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

Dieter freebsd at sopwith.solgatos.com
Sun Dec 28 22:00:13 PST 2008


The following reply was made to PR kern/118093; it has been noted by GNATS.

From: Dieter <freebsd at sopwith.solgatos.com>
To: freebsd-firewire at freebsd.org, bug-followup at freebsd.org
Cc:  
Subject: Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost 
Date: Sun, 28 Dec 2008 21:49:00 +0000

 > >>> 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?


More information about the freebsd-bugs mailing list