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

Sean Bruno <[email protected]>
Newsgroups gmane.os.freebsd.devel.firewire
Message-ID <[email protected]>
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-firewire
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.