the watchdog timer is completely broken and never fire (it's from FreeBSD
(pre iflib)). If the problem is fixed and watchdog fired, ixgbe_init() always
calls ixgbe_jcl_reinit() and it causes panic. The reason is that
ixgbe_local_timer1(it includes watchdog function) is softint and
xgbe_jcl_reinit() calls bus_dmamem*() functions. bus_dmamem*() can't be called
from interrupt context.
One of the way to prevent panic is use worqueue for the timer, but it's
not a small change. (I'll do it in future).
Another way is not reallocate dmamem if it's not required. If both the MTU
(rx_mbuf_sz in reality) and the number of RX descriptors are not changed, it's
not required to call bus_dmamem_{unmap,free}(). Even if we use workque, this
change save time of ixgbe_init().
I have a code to fix broken watchdog timer but it sometime causes watchdog
timeout, so I don't commit it yet.
The GPIO part of wbsio(4) has a lock to keep the register access
order. In addition to the lock, gpio(4) has a look to prevent
multiple control through gpio_pin_ctl(). Those locks hold at
once when gpio_pin_ctl() is called, and the lock of gpio(4) hold
before that of wbsio(4).
Therefore, the wbsio(4) has to use spin lock if gpio(4) uses
spin lock.
Remove the ppsig argument from proc_stop_done() and from sigswitch().
This functionality was used in now gone filesystem tracing feature (/proc).
It prevented emitting signal child signals to a debugging program, namely
with the SIGCHLD signal.
The modern solution to perform tracing without signals in a debugger is
to spawn a debugging server and outsource the tracing functionality to it.
This is done in software like gdb-server, lldb-server etc.
No functional change intended.
Sponsored by <The NetBSD Foundation>
avoid misinterpreting shared interrupt for another device
when clearing USBSTS, actually preserve the bits which spec requires to
preserve, and actually clear bit 1, which should be actually always
cleared to zero by spec
also #ifdef XHCI_DEBUG some unnecessary register reads
this should finally resolve PR kern/53066 also for Martin
reasons. RH0 was already removed in the kernel's input path, but some
parts were still present in the output path: they are now removed.
Sent on tech-net@ a few days ago.
maxv