On Dec 15, 2009, at 7:03 AM, Karl Denninger wrote: > This is now marked fixed and it appears (after limited testing thus far) > that it indeed is.
The bug existed in 7 as well. It's not a regression introduced in 8. The reason why this didn't come up in the 7 time frame is that sio(4) was still the default. Jeremy has been an early adopter of uart(4) and if I'm not mistaken, he always loaded the driver(s) as modules. This, due to a "lucky" bug, avoided the problem for him. In depth: With uart(4) I created the serdev I/F. This is an interface that allows umbrella drivers like puc(4) and scc(4) to obtain pending interrupt status and invoke interrupt source specific handlers. This puts the umbrella driver in control over what gets handled in what order *across* multiple interfaces. As such, with puc(4), you can service all receive interrupts for all ports before you service, say, the transmit interrupt across the ports. When a serial device does not implement the serdev I/F, then puc(4) won't be involved in interrupt handling at all. This is why puc(4)+sio(4) had no problem. Since uart(4) does implement the serdev I/F, the interrupt handler of puc(4) would be in control and since it was this interrupt handler that was broken, exhibit the stalls. But, when puc(4) and/or uart(4) were loaded as modules, puc(4) would not see uart(4) as implementing the serdev I/F. This is to do with linker sets, etc. Consequently, uart(4) would handle its own interrupts and puc(4) would not be involved (just as with the sio(4) setup). In that scenario puc(4)+uart(4) also just worked. In any case: puc(4) has been fixed and I'll deal with the linker set bug later. For best results: compile puc(4) and uart(4) into the kernel and don't load them as modules for now... FYI, -- Marcel Moolenaar xcl...@mac.com _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
