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

Sean Bruno sbruno at
Sat Dec 20 18:50:04 PST 2008

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

From: Sean Bruno <sbruno at>
To: Dieter <freebsd at>
Cc: freebsd-firewire at, bug-followup at
Subject: Re: kern/118093: firewire bus reset hogs CPU,	causing data to be
Date: Sat, 20 Dec 2008 18:49:21 -0800

 Dieter wrote:
 > Here are the results of two more experiments:
 > I tried to verify what spl the firewire code is at when calling
 > printf(9) by adding the following block into fwohci.c just
 > before one of the printfs.
 > {
 > #include <sys/types.h>
 > #include <sys/systm.h>
 >   intrmask_t debug_spl;  /* __uint32_t */
 >   intrmask_t debug_spl_high;
 >   intrmask_t debug_spl_tty;
 >   intrmask_t debug_spl_fw;
 >   intrmask_t debug_spl_0;
 >   intrmask_t debug_spl_net;
 >   debug_spl = splhigh();
 >   debug_spl_high = spltty();
 >   debug_spl_tty = splfw();
 >   debug_spl_fw = splnet();
 >   debug_spl_net = splhigh();
 >   spl0();  /* void */
 >   debug_spl_0 = splhigh();
 >   splx(debug_spl);
 >   printf("fwohci_intr_core(): spl = 0x%x\n splhigh=0x%x spltty=0x%x splfw=0x%x splnet=0x%x spl0=0x%x\n",
 >          debug_spl, debug_spl_high, debug_spl_tty, debug_spl_fw, debug_spl_net, debug_spl_0);
 > }
 > But my results appear bogus:
 > fwohci_intr_core(): spl = 0x0
 >  splhigh=0x0 spltty=0x0 splfw=0x0 splnet=0x0 spl0=0x0
 > I have examined my code and the spl(9) man page several times
 > but I can't find what is wrong.  Any clues?
 > --------------------------------------------------------
 > To isolate the effects of printf(9) from the firewire bus reset,
 > I picked a trivial system call (chown(2)) and added some printf(9)
 > calls.
 > Calling chown several times and monitoring with systat -vmstat gives:
 >   1098 interrupts on the console IRQ
 >   93.1%Sys   6.7%Intr  0.2%User  0.0%Nice  0.0%Idle
 > This did NOT interfere with Ethernet.
 > So printf(9) interferes with Ethernet when called from the
 > firewire driver, but not when called from a vanilla system call.
 I setup my system to execute a bus reset every 1 second, simultaneously, 
 I started copying a large
 file onto the system see if anything would happen.
 I saw no change to copy speed reported by SCP during the entire 
 transaction.  I also see no change
 to the system load while this is occurring.
 This seems indicative of "something else" going on.
 > --------------------------------------------------------
 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
 > sio0: type 16550A, console
 > sio0: [FILTER]
 > What does [FILTER] mean?  I don't see an explanation on the sio man page.
 Did you mean to ask a different list?  Because I have no idea.  :)

More information about the freebsd-bugs mailing list