kern/118093: firewire bus reset hogs CPU, causing data to be
lost
Sean Bruno
sbruno at miralink.com
Sun Dec 28 22:30:07 PST 2008
The following reply was made to PR kern/118093; it has been noted by GNATS.
From: Sean Bruno <sbruno at miralink.com>
To: Dieter <freebsd at sopwith.solgatos.com>
Cc: freebsd-firewire at freebsd.org, bug-followup at freebsd.org
Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be
lost
Date: Sun, 28 Dec 2008 22:22:26 -0800
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-bugs
mailing list