Bug 428533 - Large File Copy to USB (1.1) Memory Stick Fails
Large File Copy to USB (1.1) Memory Stick Fails
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Pete Zaitcev
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-12 17:59 EST by Bill Adams
Modified: 2008-11-26 15:04 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 15:04:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs and System Information From My Desktop (10.44 KB, text/plain)
2008-01-24 22:21 EST, Bill Adams
no flags Details
Log and Info From Second Desktop (6.37 KB, text/plain)
2008-01-25 12:57 EST, Bill Adams
no flags Details
dmesg From Old System Boot + Plug In of USB Drive (16.38 KB, text/plain)
2008-01-25 16:07 EST, Bill Adams
no flags Details

  None (edit)
Description Bill Adams 2008-01-12 17:59:40 EST
Good day.

I am trying to use livecd-iso-to-disk to create a bootable USB drive with F8.
During the copy of the squashfs.img, I eventually get an IO error and the copy
fails. I started looking at the system logs and eventually figured out that hal
is battling it out with other programs. Specifically, hal mounts the USB device
as async, puts lots of data into the buffer, and then the kernel pukes while
trying to sync up the data (perhaps cp is timing out while it waits?) This
happens around 160-200MB of reported copied file size.

I stopped haldaemon and tried the copy again (with -o sync on the mount command
line) and it worked fine.

The problem occurred with a vfat, ext2 and ext3 formatted USB memory stick.

The problem occurred with other USB type storage devices (Nokia 770) during
large file copies. I got around that problem by doing a sync after each file
copy (5MB MP3 files) so the buffer would not get too full.

I am not sure what the right answer is. It seems you'd want to mount removable
storage devices as "sync" anyway in case the user unplugs the device without
properly unmounting it. Or maybe it is a kernel issue?

I know FC6 also has this problem. Once I get F8 installed, I'll test it as well.

Thanks!
Comment 1 David Zeuthen 2008-01-12 19:23:24 EST
Sounds like a kernel bug to me.
Comment 2 Bill Adams 2008-01-13 15:10:33 EST
Slight change to what I saw...

I submitted the request while it was very slowly copying the .img file onto the
flash drive (yes my bad I assumed it would work all the way). I still got an IO
error at about 149MB.

I guess it is not a buffer problem.

Syslog from the error:

Jan 12 16:52:44 it kernel: usb 1-1.4: reset full speed USB device using uhci_hcd
and address 34
Jan 12 16:52:59 it kernel: usb 1-1.4: device descriptor read/64, error -110
Jan 12 16:53:14 it kernel: usb 1-1.4: device descriptor read/64, error -110
Jan 12 16:53:15 it kernel: usb 1-1.4: reset full speed USB device using uhci_hcd
and address 34
Jan 12 16:53:30 it kernel: usb 1-1.4: device descriptor read/64, error -110
Jan 12 16:53:42 it automount[1935]: expire_indirect: fstat failed: Bad file
descriptor
Jan 12 16:53:42 it last message repeated 3 times
Jan 12 16:53:45 it kernel: usb 1-1.4: device descriptor read/64, error -110
Jan 12 16:53:45 it kernel: usb 1-1.4: reset full speed USB device using uhci_hcd
and address 34
Jan 12 16:53:55 it kernel: usb 1-1.4: device not accepting address 34, error -110
Jan 12 16:53:55 it kernel: usb 1-1.4: reset full speed USB device using uhci_hcd
and address 34
Jan 12 16:54:06 it kernel: usb 1-1.4: device not accepting address 34, error -110
Jan 12 16:54:06 it kernel: sd 9:0:0:0: scsi: Device offlined - not ready after
error recovery
Jan 12 16:54:06 it kernel: sd 9:0:0:0: [sdb] Result: hostbyte=DID_ERROR
driverbyte=DRIVER_OK,SUGGEST_OK
Jan 12 16:54:06 it kernel: end_request: I/O error, dev sdb, sector 319798
Jan 12 16:54:06 it kernel: usb 1-1.4: USB disconnect, address 34
Jan 12 16:54:06 it kernel: scsi 9:0:0:0: rejecting I/O to dead device
Jan 12 16:54:06 it kernel: scsi 9:0:0:0: rejecting I/O to dead device
Jan 12 16:54:06 it kernel: FAT: Directory bread(block 15488) failed
Jan 12 16:54:06 it kernel: scsi 9:0:0:0: rejecting I/O to dead device
...


I also tried to just dd the image:

