kern/118093: firewire bus reset hogs CPU, causing data to be lost

[Dieter]

> >>> I confirmed that spl's are complete no-ops since rel 5.  So, you want 
> >>> to ignore
> >>> them as they are just markers now where locking should be implemented.
> >>>       
> >
> > I hunted down the spl code, and you're right.  Wow, I wonder how drivers
> > still using spl calls work at all?
> >
> >   
> I believe that the spl() calls are just left there as a hint where 
> locking should be.
> 
> As far as I understand, we need to pay attention to the mutex locks.

I'll rephrase my question.  In the old days, locking was done with spl.
The new way is with mutex.  But with the spl calls being replaced with
noops, and as far as I can tell the driver is not using mutex, there
doesn't appear to be any locking.  So the driver can step on itself.


> >> is to real behavior, but /var/log/messages has a tendency to get garbled 
> >> like this:
> >>
> >> Dec 22 16:00:18 home-test kernel: fwohci1: Initiate bus reset
> >> Dec 22 16:00:18 home-test kernel: fwohci1: BUS reset
> >> Dec 22 16:00:18 home-test kernel: fwohci1: node_id=0xc800ffc0, gen=8, 
> >> CYCLEMASTER mode
> >> Dec 22 16:00:18 home-test kernel: firewi
> >> Dec 22 16:00:18 home-test kernel: re1:
> >> Dec 22 16:00:18 home-test kernel: 1 n
> >> Dec 22 16:00:18 home-test kernel: odes
> >> Dec 22 16:00:18 home-test kernel: , ma
> >> Dec 22 16:00:18 home-test kernel: xhop
> >> Dec 22 16:00:18 home-test kernel: <=
> >> Dec 22 16:00:18 home-test kernel: 0, c
> >> Dec 22 16:00:18 home-test kernel: able
> >>     
> >
> > Do the lines get folded on the console, or only in /var/log/messages?
> >   
> 
> As far as I can see, the console messages are fine.  It's only the 
> messages that get
> garbled.

Perhaps an artifact of syslogd?