Marcel Moolenaar wrote: > 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, > uart(4) is defined in the GENERIC file; I am compiling in puc(4) at present in my kernel.
-- Karl
_______________________________________________ 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"