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!
Sounds like a kernel bug to me.
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.
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.
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.)
Thanks for the update Bill, changing status as requested...
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.
Created attachment 292966 [details] Log and Info From Second Desktop Large file copies work on my newer system (USB 2).
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....
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.
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.
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.
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.
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
This bug report can be closed. I think it has been fixed for some time.