Re: Installation of liblua fails

[John Klos]

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

[John Klos]

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

[John Klos]

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

[John Klos]

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

[John Klos]

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

[John Klos]

[ 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

[John Klos]

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

[John Klos]

Oops. It's a Ryzen 5900X, not 3900X.

John

Panic with 9.99.94

[John Klos]

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

[John Klos]

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

[John Klos]

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

[John Klos]

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

[John Klos]

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?

[John Klos]

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?

[John Klos]

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

[John Klos]

[   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

[John Klos]

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

[John Klos]

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

ipfilter broken in -current?

[John Klos]

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

[John Klos]

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

[John Klos]

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