Re: Installation of liblua fails
My attempt: as NetBSD wont boot from stick or even ISO (neauveu cant initialise X server), I thought, I do a virtual machine distribution built and it ends up in install liblua {Error 1}; no hint, nothing. What to do? If you want to make the system boot and it's not booting because of nouveau, then you can disable nouveau by using the boot menu to drop to the command line: userconf disable nouveau boot When you've got a booted system, you can edit /boot.cfg to disable nouveau like so: menu=Boot normally:rndseed /var/db/entropy-file;userconf disable nouveau;boot John
Re: Panics from today's sources
Hi, On Sun, Apr 03, 2022 at 05:20:37PM +, John Klos wrote: [ 56496.032711] uvm_fault(0x81908580, 0xbd134d9bc000, 2) -> e [ 56496.032711] fatal page fault in supervisor mode [ 56496.032711] trap type 6 code 0x2 rip 0x80c4f634 cs 0x8 rflags 0x10202 cr2 0xbd134d9bcc90 ilevel 0 rsp 0xa604bbfebda0 [ 56496.032711] curlwp 0xfd0d7.0327109] panic: trap [ 56496.032711] cpu5: Begin traceback... panic() at netbsd:panic+0x3c [ 56496.032711] trap() at netbsd7109] uvm_pagefree() at netbsd:uvm_pagefree+0x2d5 [ 56496.003271] uvm_unmapace_free() at netbsd:uvmspace_free+0xe4 [ 56496.042711] exit1()_exit+0x39 [ 56496.042711] syscall() at netbsd:syscall+0x1f2 cpu5: End traceback... Is that happening to specific processes? Which process is trying to exit here? I have updated three machines today and don't see anything like that so far. I've been stress testing, so the system was running a pkg_rolling-replace with some heavy packages like rust and firefox, plus running build.sh of NetBSD-current in a tmpfs in a loop, plus running VMs in simh and qemu, so it'd be hard to say which process it was at the time. However, after updating to more recent -current, this hasn't happened any more, so I think it's safe to say that whatever was causing it has been fixed. Thanks, John
Re: Interesting output from npfctl
Should be fixed with: /cvsroot/src/lib/libnpf/npf.c,v <-- npf.c new revision: 1.50; previous revision: 1.49 Thanks, Christos!
Interesting output from npfctl
Hi, One of my blocklist files ended up with a duplicate entry, and npfctl reload had this to say: npfctl reload npfctl: ?8t?f??K???H?5d? 6e 70 66 63 74 6c 3a 20 83 38 11 74 e5 66 90 e8 |npfctl: .8.t.f..| 0010 4b f3 ff ff 48 8d 35 64 a6 0a|K...H.5d..| NetBSD-9.99.97 from 23-May-2022, amd64. Any ideas? John
Fun amd64 panic
Here's one if anyone wants to try this on a physically local machine. amd64, current from today, a simple "atf-run": [ 119.516347] uhub8: at uhub1 port 6 (addr 1) disconnected [21.00] cpu10 at mainbus0 apid 9 [ 1.03] cpu10: AMD784.0900672] cpu0: Begin traceback... [ 21784.090067] vpanic() at netbsd:vpanic+0x183 [ 21784.090067] panic() at netbsd:panic+0x3c [ 21784.090067] bus_dmamap_sync() at netbsd:bus_dmamap_synG with Radeon Graphics , id 0xa50f00 [ 1.03] cpu1 21784.0900672] rge_intr() at netbsd:rge_intr+0x16f [ 21784.90] acpi0: X/RSDT: OemId [ 21784.0900672] Xhandle_ioapic_edge16() at netbsd:Xhandle_ioapi acpi0: autoconfiguration error: invalid PCI address for D003 x86_stihlt() at netbsd:x86_stihlt+0x6 [ 21784.090067] acpicpu for D006 [ 1.03] acpi0: MCFG: segment 0, bus 0-127, addr72] idle_loop() at netbsd:idle_loop+0x14c [ 21784.090067] cpu0: int 9 [ 1.03] acpi0: fixed power button present [ 1.00] dump [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, ...
Re: Panics from today's sources
[ 56496.042711] exit1()_exit+0x39 [ 56496.042711] syscall() at netbsd:syscall+0x1f2 cpu5: End traceback... Is that happening to specific processes? Which process is trying to exit here? I have updated three machines today and don't see anything like that so far. After another round of updating / rebuilding, all panics disappeared. Let's just attribute it to something out of sync for a brief time and not a real issue. Thanks! John
Panics from today's sources
Hi, A system that has otherwise been very happy with -current from 23-March-2022 has panicked twice with today's -current: NetBSD 9.99.96 (FRIGG) #0: Sat Apr 2 19:46:01 UTC 2022 [ 56496.032711] uvm_fault(0x81908580, 0xbd134d9bc000, 2) -> e [ 56496.032711] fatal page fault in supervisor mode [ 56496.032711] trap type 6 code 0x2 rip 0x80c4f634 cs 0x8 rflags 0x10202 cr2 0xbd134d9bcc90 ilevel 0 rsp 0xa604bbfebda0 [ 56496.032711] curlwp 0xfd0d7.0327109] panic: trap [ 56496.032711] cpu5: Begin traceback... panic() at netbsd:panic+0x3c [ 56496.032711] trap() at netbsd7109] uvm_pagefree() at netbsd:uvm_pagefree+0x2d5 [ 56496.003271] uvm_unmapace_free() at netbsd:uvmspace_free+0xe4 [ 56496.042711] exit1()_exit+0x39 [ 56496.042711] syscall() at netbsd:syscall+0x1f2 cpu5: End traceback... [ 5649.00] dump [ 4688.531695] uvm_fault(0x8196eb20, 0x80826dc9c000, 2) -> e [ 4688.531695] fatal page fault in supervisor mode [ 4688.531695] trap type 6 code 0x2 rip 0x80c4f634 cs 0x8 rflags 0x10202 cr2 0x80826dc9cb28 ilevel 0 rsp 0xd684bdceada0 [ 4688.541696] curlwp 0x84818573cb00 pid 16618.16618 lowest kstack 0xd684bdce62c0 [ 4688.541696] panic: trap [ 4688.541696] cpu23: Begin traceback... [ 4688.541696] vpanic() at netbsd:vpanic+0x14a [ 4688.541696] panic() at netbsd:panic+0x3c [ 4688.541696] trap() at netbsd:trap+0xaa0 [ 4688.541696] --- trap (number 6) --- [ 4688.541696] uvm_pagefree() at netbsd:uvm_pagefree+0x2d5 [ 4688.541696] uvm_anfree() at netbsd:uvm_anfree+0x51 [ 4688.541696] amap_wipeout() at netbsd:amap_wipeout+0x38 [ 4688.541696] uvm_unmap_detach() at netbsd:uvm_unmap_detach+0x49 [ 4688.541696] uvmspace_free() at netbsd:uvmspace_free+0xe4 [ 4688.541696] exit1() at netbsd:exit1+0x185 [ 4688.541696] sys_exit() at netbsd:sys_exit+0x39 [ 4688.541696] syscall() at netbsd:syscall+0x1f2 [ 4688.551696] --- syscall (number 1) --- [ 4688.551696] netbsd:syscall+0x1f2: [ 4688.551696] cpu23: End traceback... [ 4688.551696] dumping to dev 168,2 (offset=188878, size=16753352): [ 4688.551696] dump Any ideas? John
Re: Panic with 9.99.94
Oops. It's a Ryzen 5900X, not 3900X. John
Panic with 9.99.94
Hi, all, While stress testing a new Ryzen 3900X with NetBSD from yesterday's sources (running pbulks, mostly), this happened: [ 52610.574409] fatal protection fault in supervisor mode [ 52610.574409] trap type 4 code 0 rip 0x80d4d8c5 cs 0x8 rflags 0x10282 cr2 0x6fa115e0ee00 ilevel 0 rsp 0xa805ce812da0 [ 52610.574409] curlwp 0xca42d6be5180 pid 7231.7231 lowest kstack 0xa805ce80e2c0 [ 52610.574409] panic: trap [ 52610.574409] cpu23: Begin traceback... [ 52610.574409] vpanic() at netbsd:vpanic+0x156 [ 52610.574409] panic() at netbsd:panic+0x3c [ 52610.574409] trap() at netbsd:trap+0xb27 [ 52610.574409] --- trap (number 4) --- [ 52610.574409] uvm_pagefree() at netbsd:uvm_pagefree+0x38d [ 52610.574409] uvm_anfree() at netbsd:uvm_anfree+0x88 [ 52610.574409] amap_wipeout() at netbsd:amap_wipeout+0xa2 [ 52610.574409] uvm_unmap_detach() at netbsd:uvm_unmap_detach+0x56 [ 52610.574409] uvmspace_free() at netbsd:uvmspace_free+0xeb [ 52610.574409] exit1() at netbsd:exit1+0x1b8 [ 52610.574409] sys_exit() at netbsd:sys_exit+0x39 [ 52610.574409] syscall() at netbsd:syscall+0x196 [ 52610.574409] --- syscall (number 1) --- [ 52610.574409] netbsd:syscall+0x196: [ 52610.574409] cpu23: End traceback... [ 52610.574409] dumping to dev 168,2 (offset=188902, size=16753349): [ 52610.574409] dump dmesg with panic: https://klos.com/~john/ryzen_dmesg Any ideas about what happened here? John
Re: Big-endian mode supported for Raspberry Pi [0-3] with bootable images available
Thank you for all your hard work! The images work just fine out of the box. After a few hours of compiling, there was a panic. This is a 3B+ (the 1400 MHz one): [ 18045.402869] ifree: dev = 0xa801, ino = 35088, fs = / [ 18045.402869] panic: ffs_freefile_common: freeing free inode [ 18045.414509] cpu0: Begin traceback... [ 18045.414509] trace fp c0004376f810 [ 18045.414509] fp c0004376f840 vpanic() at c04e5d5c netbsd:vpanic+0x14c [ 18045.424917] fp c0004376f8a0 panic() at c04e5e54 netbsd:panic+0x44 [ 18045.424917] fp c0004376f930 ffs_freefile_common.isra.0() at c0422f44 netbsd:ffs_freefile_common.isra.0+0x2d4 [ 18045.436775] fp c0004376f9a0 ffs_freefile() at c0427bb4 netbsd:ffs_freefile+0xf4 [ 18045.445200] fp c0004376fa00 ffs_reclaim() at c0434968 netbsd:ffs_reclaim+0x110 [ 18045.445200] fp c0004376fa40 VOP_RECLAIM() at c0556cfc netbsd:VOP_RECLAIM+0x34 [ 18045.455684] fp c0004376fa70 vcache_reclaim() at c0548a6c netbsd:vcache_reclaim+0x14c [ 18045.465203] fp c0004376fb40 vrelel() at c0549520 netbsd:vrelel+0x2a0 [ 18045.465203] fp c0004376fba0 vn_close() at c054dcfc netbsd:vn_close+0x44 [ 18045.477720] fp c0004376fbd0 closef() at c047c448 netbsd:closef+0x60 [ 18045.477720] fp c0004376fc10 fd_free() at c047f3c0 netbsd:fd_free+0xf8 [ 18045.488230] fp c0004376fc90 exit1() at c048a5cc netbsd:exit1+0xfc [ 18045.488230] fp c0004376fd80 sys_exit() at c048af08 netbsd:sys_exit+0x38 [ 18045.498527] fp c0004376fdb0 syscall() at c008ef1c netbsd:syscall+0x18c [ 18045.508234] fp c0004376fe60 trap_el0_sync() at c00903f0 netbsd:trap_el0_sync+0x380 [ 18045.508234] tf c0004376fed0 el0_trap() at c00927f0 netbsd:el0_trap [ 18045.518235] trapframe 0xc0004376fed0 (304 bytes) [ 18045.518235] pc=fd5f181b0c14, spsr=8000 [ 18045.518235]esr=5601,far=f53aaf49a000 [ 18045.529932] x0=, x1= [ 18045.529932] x2=00020013e000, x3=ff837b80 [ 18045.529932] x4=, x5=fd5f1844a3c0 [ 18045.541002] x6=, x7=4545524348363400 [ 18045.541002] x8=fd5f, x9=0003 [ 18045.541002]x10=fd5f18221000,x11=0030 [ 18045.552073]x12=fd5f18239a00,x13=fd5f17c008c0 [ 18045.552073]x14=0014,x15=4008 [ 18045.552073]x16=00020013d1f8,x17=fd5f181b0c10 [ 18045.563146]x18=0041,x19= [ 18045.563146]x20=00020013d000,x21=ff838fe0 [ 18045.563146]x22=00020013df80,x23= [ 18045.574215]x24=ff838fe0,x25=f33f [ 18045.574215]x26=,x27= [ 18045.574215]x28=, fp=x29=ff837b80 [ 18045.585287] lr=x30=00020011c890, sp=ff837b80 [ 18045.585287] [ 18045.585287] cpu0: End traceback... [ 18045.594926] rebooting... This was a clean big endian filesystem on a USB attached SSD on its first boot. Trying to fully fsck didn't work (I don't have a record - it was on the local console), and trying to fsck on a little endian Pi gave this: http://mail-index.netbsd.org/port-arm/2020/12/26/msg007132.html I decided to make a clean little endian filesystem and restart. However, enabling WAPBL in fstab causes the boot to fail with messages saying that the filesystem is read-only, then: mount /dev/sd0a / mount_ffs: /dev/sd0a on /: specified device does not match mounted device Perhaps it should be noted somewhere that WAPBL can't be used on other-endian systems, and a more meaningful error presented when it is attempted? John Klos
Re: ctfmerge stuck on CPU
I'm testing very recent -current on RPi4. Threaded programs are broken for aarch64 since ~1 week (most of the pthread tests fail, programs get stuck in jemalloc cleanup on thread exit). It is not clear what goes wrong exactly (or: why this works on other architectures) OK thanks for the info, I'll try again some other time. If you'd like to be able to compile until this is fixed, just fetch and untarxzip this: http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202006030740Z/evbarm-aarch64/binary/sets/base.tar.xz John
Re: Proposal to remove driver for the Cabletron EA41x SCSI Ethernet adapter
If this is the same chip as is in the DaynaPort SCSI-Link-T, I can offer to test the driver. I just checked, and the Dayna SCSI/Link does not have the same chipset as the Cabletron, so I can't test the hardware. Please consider any objection from me rescinded. Thanks, John
Re: Proposal to remove driver for the Cabletron EA41x SCSI Ethernet adapter
Hi, We have a driver for this device in sys/dev/scsipi/if_se.c. It was pretty popular with the pc532 crowd back in the day because SCSI was the only expansion bus the pc532 had. There are changes coming to the network stack and it's unlikely that (a) anyone has such a device to test it, and (b) that the driver even works currently because it's been so long since probably anyone ran this code. I propose we remove this driver. If it's not too much work, it might be worth keeping because some newer hardware will emulate it: https://hackaday.io/project/18974-tiny-scsi-emulator If this is the same chip as is in the DaynaPort SCSI-Link-T, I can offer to test the driver. John
Re: Can't set volume options during install?
How are people supposed to set the block and fragment sizes in the NetBSD installer? If it's still possible, it certainly isn't easy to find. Is it usefull anywhere? I removed it, thinking noone would care. If there is use for it, I'll re-add it to the partition details menu: It would go before "mount options" and only be available for FFS. But is it really needed? I often use small USB sticks, small virtual machine images, SD cards and the like which end up sometimes having not enough inodes for a pkgsrc tree even when there's plenty of space. If the defaults worked well enough, for instance, for a 1 gig image, then it'd be nice to not need to think about, but right now the defaults for a 1 gig image give: /dev/rvnd0a: 1024.0MB (2097152 sectors) block size 16384, fragment size 2048 using 6 cylinder groups of 170.67MB, 10923 blks, 21504 inodes. super-block backups (for fsck_ffs -b #) at: 32, 349568, 699104, 1048640, 1398176, 1747712, So the options would be nice :) Thanks! John
Can't set volume options during install?
How are people supposed to set the block and fragment sizes in the NetBSD installer? If it's still possible, it certainly isn't easy to find. John
Re: Panic on current on mac68k
[ 3.2026086] sd0 at scsibus0 target 0 lun 0: disk removable [ 3.3027567] sd0: 61064 MB, 16383 cyl, 15 head, 63 sec, 512 bytes/sect x 125059072 sectors [ 3.4035060] sd1 at scsibus0 target 0 lun 1: disk removable [ 3.5038328] sd1: drive offline [ 3.5399414] sd2 at scsibus0 target 0 lun 2: disk removable [ 3.6369543] sd2: drive offline [ 3.6729607] sd3 at scsibus0 target 0 lun 3: disk removable [ 3.7720454] sd3: 61056 MB, 15506 cyl, 128 head, 63 sec, 512 bytes/sect x 125042688 sectors [ 3.8770380] sd4 at scsibus0 target 0 lun 4: disk removable [ 3.9741249] sd4: drive offline [ 4.0117232] sd0: async, 8-bit transfers [ 4.0117232] sd1: async, 8-bit transfers [ 4.0117232] sd2: async, 8-bit transfers [ 4.0117232] sd3: async, 8-bit transfers [ 4.0117232] sd4: async, 8-bit transfers That is a whole raft of, erm, non-standard disk drives you have there. How are the silicon disks bridged, and how reliable and standard conformant (sp?) are these bridges? Do you get the panic with traditional spinning rust? Those are all flash media in an SCM Microsystems PCD-50B SCSI card reader. Mac OS can't see things on anything that's not LUN 0, but NetBSD sure can. I've had no issues with it on this machine or on a VAXstation 4000/30. I won't have a chance to try out a spinning rust drive for a week or two, but I'll give that a go, too. John
Panic on current on mac68k
On a Quadra 605 which has been running netbsd-8 without issues for ages, it seems -current isn't happy. I don't see any obvious recent changes which might cause this. Ideas? [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000] The Regents of the University of California. All rights reserved. [ 1.000] NetBSD 8.99.34 (GENERIC) #0: Sun Feb 24 08:02:45 UTC 2019 [ 1.000] mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/mac68k/compile/GENERIC [ 1.000] Apple Macintosh LC 475/33 (68040) [ 1.000] cpu: delay factor 1051 [ 1.000] fpu: mc68040 [ 1.000] total memory = 132 MB [ 1.000] avail memory = 124 MB [ 1.000] mrg: 'Quadra/Centris 605 ROMs' ROM glue, tracing off, debug off, silent traps [ 1.000] mainbus0 (root) [ 1.000] obio0 at mainbus0 [ 1.000] esp0 at obio0 addr 0 (quick): address 0x42b000: NCR53C96, 16MHz, SCSI ID 7 [ 1.000] scsibus0 at esp0: 8 targets, 8 luns per target [ 1.000] adb0 at obio0 [ 1.000] asc0 at obio0: Apple Sound Chip [ 1.000] intvid0 at obio0 @ f9001000: DAFB video subsystem, monitor sense 1 [ 1.000] intvid0: 640 x 480, monochrome [ 1.000] macfb0 at intvid0 [ 1.000] wsdisplay0 at macfb0 (kbdmux ignored) [ 1.000] iwm0 at obio0: Apple GCR floppy disk controller [ 1.000] fd0 at iwm0 drive 0: (HD disk -- not supported) [ 1.000] fd1 at iwm0 drive 1: (HD disk -- not supported) [ 1.000] zsc0 at obio0 chip type 0 [ 1.000] zsc0 channel 0: d_speed 9600 DCD clk 0 CTS clk 0 [ 1.000] zstty0 at zsc0 channel 0 (console i/o) [ 1.000] zsc0 channel 1: d_speed 9600 DCD clk 0 CTS clk 0 [ 1.000] zstty1 at zsc0 channel 1 [ 1.000] nubus0 at mainbus0 [ 1.000] sn0 at nubus0 slot e: Macintosh LC Ethernet Adapter [ 1.000] sn0: Ethernet address 00:01:98:34:0a:af [ 1.0070344] scsibus0: waiting 2 seconds for devices to settle... [ 1.0813425] adb0 (direct, Cuda): 2 targets [ 1.1974730] aed0 at adb0 addr 0: ADB Event device [ 1.2548707] akbd0 at adb0 addr 2: keyboard II [ 1.3069412] wskbd0 at akbd0 (mux ignored) [ 1.3548783] ams0 at adb0 addr 3: EMP mouse 3-button, 480 dpi [ 1.4558255] wsmouse0 at ams0 (mux ignored) [ 3.2026086] sd0 at scsibus0 target 0 lun 0: disk removable [ 3.3027567] sd0: 61064 MB, 16383 cyl, 15 head, 63 sec, 512 bytes/sect x 125059072 sectors [ 3.4035060] sd1 at scsibus0 target 0 lun 1: disk removable [ 3.5038328] sd1: drive offline [ 3.5399414] sd2 at scsibus0 target 0 lun 2: disk removable [ 3.6369543] sd2: drive offline [ 3.6729607] sd3 at scsibus0 target 0 lun 3: 1.28> disk removable [ 3.7720454] sd3: 61056 MB, 15506 cyl, 128 head, 63 sec, 512 bytes/sect x 125042688 sectors [ 3.8770380] sd4 at scsibus0 target 0 lun 4: disk removable [ 3.9741249] sd4: drive offline [ 4.0117232] sd0: async, 8-bit transfers [ 4.0117232] sd1: async, 8-bit transfers [ 4.0117232] sd2: async, 8-bit transfers [ 4.0117232] sd3: async, 8-bit transfers [ 4.0117232] sd4: async, 8-bit transfers [ 4.7688770] swwdog0: software watchdog initialized [ 4.8369274] WARNING: 1 error while detecting hardware; check system log. [ 4.9171894] boot device: sd0 [ 4.9689727] root on sd0a dumps on sd0b [ 5.0856203] root file system type: ffs [ 5.1405822] kern.module.path=/stand/mac68k/8.99.34/modules [ 5.2356266] panic: Unexpected phase in transfer_pdma. [ 5.2356266] cpu0: Begin traceback... [ 5.2356266] ?(?) [ 5.2356266] db_panic(0,9ac000,0,32d680,3f0e6c) at 0 [ 5.2356266] vpanic(28b942,3f0e78,3f0ebc,15bae,28b942) + 154 [ 5.2356266] panic(28b942,4d8983c,ea9c3000,0,0) + c [ 5.2356266] transfer_pdma(?) [ 5.2356266] mi_switch(32d680) + 140 [ 5.2356266] sleepq_block(0,0,349b9c,32d680,349b90,2b98b4,32d2e4,9ac09c,9ac558) + 16c [ 5.2356266] cv_wait(349b90,349b9c) + 78 [ 5.2356266] kthread_join(acd620) + 72 [ 5.2356266] config_finalize_mountroot(0,0,5,e6b,3f0fa4) + 24 [ 5.2356266] main(1cc4ba,796000,0,1000,187c06) + 71a [ 5.2356266] ?() at 419 [ 5.2356266] cpu0: End traceback... Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x6:unlka6
ahcisata and WDCTL_RST
Hi, I have an older MSi MS-7511 motherboard (it just happens to be the one that the NetBSD Foundation gave to certain developers). It has run fine for years, but with NetBSD-7 and -current, ahcisata will only recognize SATA drives every tenth boot or so. There's no discernible pattern: ahcisata0 at pci0 dev 9 function 0: vendor 0x10de product 0x0ad0 (rev. 0xa2) LSA0: Picked IRQ 21 with weight 1 ahcisata0: interrupting at ioapic0 pin 21 ahcisata0: 64-bit DMA ahcisata0: ignoring broken port multiplier support ahcisata0: AHCI revision 1.20, 6 ports, 32 slots, CAP 0xe3209f05 atabus0 at ahcisata0 channel 0 atabus1 at ahcisata0 channel 1 atabus2 at ahcisata0 channel 2 atabus3 at ahcisata0 channel 3 atabus4 at ahcisata0 channel 4 atabus5 at ahcisata0 channel 5 ... ahcisata0 port 1: device present, speed: 3.0Gb/s ahcisata0 port 2: device present, speed: 3.0Gb/s ahcisata0 port 0: device present, speed: 3.0Gb/s ahcisata0 port 3: device present, speed: 3.0Gb/s ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0 ahcisata0 channel 1: clearing WDCTL_RST failed for drive 0 ahcisata0 channel 2: clearing WDCTL_RST failed for drive 0 ahcisata0 channel 3: clearing WDCTL_RST failed for drive 0 With NetBSD 7.0.1 installation kernel, I get the same as above but: ahcisata0 port 3: device present, speed: 3.0Gb/s ahcisata0 port 1: device present, speed: 3.0Gb/s ahcisata0 port 2: device present, speed: 3.0Gb/s ahcisata0 port 0: device present, speed: 3.0Gb/s atabus0: Unrecognized signature 0x0001 on port 0. Assuming it's a disk. atabus3: Unrecognized signature 0x0001 on port 0. Assuming it's a disk. atabus2: Unrecognized signature 0x0001 on port 0. Assuming it's a disk. atabus1: Unrecognized signature 0x0001 on port 0. Assuming it's a disk. wd0 at atabus0 drive 0 wd0: wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA) ... (and other three disks) However, booting a NetBSD 6.1.5 kernel, all drives are recognized and are usable with no problems at all. The only difference is that the "ignoring broken port multiplier support" message isn't reported by the 6.1.5 kernel. While trying to figure out what was wrong, I tried completely different drives, different SATA cables, a different power supply, et cetera, and nothing mattered except changing the kernel. Does anyone have ideas about what may've broken this? Thanks, John
Re: ipfilter broken in -current?
Kernel and userland compiled from today's current sources from about six hours ago on an evbmips-eb system: Just to make sure: evbmips-eb or evbmips64-eb ? (i.e.: native or compat_netbsd32 issue?) Oh - sorry - evbmips64-eb. But on a much more common Raspberry Pi 2 running -current, things work :P John
ipfilter broken in -current?
Kernel and userland compiled from today's current sources from about six hours ago on an evbmips-eb system: ipf -f /etc/ipf.conf 115:ioctl(SIOCGETFS) unrecognised ipf ioctl User/kernel version check failed Anyone?
Re: Removal of acorn26 port
Hi, I can't figure how I'd use it or find a compatible computer; running in an emulator doesn't really count. True. Just like the ns32k, it was nice, but without hardware to run it, it's hardly worth the effort. For that matter, does anybody still use port-vax? Actually, yes. That port gets much more use. VAXen are pretty common and they're more than just a curiosity. Mine are used for various things - secondary DNS and backup MX in a non-temperature controlled location, performance profiling of code which will eventually run on embedded hardware, edge case testing of floating point code and so on. netbsd-6 runs just fine on VAXen, but netbsd-7 and current have toolchain issues at the moment. In some ways removal of acorn26 isn't too unlike the removal of support for i80386 processors from the i386 port (the name is a bit of a misnomer now, though). John
Re: Removal of acorn26 port
Unless someone can give a good reason to keep it, the acorn26 port will be removed in a week or two or three. Along with the removal will be the cleanup of the common arm to remove the arm26 bits associated with it. Does the port currently work? If so, maybe it'd be nice to have a 7.0 release before it's removed so it's clear what the last known working release, tag and date are. John