Re: Lock of NetBSD-current with ifconfig down / up

[Masanobu SAITOH]

Hi.

On 2022/09/18 2:55, John Klos wrote:
> Hi,
> 
> Here's a nice issue :)
> 
> Plug in ure* USB ethernet to amd64 machine running NetBSD-current (9.99.99, 
> 22-August-2022):
> 
> [ 1791670.446266] ure0 at uhub8 port 4
> [ 1791670.446266] ure0: Realtek (0x0bda) USB 10/100/1000 LAN (0x8153), rev 
> 2.10/30.00, addr 6
> [ 1791670.446266] ure0: RTL8153 ver 5c30
> [ 1791670.566267] rgephy0 at ure0 phy 0: RTL8251 1000BASE-T media interface, 
> rev. 0
> [ 1791670.586267] rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, auto
> [ 1791670.586267] ure0: Ethernet address a0:ce:c8:e7:88:5f
> [ 1791673.256299] ugen1 at uhub8 port 5
> [ 1791673.256299] ugen1: VIA Labs, Inc. (0x2109) PD3.0 USB-C Device (0x), 
> rev 2.01/0.01, addr 7
> 
> ifconfig ure0 up
> 
> No problem:
> 
> ure0: flags=0x8943 mtu 1500
> capabilities=0x3ff00
> capabilities=0x3ff00
> capabilities=0x3ff00
> enabled=0
> ec_capabilities=0x1
> ec_enabled=0
> address: a0:ce:c8:e7:88:5f
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet6 fe80::a2ce:c8ff:fee7:885f%ure0/64 flags 0 scopeid 0x9
> 
> ifconfig ure0 down
> 
> Locks the machine. I couldn't get more information because it's 3000 miles 
> away. There's nothing in dmesg because the machine was power cycled.

One of my environment:

# ifconfig ure0 down
[  63.2217114] panic: kernel diagnostic assertion "mii_locked(mii)" failed: 
file "../../../../dev/mii/mii.c", line 381
[  63.2332664] cpu0: Begin traceback...
[  63.2332664] vpanic() at netbsd:vpanic+0x183
[  63.2418447] kern_assert() at netbsd:kern_assert+0x4b
[  63.2418447] mii_down() at netbsd:mii_down+0x9a
[  63.2521575] usbnet_if_stop() at netbsd:usbnet_if_stop+0x134
[  63.2521575] ether_ioctl_reinit() at netbsd:ether_ioctl_reinit+0x78
[  63.2623342] usbnet_if_ioctl() at netbsd:usbnet_if_ioctl+0x80
[  63.2717104] doifioctl() at netbsd:doifioctl+0x322
[  63.2717104] sys_ioctl() at netbsd:sys_ioctl+0x56d
[  63.2817903] syscall() at netbsd:syscall+0x196
[  63.2817903] --- syscall (number 54) ---
[  63.2817903] netbsd:syscall+0x196:
[  63.2930753] cpu0: End traceback...








> Initially I imagined it might be due to the ure* driver, but then it happened 
> locally.
> 
> On an amd64 system running 9.99.98 from 16-July-2022, I ran "ifconfig re1 
> down" and the machine locked - no ICMP, nothing for SIGINFO, no response to 
> keyboard cnmagic.
> 
> It doesn't appear to be hardware, but here's this just because.
> 
> [ 1.044097] re1 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit 
> Ethernet (rev. 0x0c)
> [ 1.044097] re1: interrupting at msix2 vec 0
> [ 1.044097] re1: RTL8168G/8111G (0x4c00)
> [ 1.044097] re1: Ethernet address 4c:cc:6a:01:a5:e0
> [ 1.044097] re1: using 256 tx descriptors
> [ 1.044097] rgephy1 at re1 phy 7: RTL8251 1000BASE-T media interface, 
> rev. 0
> 
> I've ordered some PS/2 keyboards, because I take it that's the only way to 
> reliably get in to the kernel debugger on amd64, unless someone knows a trick 
> to make USB keyboards usable.
> 
> send-pr?
> 
> Thanks,
> John

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: Can version bump up to 9.99.100?

[Kengo NAKAHARA]

Hi,

On 2022/09/17 19:34, Robert Elz wrote:

 Date:Fri, 16 Sep 2022 23:46:59 +
 From:David Holland 
 Message-ID:  

   | While it's possible that some of
   | these may exist, it's unlikely that there are many of them or that
   | they appear anywhere especially important.

That's all encouraging, and yet more reason to bump the version
soon (as required) so we have the 9.99.1xx series around long
enough for any issues to be found and fixed, before we're back
to 10.0 and 10.99.1 with a whole different set of issues to fix.


I commit the patch and bump up to 9.99.100 now.
Thank you for your advise!


Thanks,

--
//
Internet Initiative Japan Inc.

Device Engineering Section,
Product Division,
Technology Unit

Kengo NAKAHARA 

mfii0: cmd timeout

[Edgar Fuß]

This is NOT kern/55192.

So I thought I had mastered my PERC H330; set up two virtual volumes 
containing a one-disc RAID 0, set up GPTs, EFI boot volumes, built a 
RAIDframe RAID 1, disklabeled that, newfs'd the partitions, only 
remaining step being unpacking the sets (and a few config files).

Unfortunately, the machine hangs unpacking the sets, uttering
mfii0: cmd timeout ...
and stalls.

This is NOT kern/55192. It happens both with 8.2_STABLE with the patch 
from mfii.c 1.16 applied and -current.

The strange thing is that dd'ing to the raw partition seems to work 
and initializing the RAID parity also worked. But unpacking any sets 
stalls sooner or later.

Any idea how to debug this?

I looked at OpenBSD's (where mfii(4) was ported from) CVS and couldn't 
find any changes that look related.
I looked at FreeBSD, but they mave mrsas(4), which seems to be an 
entirely different beast provided by AVAGO/LSI.
Any idea why OpenBSD wrote a new driver? Any chance to port mrsas(4) 
from FreeBSD?