PUC Serial I/O problem - copy of gnats-filed bug report (as [SB
QUAR: Sun Dec 13 10:50:06 2009] discussed previously)
xcllnt at mac.com
Tue Dec 15 17:58:09 UTC 2009
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.
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
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...
xcllnt at mac.com
More information about the freebsd-stable