> I've been trying to debug a problem with USB attached mass-storage
> devices on my friends server. We originally saw the problem on snv_66
> but still see it on snv_74.
>
> While we saw the problem with a zpool on a USB device (a Maxtor one
> touch) we can reproduce it just using mkfs to create a UFS filesystem as
> well. We have tried different USB ports on the machine, and different
> drives (WD drive in a cheap Safecom enclosure).
>
> We get the following messages (regardless of drive/usb enclosure type):
>
> Oct 21 18:45:35 server scsi: [ID 107833 kern.warning] WARNING:
> /[EMAIL PROTECTED],0/pci1849,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL
> PROTECTED],0 (sd10):
> Oct 21 18:45:35 server SCSI transport failed: reason 'tran_err':
> retrying command
> Oct 21 18:45:41 server scsi: [ID 107833 kern.warning] WARNING:
> /[EMAIL PROTECTED],0/pci1849,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL
> PROTECTED],0 (sd10):
> Oct 21 18:45:41 server SCSI transport failed: reason 'timeout':
> retrying command
> Oct 21 18:46:42 server scsi: [ID 107833 kern.warning] WARNING:
> /[EMAIL PROTECTED],0/pci1849,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL
> PROTECTED],0 (sd10):
> Oct 21 18:46:42 server SCSI transport failed: reason 'timeout': giving up
> Oct 21 18:46:54 server scsi: [ID 107833 kern.warning] WARNING:
> /[EMAIL PROTECTED],0/pci1849,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL
> PROTECTED],0 (sd10):
> Oct 21 18:46:54 server SCSI transport failed: reason 'timeout': giving up
> Oct 21 18:47:00 server scsi: [ID 107833 kern.warning] WARNING:
> /[EMAIL PROTECTED],0/pci1849,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL
> PROTECTED],0 (sd10):
> Oct 21 18:47:00 server SCSI transport failed: reason 'timeout': giving up
> Oct 21 18:47:06 server scsi: [ID 107833 kern.warning] WARNING:
> /[EMAIL PROTECTED],0/pci1849,[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL
> PROTECTED],0 (sd10):
> Oct 21 18:47:06 server SCSI transport failed: reason 'timeout': giving up
>
> prtconf, smbios, prtdiag, scanpci output can be found at:
> http://nessieroo.com/usb-timeout
>
> We have tried setting the reduced command set in scsa2usb.conf but that
> didn't change the behaviour on snv_66 or snv_74.
>
> What should we be trying next for debugging this ? Any known issues ?
> While it would be nice to get the Maxtor onetouch to work if a different
> drive is needed that is fine but the goal is a zpool on a single USB
> device (this is a remote backup written to by rsync and we want ZFS
> features).
Hmm, according to scanpci output, the box is using ehci on an
nVidia chipset...
pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x10de device 0x03f2
nVidia Corporation MCP61 USB Controller
CardVendor 0x1849 card 0x03f2 (ASRock Incorporation, Card unknown)
STATUS 0x00b0 COMMAND 0x0006
CLASS 0x0c 0x03 0x20 REVISION 0xa2
BIST 0x00 HEADER 0x80 LATENCY 0x00 CACHE 0x00
BASE0 0xdfefec00 addr 0xdfefec00 MEM
MAX_LAT 0x01 MIN_GNT 0x03 INT_PIN 0x02 INT_LINE 0x0b
BYTE_0 0x49 BYTE_1 0x18 BYTE_2 0xf2 BYTE_3 0x03
And its a single cpu / single core box.
A wild guess: Has the user installed Casper's powernow driver?
I'm asking because I've observed similar timeouts:
- on AMD64 boxes with nVidia chipset integrated ehci
and
- powernow driver set to automatic (and cpu is idle),
or cpu forced to the slowest frquency
and
- Maxtor Personal Storage USB2.0 HDD
The timeouts never happen when I force the cpu frequency to anything
other than the slowest setting. That is, I've been using this shell
script hack to work around the usb timeout problem:
# avoid running in the slowest powernow state with the ASUS M2NPV-VM,
# for some reason that breaks usb on the maxtor usb backup hdd
date +"Backup is running: %T"
/usr/sbin/powernowadm manual
sleep 5
/usr/sbin/powernowadm slow
/usr/sbin/powernowadm faster
I was able to reproduce the same timeout / powernow issue using an
ASUS M2N-SLI deluxe mainboard.
Using the above powernowadm commands, the M2NPV-VM never again
had the timeout issue, and the Maxtor USB2.0 HDDs have been used for
writing about ~180GB each night, 5 times a week, for several month now.
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
