PUC Serial I/O problem - copy of gnats-filed bug report (as [SB QUAR: Sun Dec 13 10:50:06 2009] discussed previously)

[Karl Denninger]

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