Guojun Jin
2009-Nov-18 07:46 UTC
8.0-RC3 USB lock up on mounting two partitions from one USB drive
Did newfs on those partition and made things worsen -- restore completely fails:
(I had experienced another similar problem on an IDE, which works well for 6.4
and 7.2, but 8.0.)
This dirve works fine under FreeBSD 6.4.
Is something new in 8.0 making disk partition schema changed?
g_vfs_done():da0s3d[READ(offset=98304, length=16384)]error = 6
g_vfs_done():da0s3d[WRITE(offset=192806912, length=16384)]error = 6
fopen: Device not configured
cannot create save file ./restoresymtable for symbol table
abort? [yn] (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scs
i status == 0x0
(da0:umass-sim0:0:0:0): removing device entry
ugen1.2: <DMI> at usbus1
umass0: <DMI Ultra HDD, class 0/0, rev 2.00/1.19, addr 2> on usbus1
umass0: SCSI over Bulk-Only; quirks = 0x0000
umass0:0:0:-1: Attached to scbus0
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <DMI Ultra HDD 1.19> Fixed Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C)
Device da0s3d went missing before all of the data could be written to it; expect
data loss.
99 23:19 sysinstall
100 23:20 newfs /dev/da0s3d
101 23:20 newfs /dev/da0s3e
102 23:21 mount /dev/da0s3d /mnt
103 23:21 cd /mnt
104 23:21 dump -0f - /home | restore -rf -
105 23:27 history 15
-----Original Message-----
From: Guojun Jin
Sent: Tue 11/17/2009 11:05 PM
To: freebsd-stable@freebsd.org
Cc: questions@freebsd.org; freebsd-usb@freebsd.org
Subject: 8.0-RC3 USB lock up on mounting two partitions from one USB drive
When mounting two partitions from a USB dirve, it can cause the drive access
lock up for a long time.
Details:
Terminal 1 --
term1# mount /dev/da0s3d /mnt
term1# cd /mnt ; rm -fr *
when rm starts, go to terminal 2 and do:
term2# mount /dev/da0s3e /dist ### this will hanging for a long time and USB
hard drive activity light is off.
After more than 1-2 minutes, mount returns, and the drive activity light is
blinking, thus removing is going on.
term2# ls /dist ### this will cause dUSB dirve hanging again -- no avtivity.
Similarly, ls will finish in a couple of miniutes or longer, the rm command
continues; but for a while, the drive
activity will stop again.
Reboot machine, repeat the above steps, and result will be the same. Reboot
machine again, and just mount one
partition, then doing "rm -rf *" without involve the second partition,
rm will finish quickly.
Has anyone obseved this behave on 8.0-RC?
-Jin
Guojun Jin
2009-Nov-18 08:23 UTC
8.0-RC3 USB lock up on mounting two partitions from one USB drive
When mounting two partitions from a USB dirve, it can cause the drive access lock up for a long time. Details: Terminal 1 -- term1# mount /dev/da0s3d /mnt term1# cd /mnt ; rm -fr * when rm starts, go to terminal 2 and do: term2# mount /dev/da0s3e /dist ### this will hanging for a long time and USB hard drive activity light is off. After more than 1-2 minutes, mount returns, and the drive activity light is blinking, thus removing is going on. term2# ls /dist ### this will cause dUSB dirve hanging again -- no avtivity. Similarly, ls will finish in a couple of miniutes or longer, the rm command continues; but for a while, the drive activity will stop again. Reboot machine, repeat the above steps, and result will be the same. Reboot machine again, and just mount one partition, then doing "rm -rf *" without involve the second partition, rm will finish quickly. Has anyone obseved this behave on 8.0-RC? -Jin
I will do, I also borrowed two other machiens -- one AMD two core laptop, and one P4 desktop -- for further testing. I will enable kernel coredump for all of them and will make cores available by end of today. -Jin -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Wed 11/25/2009 12:37 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote:> What other debug shall we turn on to analyze this problem.Are you able to extract the panic message? Try enabling dump on the swap partition. --HPS
Shall I fill a defect? or someone on this mailing list can take care of this problem before release. -Jin -----Original Message----- From: Hans Petter Selasky [mailto:hselasky@c2i.net] Sent: Thu 11/26/2009 12:20 AM To: Guojun Jin Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org Subject: Re: 8.0-RC USB/FS problem On Thursday 26 November 2009 08:30:52 Guojun Jin wrote:> Most crash had the same back trace. This is also true when USB access > hangs, then unplug the drive.I think from the backtrace that this is not an USB issue. It is a file-system issue. --HPS
I noticed that your machine also has an AMD CPU. Hopefully this may NOT imply something to the hardware. I will find more systems especially Intel CPUs to do further test. -----Original Message----- From: Stefan Esser [mailto:se@freebsd.org] Sent: Monday, November 30, 2009 12:18 PM To: Hans Petter Selasky Cc: freebsd-usb@freebsd.org; bugs@freebsd.org; freebsd-stable@freebsd.org; Guojun Jin Subject: Re: 8.0-RC USB/FS problem On 22.11.2009 10:47 Hans Petter Selasky wrote:> Other operating systems do a port bus reset when the device has aproblem. On> FreeBSD we just try a software reset via the control endpoint. I guessthat it> is a device problem you are seeing. The USB stack in FreeBSD is fasterthan> the old one, and maybe the faster queueing of mass storage requeststrigger> some hidden bugs in your device. > > When the problem happens try: > > sysctl hw.usb.umass.debug=-1I have observed USB lock-ups with several external drive enclosures that used to work with the old USB stack (and continue to work when connected to a Windows notebook, for example). (BTW: System is AMD X2 with Nvidia chip-set and i386 kernel.) In my case, hw.usb.debug=6 makes the drive work at some 4MB/s for any amount of data transfered, while hw.usb.debug=5 (and an ylower value) lets the drive pause for about 1 Minute per 100MB transfered. I wanted to test whether short delays inserted in the places with DPRINTFN(6, ...) make a difference, but will not get to it before the weekend. Regards, STefan