Quality of FreeBSD

[Marko Vihoma]

Hello list and J. :-)

On Tuesday 26 July 2005 18:26, J. Porter Clark wrote:

> Because the hard drive is "only" 20 GB, I have an external drive
> connected to the IEEE 1394 port.  (The USB ports on this laptop
> are unacceptably pokey.)  Most of the problems are probably
> related to my attempts at hot-plugging (so to speak) this
> interface.  The first time I connect the drive up to the box,
> I get this sort of thing:
> 
>   firewire0: New S400 device ID:0090a95000006600
>   da0 at sbp0 bus 0 target 0 lun 0
>   kernel: da0: <WDC FireWire/USB2.0 0417> Fixed Simplified Direct 
Access SCSI-4 device 
>   kernel: da0: 50.000MB/s transfers
>   kernel: da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 
30401C)
>   fwohci0: BUS reset
>   fwohci0: node_id=0xc000ffc0, gen=2, CYCLEMASTER mode
>   kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
>   kernel: firewire0: bus manager 0 (me)
> 
> I can then mount a partition from the drive:
> 
>   mount /dev/da0s2d ~/ext_bsd
> 
> Sometimes I have a problem--and I can't duplicate it right
> now--in that if I umount the drive, then remove the plug, then
> reinsert it, I can't remount it immediately.  Attempting to
> mount the drive will block for a few minutes.  If I wait several
> minutes, it will remount immediately, or I can speed that up by
> removing and reinserting the plug a second time, which is what I
> usually do.
> 
> The main problem I have is possibly related to an intermittent
> connection...which has been aggravated by the many insertions
> and reinsertions.  Sometimes, out of the blue, I'll get an error
> like this:
> 
>   kernel: Interrupt storm detected on "irq11: nvidia0 cbb*"; 
throttling interrupt source
>   kernel: fwohci0: BUS reset
> 
> It's usually precipitated by my moving the laptop off my lap
> onto a table or otherwise wiggling the cable, which seems to
> be unpredictably sensitive.  (It never happens if there is no
> I/O going on at the time.)  I have no idea why it mentions the
> nvidia0 device.
> 

Look at the output of `vmstat -i` and you'll probably notice the fwohci0 
(or sbp(4)?) interrupt is shared with nvidia0 and other devices.

> When this happens, any I/O on the Firewire drive will hang
> indefinitely.  I can't fix it at that point; about all I can do
> is reboot. "fwcontrol -r" doesn't help any.  If I reboot the
> system, I always have problems syncing it; it complains about
> unwritten buffers or vnodes, and eventually I have to manually
> reset it.  When I come back up, I have fsck problems not only
> with the Firewire partitions but also /usr and others.
> 

The sbp(4) page tells us:
<quote>
"If you want to force to detach the device, run ``fwcontrol -r'' several 
times."
</quote>

Have You tried that? I'm interested in your experiences with firewire 
mass storage, because I don't (yet) have one but might be interested in 
getting some extra removable HD space. I am for some reason in the 
belief that firewire disks might perform better than their USB-2.0 
counterparts?

> You can say that I created the problem myself by manhandling the
> little plug or by even trying to insert it and remove it "hot."
> (Nobody said I could, nobody said I couldn't.)  But I can do
> this with Windows XP with no problems.  I also don't have any
> problems caused by wiggling the apparently very sensitive cable
> with XP.  I also didn't have the wiggling-cable problem under
> 4.X, although it's possible that mechanical degradation since
> that time is at fault.  (The hanging mount problem did occur
> under 4.X.)  I haven't posted this as a bug report because (a) I
> haven't had much luck with bug reports <sniff> and (b) I'm sure
> the answer would be "fix your hardware."
> 
> -- 
> J. Porter Clark      <jpc at suespammers.org>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to 
"freebsd-stable-unsubscribe at freebsd.org"
> 

-- 
marko [dot] vihoma [at] dnainternet [dot] net
BOFH excuse #144:

Too few computrons available