[root@it boot]# dd if=squashfs.img of=/dev/sdb
dd: writing to `/dev/sdb': Input/output error
389665+0 records in
389664+0 records out
199507968 bytes (200 MB) copied, 660.907 s, 302 kB/s


Just make sure that the memory stick is ok:

[root@it boot]# /sbin/badblocks -v -w /dev/sdb
Checking for bad blocks in read-write mode
From block 0 to 3964416
Testing with pattern 0xaa: done                                
Reading and comparing: done                                
Testing with pattern 0x55: done                                
Reading and comparing: done                                
Testing with pattern 0xff: done                                
Reading and comparing: done                                
Testing with pattern 0x00: done                                
Reading and comparing: done                                
Pass completed, 0 bad blocks found.

Comment 3 Christopher Brown 2008-01-16 00:07:40 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

Thanks for taking the time to report this issue and for the debugging above -
I'm re-assigning to the USB subsystem maintainer in the first instance.
Comment 4 Bill Adams 2008-01-16 11:33:16 EST
Hey guys,

It seems this bug has been fixed in the F8 stock kernel (2.6.23.1-42.fc8). I
installed F8 on my Dell D620 and the large file copy worked fine (USB 2). I'm
going to install F8 on my desktop machine soon and will report back if it works
on that system (the one giving me problems) and also test this with an updated
F8 kernel.

The status should probably be set to NEEDINFO until I can do more testing. (I
cannot set the status myself since I am not the assignee.)
Comment 5 Christopher Brown 2008-01-16 11:43:56 EST
Thanks for the update Bill, changing status as requested...
Comment 6 Bill Adams 2008-01-24 22:21:13 EST
Created attachment 292909 [details]
Logs and System Information From My Desktop

Got F8 installed on my systems. Unfortunately the problem did not go away.
Attached is some info about my system in hopes that might help.

I am also open to compiling/installing different kernels possibly with patches
for testing.
Comment 7 Bill Adams 2008-01-25 12:57:22 EST
Created attachment 292966 [details]
Log and Info From Second Desktop

Large file copies work on my newer system (USB 2).
Comment 8 Bill Adams 2008-01-25 13:04:10 EST
The large file copy is still broken on my older system but now works fine on my
newer system (both systems are Fedora 8). I am not overly concerned about my
older system working since I have two others that work fine (my other desktop
and the previously mentioned laptop). However, if someone wants to work with me
on getting this working I am more than happy to put out the effort to do that
(test kernels, patches, etc.)

It is your call to leave open or drop this....
Comment 9 Pete Zaitcev 2008-01-25 14:18:50 EST
Actually, I thought about this a bit, just didn't write anything in the bug.
From the logs, the following happens:
 - we write dirty data
 - storage reset occurs (not a good thing, but it happens)
 - -110 on everything

The -110 on everything means that interrupts stopped arriving from UHCI.
It can mean a bug if we closed them in the controller by accident.

Another likely explanation is that SMM BIOS closes them. So I wonder
if the old system had so-called "Legacy mode" enabled. On boot we tell
BIOS to hand over the control over the USB, but some moterboards ignore
it. Naturally, it's nearly impossible to diagnose, esp. remotely.
Comment 10 Bill Adams 2008-01-25 16:07:01 EST
Created attachment 292997 [details]
dmesg From Old System Boot + Plug In of USB Drive

I checked the BIOS settings and "USB Legacy" was set to auto. I changed it to
"Disabled" and rebooted. The attached dmesg is from the boot in that
configuration + when I plugged in the USB device.

I tried the file copy (livecd-iso-to-disk) again and got the same result with a
bunch of error -110 in the kernel log.

There is a small, cheap USB hub sitting between the USB port and the device. I
see there is a new kernel available. I'll first upgrade to that, try it, and if
that fails, I'll try removing the USB hub and see if that changes my results.

For the record, my motherboard is an Asus A7M266 with BIOS version 1007. The is
newer version -- 1008.02b -- but it is beta from 2002 so I have little interest
in installing it.
Comment 11 Pete Zaitcev 2008-01-25 17:13:26 EST
Sorry to be wrong about BIOS. As for hub, if that fails and you fix it,
you may fix the original reset so that the problem does not occur in
the first place. But I don't see how a hub can make -110 to happen,
so that's something else.
Comment 12 Bill Adams 2008-04-11 14:04:11 EDT
I just successfully copied a 246MB file to the problem USB stick on the problem
computer (sans USB hub and a bunch of kernel versions later). We can close this
bug. Thanks for all of your help.
Comment 13 Bug Zapper 2008-11-26 04:25:02 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bill Adams 2008-11-26 11:29:59 EST
This bug report can be closed. I think it has been fixed for some time.

Note You need to log in before you can comment on or make changes to this bug.