Summary: | smsc floods console with warning messages "Failed to read register 0x114" and "MII is busy" | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | rz-rpi03 | ||||||||
Component: | arm | Assignee: | freebsd-arm (Nobody) <freebsd-arm> | ||||||||
Status: | Closed Overcome By Events | ||||||||||
Severity: | Affects Some People | CC: | rb | ||||||||
Priority: | --- | ||||||||||
Version: | CURRENT | ||||||||||
Hardware: | arm64 | ||||||||||
OS: | Any | ||||||||||
Attachments: |
|
Description
rz-rpi03
2019-08-29 21:46:32 UTC
I've seen behaviour like this on an RPi B when the power supply isn't up to the job. I think the common denominator is disruption of the USB stack. (In reply to Bob Bishop from comment #1) The RPi3 B is powered by an original power supply for an RPI3 B. Plugged in the USB ports are the keyboard and the low profile single port SD card reader. Also the ethernet and HDMI interfaces are in use. A power meter shows 2.0 W going into the power supply. 2.1 W if the keyboard's num-lock LED is in use. So I think there is still enough power available to rule out the power supply. Created attachment 207281 [details]
Start of panic stack backtrace
Trying to repoduce the problem with a GENERIC kernel, I get a panic which
stack backtrace consists of more lines than fit on the screen.
With the panic I lost the USB keyboards console input, so I am unable to give
the debugger any commands.
So I make a movie of the panic and took three screenshots.
a) contains the cause of the panic and the start of the stack backtrace.
b) is somewhere in the middle of the backtrace
c) contains the end of the backtrace with the debigger prompt.
Created attachment 207282 [details]
Somewhere in the middle of panic stack backtrace
Created attachment 207283 [details]
End of the panic stack backtrace
The attached screenshots show a panic occuring with a GENERIC r352023 kernel while tyring to reproduce the problem. I also did some investigation what happend to older reports of "smsc0: warning: Failed to read register 0x114 / smsc0: warning: MII is busy" kernel messages. It looks like those got fixed in base r288447 (review D3722) but removed/ifdef'd out during the transfer to ARM_INTRNG (e.g. base r296825, base r297581). If those fixes showed up at an other place in ARM_INTRNG I missed them, sorry. Maybe the following is related to the smsc-problem, may be it is not. But it is also related to the pmap as well as the panic. Without panicing, the same kernel informs about a lock order reversal. Password:lock order reversal: 1st 0xfffffd0000cf4a80 abd_chunk (UMA zone) @ /usr/src/sys/vm/uma_core.c:4232 2nd 0xffff00000121d728 pmap (pmap) @ /usr/src/sys/arm64/arm64/pmap.c:5819 stack backtrace: #0 0xffff0000004668e4 at witness_debugger+0x64 #1 0xffff0000003dfca4 at __mtx_lock_flags+0xb0 #2 0xffff0000007346e0 at pmap_fault+0x1bc #3 0xffff000000736520 at data_abort+0xc0 #4 0xffff00000073635c at do_el1h_sync+0x128 #5 0xffff00000071c074 at handle_el1h_sync+0x74 #6 0xffff0000006b6e04 at uma_dbg_free+0x50 #7 0xffff0000006b5ed8 at uma_zfree_arg+0x13c #8 0xffff0000015d6510 at abd_free+0xc0 #9 0xffff0000015da314 at arc_hdr_free_pabd+0x94 #10 0xffff0000015e15a0 at arc_write+0x1f0 #11 0xffff0000015f6ab4 at dbuf_write+0x638 #12 0xffff0000015f509c at dbuf_sync_indirect+0x2b0 #13 0xffff0000015f4d6c at dbuf_sync_list+0xa4 #14 0xffff0000015f50d0 at dbuf_sync_indirect+0x2e4 #15 0xffff0000015f4d6c at dbuf_sync_list+0xa4 #16 0xffff0000015f50d0 at dbuf_sync_indirect+0x2e4 #17 0xffff0000015f4d6c at dbuf_sync_list+0xa4 Last login: Sun Sep 8 11:22:45 on ttyv0 The fix related to bug #240518 (fixing the panic) fixes the flooding as well. Those "smsc0: warning: ..." messages still appeared in one of three tests, but they are not flooding the console any more. Also the system continues to respond to user/keyboard interactions. Because of those changes in the bug environment (can not reliable reproduce "smsc0: warning: ..." messages any more, system continues to respond now) here I close this bug report. |