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

Sean Bruno sbruno at miralink.com
Sun Dec 28 22:22:27 PST 2008


Dieter wrote:
>>>
>>>   
>>>       
>> 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.
>
>   
Well, there is locking around a couple of mutex's via FW_GLOCK().

It appears that the locking is not robust, and that is one of the issues 
that I am
looking into right now.
>   
>>>> 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?
>   
I doubt it.  I'm working on a patch that improves the locking a bit and 
does some
other "gross" things to try and keep things from flying apart.

I've SEEN this behaviour in my implementations with sbp_targ and 
couldn't pin it down.

Scott Long gave me a couple of pointers this evening, but I'm still 
working on locking
down the taskqueues and some of the callback_handlers.  There are some 
bad things going
on specifically during initialization that are pre-empting normal operation.

Sean


More information about the freebsd-firewire mailing list