Bug 128602

< feeding "control timeout on ep0in" into.
> feeding "control timeout on ep0in" into Google.

< All the same error, followed relevant chaos
< All the same error, followed by relevant chaos

Sorry .. long day.

*** Bug 127925 has been marked as a duplicate of this bug. ***

*** Bug 126933 has been marked as a duplicate of this bug. ***

I am able to get freecom usb2 harddisk to connect by unpluging it
after boot and replug it. 

Created attachment 102430 [details]
output log from kernel 2.6.7-1.449-2.2

This bug still persist with the lates update kernel, but I am able use
the usb hardisk by unplugin after boot and reconnect it. 

I have been able to use usb storage with kernel-2.6.7-1.509 by
disableing md and devicemapper.

Have just upgraded to FC2's kernel-2.6.7-1.494.2.2 and slammed about 3
Gigs of data into a USB connected hard drive. Didn't need to adjust
anything. Looks like it got fixed.

I'm using kernel 2.6.8-1.521, but I'm still getting the same symptoms
with my USB minidisc player.

Sadly I just got the same problem back again when I tried to use a
webcam on a machine with kernel kernel-2.6.8-1.521 .. so I have
reopened the report.

Is anyone seeing this who does *not* have gnome-pilot enabled?

If you are seeing this with gnome-pilot enabled then could you stop or
pause the daemon (right click on applet, select "Pause Daemon") and
see if things work better?

See thread starting at
 
http://mail.gnome.org/archives/gnome-pilot-list/2004-September/msg00000.html

Asked on USB lists about this.  See my request and the response:-
 
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg27976.html
 
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg27982.html

Response:-
It's a bug in 
the storage device -- the device can't handle a standard request (of the 
sort send by the /proc/bus/usb/devices driver when reading a device
string 
for the Vendor, Product, or Serial number) while the device is in the 
middle of a mass storage data transfer.  Devices are supposed to be able 
to do this; it's the equivalent of walking and chewing gum at the same 
time.  But some can't, and when asked to they simply fail.

So far nobody has come up with a really good solution.  There's nothing 
illegal about making these other requests during a data transfer, and 
plenty of devices can handle them just fine.  So we don't want to rule 
them out.  But in the end maybe we'll have to.

I have only a usb ps/2 optical mouse and a hub hooked up. the mouse is
recognized as usb1-1 and ep0in timeout is a result of the mouse. when
i have more devices installed it fails more often and usually durring
boot up. there doesn't seem to be a consensus on the cause of the
problem. perhaps its in the ohci module itself instead of any
individual device drivers.

*** Bug 110405 has been marked as a duplicate of this bug. ***

I have seen this problem with a couple of Microsoft Natural Pro USB
keyboards. It seems odd that all of these various devices (usb flash
drive, hard disk, web cam, keyboard, etc.) all have the same flaw. It
seems more likely that its a driver problem burried way deep down
somewhere.

The likelyhood of the manufacturers re-engineering all of these USB
parts to respond strictly according to the USB specs (if this is
indeed the problem) is extremely low. Blaming the hardware will not
really wash when the number of "faulty" items is this large. 

I got my mouse back! And it is a releif to be off the old ps/2 keyboard!

My HP Pavillion 7965 keyboard and mouse were both failing.

I did a 'roll back' on my kernel version to kernel-2.6.5-1.358 with

"rpm -e latest_kernel_upgrade"

While I had some problem booting again (kudzu was hanging), I got
round this in interactive mode, then I had to reinstal nvidia, now I
am back!

YAY!

During nvidia reinstall I did an 'init 3' and then 'init 5' kudzu ran
OK at that time... Now the real test... can I reboot and come back in
one piece...

I have had similar problems with FC2 since the start, trying to sync a
USB flash disk which works 100% reliably under FC1 on a physically
identical desktop (Dell Optiplex GX 270).  When I upgraded my FC2
kernel to 2.6.8-1.521smp, things got a lot better, and now I can
_sometimes_ use the usb flash disk (before, any attempt to use it
invariably crashed things).  However, the problem persists: if I
attempt a large transfer in one chunk, eventually things die.

It may well be that there are faulty devices out there, but it's quite
annoying to find that kernel 2.4 handled them just fine, and now I
can't sync my desktop and home machines with my typical lightweight
mechanism, a usb disk in my pocket.

Here is the kernel log relevant segment.  Upon device insertion:

Nov  4 15:16:06 planck kernel: usb 1-6: new high speed USB device
using address 5
Nov  4 15:16:06 planck kernel: scsi3 : SCSI emulation for USB Mass
Storage devices
Nov  4 15:16:06 planck kernel:   Vendor: USB       Model: Flash Drive
      Rev: 1.12
Nov  4 15:16:06 planck kernel:   Type:   Direct-Access               
      ANSI SCSI revi
sion: 02
Nov  4 15:16:06 planck kernel: SCSI device sda: 1015805 512-byte hdwr
sectors (520 MB)
Nov  4 15:16:06 planck kernel: sda: Write Protect is off
Nov  4 15:16:06 planck kernel: sda: assuming drive cache: write through
Nov  4 15:16:06 planck kernel:  sda: sda1 sda2
Nov  4 15:16:06 planck kernel: Attached scsi removable disk sda at
scsi3, channel 0, id 0,
 lun 0
Nov  4 15:16:06 planck kernel: Attached scsi generic sg1 at scsi3,
channel 0, id 0, lun 0,
  type 0
Nov  4 15:16:06 planck kernel: updfstab: Using deprecated /dev/sg
mechanism instead of SG_
IO on the actual device
Nov  4 15:16:06 planck kernel: updfstab: Using deprecated /dev/sg
mechanism instead of SG_
IO on the actual device
Nov  4 15:16:07 planck scsi.agent[4516]: disk at
/devices/pci0000:00/0000:00:1d.7/usb1/1-6
/1-6:1.0/host3/3:0:0:0


Then I initiate a large transfer.  After a while, I get:

Nov  4 15:20:45 planck kernel: usb 1-6: reset high speed USB device
using address 5
Nov  4 15:20:50 planck kernel: usb 1-6: control timeout on ep0in
Nov  4 15:20:50 planck kernel: usb 1-6: device not accepting address
5, error -71
Nov  4 15:20:50 planck kernel: scsi: Device offlined - not ready after
error recovery: hos
t 3 channel 0 id 0 lun 0
Nov  4 15:20:50 planck kernel: SCSI error : <3 0 0 0> return code =
0x50000
Nov  4 15:20:50 planck kernel: end_request: I/O error, dev sda, sector
561694
Nov  4 15:20:50 planck kernel: scsi3 (0:0): rejecting I/O to offline
device
Nov  4 15:20:50 planck last message repeated 3 times
Nov  4 15:20:50 planck kernel: Buffer I/O error on device sda2,
logical block 241529
Nov  4 15:20:50 planck kernel: lost page write due to I/O error on sda2

... with much more of the same.  Eventually, it ends with:

Nov  4 15:20:50 planck kernel: scsi3 (0:0): rejecting I/O to offline
device
Nov  4 15:20:50 planck last message repeated 108 times
Nov  4 15:20:50 planck kernel: usb 1-6: USB disconnect, address 5
Nov  4 15:20:50 planck kernel: scsi3 (0:0): rejecting I/O to device
being removed
Nov  4 15:20:50 planck last message repeated 184 times
Nov  4 15:20:50 planck kernel: updfstab: Using deprecated /dev/sg
mechanism instead of SG_
IO on the actual device
Nov  4 15:20:50 planck kernel: usb 1-6: new high speed USB device
using address 6
Nov  4 15:20:55 planck kernel: usb 1-6: control timeout on ep0in
Nov  4 15:20:56 planck kernel: usb 1-6: device not accepting address
6, error -71
Nov  4 15:20:56 planck kernel: usb 1-6: new high speed USB device
using address 7

I hope this helps,

f

Yup, the kernel roll back hasn't fixed all my problems. No GRUB dosn't
recognize my USB, and kudzu hangs...

if I use ps/2 to get past this, once booted everything is fine.

This problem has now cleared up - USB still OK on 2.6.5-1.358

which scanner work on remote desktop technology?

I am having the same problem as Fernando... Maybe it all this thin air
in Denver, lol.

I just upgraded to the latest FC3 kernel this morning.  When I plug in
a flash stick, this is what shows up in the /var/log/messages:

Nov 22 15:12:43 itmanager kernel: usb 2-1: new full speed USB device
using address 4
Nov 22 15:12:48 itmanager kernel: usb 2-1: control timeout on ep0out
Nov 22 15:12:54 itmanager kernel: usb 2-1: control timeout on ep0out
Nov 22 15:12:54 itmanager kernel: usb 2-1: device not accepting
address 4, error -110
Nov 22 15:12:54 itmanager kernel: usb 2-1: new full speed USB device
using address 5
Nov 22 15:12:59 itmanager kernel: usb 2-1: control timeout on ep0out
Nov 22 15:13:04 itmanager kernel: usb 2-1: control timeout on ep0out
Nov 22 15:13:05 itmanager kernel: usb 2-1: device not accepting
address 5, error -110

I see lots of messages stating that 2.6.9 is suposed to fix this, but
as you can see, that is what I am running, and it is not fixed:

$ uname -srv
Linux 2.6.9-1.681_FC3 #1 Thu Nov 18 15:10:10 EST 2004

Anybody have any idea what is going on here?

All of my USB devices are u/s under FC3 as well.

I'm experiencing the same problems since months now (already appeared
on  FC2). I tried a card reader, a Palm, my digital camera. It won't
work for a long time (meaning only for a couple of seconds, maybe a
few minutes). All devices work fine on my notebook. I'm using an Asus
P4B533 board if that helps. Kernel output of last prob:

usb 1-4.2: new full speed USB device using address 4
scsi1 : SCSI emulation for USB Mass Storage devices
  Vendor: KMCA      Model: DiMAGE Xg         Rev: 1.00
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sde: 121856 512-byte hdwr sectors (62 MB)
sde: Write Protect is off
sde: Mode Sense: 18 00 00 08
sde: assuming drive cache: write through
 sde: sde1
Attached scsi removable disk sde at scsi1, channel 0, id 0, lun 0
USB Mass Storage device found at 4
usb 1-4.2: control timeout on ep0in
usb 1-4.2: control timeout on ep0in
usb 1-4.2: reset full speed USB device using address 4
usb 1-4.2: device not accepting address 4, error -32
scsi: Device offlined - not ready after error recovery: host 1 channel
0 id 0 lun 0
SCSI error : <1 0 0 0> return code = 0x50000
end_request: I/O error, dev sde, sector 47
Buffer I/O error on device sde1, logical block 8
scsi1 (0:0): rejecting I/O to offline device
Buffer I/O error on device sde1, logical block 9
Buffer I/O error on device sde1, logical block 10
Buffer I/O error on device sde1, logical block 11

Kernel used: 2.6.9-1.649

The Logitech WingMan RumblePad joystick gives a similar error. Kernel
is 2.6.9-1.1018_FC4 on FC3. The original FC3 kernel behaves the same.

Dec  7 20:48:56 yeti kernel: usb 2-3: new low speed USB device using
address 3
Dec  7 20:49:01 yeti kernel: usb 2-3: control timeout on ep0in
Dec  7 20:49:06 yeti kernel: drivers/usb/input/hid-core.c: timeout
initializing reports
Dec  7 20:49:06 yeti kernel:
Dec  7 20:49:06 yeti hal.hotplug[4398]: DEVPATH is not set
Dec  7 20:49:06 yeti kernel: input: USB HID v1.10 Joystick [Logitech
Inc. WingMan RumblePad] on usb-0000:00:02.0-3

I just add a very similar (probably the same) into Ubuntu's Bugzilla;
see https://bugzilla.ubuntu.com/show_bug.cgi?id=4487

I can work around the problem by booting without USB devices attached,
then doing "modprobe -r uhci_hcd; modprobe uhci_hcd".  Then USB work
correctly.

Sadly this approach doesn't work with any of my USB devices. It allows
another burst of use, but they just drop out again before very long.

My FC1 and FC2 happy USB card reader has just become toast with FC3. 
Can't be sure I've ever used it with FC3 but now (2.6.9-1.681_FC3) I
get the following when I plug it in.  Never gets to a state that is
mountable

Dec 14 17:15:52 iri31 kernel: usb 1-6: new high speed USB device using
address 5
Dec 14 17:15:52 iri31 kernel: scsi2 : SCSI emulation for USB Mass
Storage devices
Dec 14 17:15:52 iri31 kernel:   Vendor: Generic   Model: STORAGE
DEVICE    Rev: 0113
Dec 14 17:15:52 iri31 kernel:   Type:   Direct-Access                
     ANSI SCSI revision: 02
Dec 14 17:15:57 iri31 kernel: usb 1-6: control timeout on ep0in
Dec 14 17:16:07 iri31 last message repeated 2 times
Dec 14 17:16:08 iri31 hal.hotplug[6624]: timout(10000 ms) waiting for
/devices/pci0000:00/0000:00:03.3/usb1/1-6/1-6:1.0
Dec 14 17:16:08 iri31 hal.hotplug[6626]: timout(10000 ms) waiting for
/devices/pci0000:00/0000:00:03.3/usb1/1-6/1-6:1.0/host2/2:0:0:0
Dec 14 17:16:12 iri31 kernel: usb 1-6: control timeout on ep0in
Dec 14 17:16:18 iri31 scsi.agent[6647]: Attribute
/sys/devices/pci0000:00/0000:00:03.3/usb1/1-6/1-6:1.0/host2/2:0:0:0/type
does not exist

Would you be able to confirm which FC2 kernels worked?

All my USB devices worked fine under FC1 with a 2.4 kernel, but were
no longer of any use under FC2 with a 2.6 kernel and haven't worked since.

Has nobody in the know heard anything more about when this issue is
set to be resolved? An OS that won't run a sizeable percentage of USB
kit on the market isn't going to fair that well in the desktop and
mobile space.

I used FC1 from release and found that I could use a USB device one
and a half times for any given boot.  mount/umount/mount but then a
umount would simply hang.  No errors reported.

FC2 I used from release and updated through every kernel release
without noticing a problem.

Now I am completely unable to use the card reader.  I've had no
problems with a USB ethernet adapter on the same machine.

Folks,

I think this bug report is getting lost under a pile of only
semi-related stuff.

There were changes which affected USB that went in at
kernel-2.6.9-1.678_FC3
For example see Bugzilla #140005

I suggest folks try with an early FC3 kernel - for example
kernel-2.6.9-1.667 (which is the distribution kernel), and/or try with
 one of the recent testing kernels - for example
kernel-2.6.9-1.715_FC3 which can be found in
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/3/i386/

That should help bottom out whether people are seeing a transitory
problem that was broken in the FC3 updates, or the long term problem
that this bug entry was originally opened for.  I must admit I have
totally lost track on this one :-/

I cannot prevent users from reopening random bugs because they
know no better. Andrew's problem was fixed, the bug was closed.

There may be a gazillion reasons why controls time out, every
one has to have a bug to be trackable.

Unfortunately, all Bugzilla materials suggest users to attach to
existing bugs instead of opening new ones, which backfires badly
in a case such as this.

I have been having the same problem as stated in original bug.  I am
now using FC3.  I think the error message is a bit of a red herring. 
It has everybody looking for timeout problems in other things that may
be stopping hotplub from working, but I think it is a problem with
hotplug or sysfs letting go of the node.  (bear with me, I don't know
anything about code or device drivers, or how to say these things
properly)

OK, it seems the USB device gets recognised and added as, say, scsi3
to start with.  When it is removed, then plugged back in again later
it is being added as scsi4, then again later as scsi5 ... etc.  Now,
when it is removed I thought it should allow it to use the same ID
again, ie scsi3, but it keeps increasing the name by one number.  It
timeouts because it keeps waiting for a device in SYSFS that is not
present, and is not being created.

When I had FC2, I could plugin and remove my USB pen as many times as
I liked and it kept finding it OK, with the number increasing each
time.  I remember seing it at address 3 to start with and at the end
of the day at address 16 one time.

WHY?  No matter how many times it is pluged and removed, it should
remain at the same address, shouldn't it, assuming no other devices
had been attached?

BTW, a reboot allows the usb pen to be used once before error recurrs.
 If I wanted to continually reboot I would be using MS :-)

Some problem w/FC3 2.6.9-1.681_FC3. 

Insert the USB Memory stick (multiple memory sticks affected), it
mounts fine.  Properly unmount the memory stick (umount /dev/sda1) and
reinsert  later... dmesg reports "usb 1-1: control timeout on ep0in".  

Nothing but rebooting will fix this issue after ONE SINGLE USE of
memory stick.

Have you tried rmmod'ing all the USB kernel modules out of the kernel
and trying again. It does seem to work for others.

In answer to:


> Pete Zaitcev (zaitcev)  on 2004-12-15 06:48 -------
>
> I cannot prevent users from reopening random bugs because they
> know no better. Andrew's problem was fixed, the bug was closed.

The user that reopened this random bug was me. See comment #10

> There may be a gazillion reasons why controls time out, every
> one has to have a bug to be trackable.

I think the point being made here is that 2.6 is a disaster area wrt
USB devices. I have a bunch of (currently idle) USB devices that
worked just fine under k2.4 and most of them fail with this error
message under k2.6.

> Unfortunately, all Bugzilla materials suggest users to attach to
> existing bugs instead of opening new ones, which backfires badly
> in a case such as this.

When users have only got this fairly nodescript error message to go
on, how do they know to do anything different. They match the error
they see to the bugzilla database and find this report. If someone has
a reason why a specific USB device fails under 2.6 and works under 2.4
then they can surely break off a new report. Until then, they all look
the same to me and most of the others on this copy list .. ignorant or
otherwise.

> I think the point being made here is that 2.6 is a disaster area wrt
> USB devices. I have a bunch of (currently idle) USB devices that
> worked just fine under k2.4 and most of them fail with this error
> message under k2.6.

Since my comment (#33), I have reloaded FC2 (because of Hal, selinux
and this issue), compiled in 2.6.9 and am now able to hotplug USB
devices to my hearts content.

This is clearly an issue with FC3, not a 2.4 v 2.6 issue.

Changes in FC3 with how it handles 'hotplug', SYSFS and 2.6 would seem
to be the issue.  

Unfortunately, I haven't the skills to fix it.

Sorry to be the bear of bad news.  My Amd Athon Irongate Motherboard
hates 2.6.9 kernels with a passion list of problems.

Having a Canon N1220U scanner Connected.

Install disk fails yep stalls completely ie first disk update is
required to fix or removing usb devices.

Also stalls at kudzu and cups if a usb device is attached due to
/proc/bus/usb/devieces<spelt wrong there is only one file in this
directory starting with d> being down found this out by login as
single and trying to cat file and locking system up and it is a file
that sould always cat.

This is a reported fault in 2.6.9 kernels with partical Motherboards
2.6.10 is ment to fix this and it does for me.

"usb 1-1: control timeout on ep0in"  Yep is a mesage that appears over
time verry randomly if the usb device worked in the first place ie
/proc/bus/usb/001/ has files 001 and 002 not just 001.

Upgrade to a standard 2.6.10 everthing is working fine except missing
Tux and other features.

There is a HotPluging fault with the new kernel(2.6.10) ie a
prehotplug fault If my scanner is attached on startup it is not
changed to my current user.  This is a pain in the but not having the
scanner follow my user might be a fault with how hotplug and udev works.

I hope this helps because I want a working kernel with all features
soon.  Note Please consider putting Fedora out with a Standard Kernel
ie tell you if the fault is in the standard or you mods how I started
to locate it rebuilt 2.6.9 from standard and it still did not work so
I went to kernel.org and look threw the faults there.

Question is how many of these fault are being cause by this fault in
the standard kernel.

I have an hp5550 connected thru a wireless USB port. It worked fine with Core 2
but, after the upgrade to Core 3, the message appears and the printer queue
dies, at somepoint, it finds the printer again and tries to install it
automatically ending up with several print queues of the same device and unable
to print. Atthis point I will upgrade to 2.6.9-1.724 to see if it fixes the
problem. I have 2.6.9-1.681 at this time

I just started having problems with an external keyboard (ps2, but
connected using a ps2->usb converter) since the last kernel update or
two - I type keys and they are missing or keys repeat indefinitely.  I
am currently using kernel-2.6.10-1.737_FC3 and, yes, I use
gnome-pilot.  Pausing the daemon has helped so far.

What is the status of this bug?  The last comment from redhat makes it
seem that I should open a new bug report on this.  Is this the case?

And, yes, I get:

usb 3-1: gpilotd timed out on ep0in
usb 3-1: gpilotd timed out on ep0in

Status is that I haven't done anything to help Andrew out since the
time he reopened this but, at least not directly.

Most of these problems are concurrent access problems. A few devices
get their panties in a wad when two URBs are queued to them, usually
a control and a bulk. Then one of those times out. The problem is
magnified by the fact that simple cat-ting of /proc/bus/usb/devices
creates a flurry of controls to read uncached descriptors.

In 2.4 we carry a separate patch which simply locks out devices
for access, but in 2.6 I hoped to be more in line with upstream.

Also I suspect Andrew's problems may be different, remember that
has a "bunch" of devices in comment #36, so obviously it must be
something else. So, yes, I'd like separate bugs by people who're
willing to track, run tests for me, etc.

Well, I created a separate bug report for my keyboard+gpilotd problems
(bug #144943), but got no response, so I am just going to add my
comments here.  If you don't like it, ....

In addition to my keyboard+gpilotd problems, I am also having card
reader+gpilotd problems.  If I put in my Kingston SD 512 MB card +
card reader while the gpilotd daemon is active, the card will become
inaccessible after a few seconds.  If I pause the daemon first, I
don't have any problems.

I am willing to help debug this and even make a separate bug report if
someone can convince me it is worth the effort.

I am now running two identical machines with FC3 on one and FC2 on my
main machine.

On the FC2 machine, regardless of the kernel, rpm or vanilla, 2.4 or
2.6 (right up to 2.6.10), all usb devices work and play properly.  I
am able to plug in and remove pens, card readers and scanners to my
hearts content and they work.

On the FC3 machine it does not matter what kernel I use, the usb pen,
card reader & scanner all work once then won't go a second time, with
error regarding timeout on ep0in.

Both machines are setup with the same boot options, except FC3
requires HAL to work properly.

Is the problem to do with HAL, it being a Hardware Layer?  What I do
know is, without a doubt, it is something in FC3 that is causing my
problems with "control timeout on ep0in"

It would help if anybody could state what 'ep0in' is, or does.

Also, regardless of the 'Fixed In:' statement below, it does not seem
to matter what kernel I use, and I have literally tried ALL the rpm
kernels, plus kernel.org kernels from 2.4.12 up to, and including, 2.6.10.
I find it really strange when people keep complaining about kernel 2.*
being hopeless with respect to USB, when I am finding it is the
distribution and how it intereacts with the kernel. Changes in FC3
with how it handles 'hotplug', SYSFS and USB would seem
to be the issue.

What changes where there in FC3 from FC2 in how USB and 'hotplug'
work, this seems to be the problem.

The following information is only slightly FC related but posted for
interest this problem also occurs on some machines with Mandrake 10.1
using kernel 2.6.8.

Case 1:-  old Dell Optiplex Intel Chipset memory USB memory sticks
work fine.

Case 2:   New Dell Latitude 600 USM memory stick works fine.

Case 3   Old AMD Athlon board + lot of SCSI disks. USB memory sticks
mount fine but will timeout even when not accessed, if the stick is
then removed the whole computer locks up.

Case 4: Same machine as above with stock FC3 same result i.e dies with
USB memory sticks.

Case 5 Same machine as above with Mandrake 10.0 early 2.6 kernel 5 as
I remember and devfs not udev worked fine.

Not sure where this leads us

I found this little gem tonight, could it be related?

< http://www.fedoraforum.org/forum/showthread.php?t=31220 >
<snip>
 USB 2.0 problems - SOLVED!
Well, this took me longer than I wanted to find the answer, but I
found the solution to 2 problems - using USB 2.0, and the problem
where flash drives were recognized the first time they were plugged
in, but if you unplugged the drive, it wouldn't recognize it again. I
turned off acpi. I went into System Settings -> Server Settings -
Services -> and unchecked acpid and saved it. I also went into
/boot/grub/grub.conf and added acpi=off to the kernel line. Now, my
USB 2.0 flash drive (SanDisk 1.0GB) works great! the icon pops up on
the desktop instantly, and it's running at USB2.0 speeds. I unmounted
it, unplugged it and plugged in back in 3 times and it worked every
time. For those with inquiring minds, it was related to interrupts.
Apparently, acpi is stepping on the interrupts that the USB system
uses. That was the cause of both problems. That's probably also why my
PC never shut off automatically like it's supposed to (because acpi is
used to do that). I found the solution at
http://www.linux-usb.org/FAQ.html#ts6
Hope this helps everyone else out there with the same problem.
<snip>

I would test it, but I have taken FC3 off my other machine and do not
want to put FC3 back until this is resolved.

Yes comment #45 may be related, but only if Andrew Meredith confirms.
Somehow I suspect we won't get away "with closed - bad ACPI".

Well, I can confirm that acpi=off doesn't solve this kind of problem
in all cases.  It may take a while to see it, though.  I created this bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144866

but since there has been no reply there, I'm posting here where there
seems to be more activity.

To summarize my woes with usb storage devices:  using an Apacer Handy
Steno 512 MB USB 2.0 flash drive causes filesystem corruption and data
loss under Fedora 3, BOTH on a Dell optiplex GX270 (USB 2.0) and on an
old Dell Inspiron 4100 laptop (USB 1.1 only).  I am using kernel
2.6.10-1.741_FC3 (though I've been testing pretty much every FC2 and
FC3 kernel and the problem ALWAYS appears, it only takes longer to
show up sometimes).

I must note that the devices can be mounted normally, and appear to
operate fine for a while.  But once a large transfer is initiated (I
use it to sync my home and office machines with an rsync script),
eventually the 'ep0in timeout' messages pop up in /var/log/messages,
and after that all hell breaks loose.  The filesystem is irreparably
hosed.

I've tried many kernels, and all apm/acpi combinations.  The USB flash
disk is not at fault, since it works 100% of the time with an
identical desktop which I've kept using RedHat 9.0.  Also, the same
laptop was running Fedora1 until a few days ago, and it handled these
devices fine, so I am pretty much sure the hardware is not at fault.

I have encountered more usb-storage problems, which I suspect are
related.  I plugged two different external USB IDE enclosure into the
Dell Optiplex 270 (Feodora 3), which needed fsck to be run.  Upon
attempting to run fsck, the process simply hung silently.  I could not
kill it, suspend it or otherwise get the terminal back.  

Furthermore, I could not even reboot the box.  It appeared fully
responsive (KDE kept working normally), but since I suspected kernel
problems, I decided to logout and reboot.  The shutdown process
started, but all I got was the red text message saying 'please wait
while system shuts down' (or something like that).  After that,
nothing.  Not a single step of the shutdown process completed, and I
had to power cycle the box.  I had been monitoring /var/log/messages
all along, and there was never a single message generated, so this is
all the information I can provide.

The same external USB IDE enclosures worked fine afterwards when
plugged into the RedHat9.0 box.  I could fsck them, and then transfer
about 20GB of data to each without a single glitch (at usb2.0 speeds).

Finally, trying to use PCMCIA cards to access these external devices
is also failing.  I have a USB2 and a Firewire PCMCIA card, both of
which worked fine under Fedora1.  Now both of them cause instant
kernel panics.

In summary, the status of external storage devices under Fedora3
(kernel 2.6.10-1.741_FC3) is an absolute, utter disaster.  Data loss,
filesystem corruption, kernel panics, hung systems, etc.

I realize that Redhat has a strong policy of following closely the
upstream kernel, and I understand the rationale behind it.  But in
this case, if you can at all come up with an in-house patch which
restores the functionality of FC1, I beg you to do so.  The current
situation is really a mess, and it is causing at least me (and
probably many others) literally weeks of headaches and forcing us to
keep a frankenstein environment littered with Redhat9 boxes to handle
external storage.

I'll be happy to test newer kernels or provide more information.

Regards,

f

Even if acpi off helped, it only indicates a problem with ACPI, the
heart of which is a kernel module and therefore the bug should stay open.

Also, turning off power management (ACPI) is not an acceptable
solution for laptop users.

Pete - it appears that there are several people willing to try to
debug this problem.  What can we do?

Confirmed and additional info:
2.6.9-1.724_FC3 was the last 'working' kernel for external USB2 disk enclosures.
All kernels since that release will 'lock' the drive after any serious I/O, or
at a random time under very light I/O.

2.6.10-1.760_FC3 will in fact NOT shut down after this condition occurs.

2.6.10-1.753_FC3 and 2.6.10-1.741_FC3 would at least shut down after the drive
failed (or was shut off -- hard to tell with no logging).

The only USB errors in any log from any error that happened were:

hiddev96: USB HID v1.10 Device [Western Digital External HDD] on
usb-0000:00:1d.7-3.2
drivers/usb/input/hid-input.c: event field not found
drivers/usb/input/hid-input.c: event field not found

I have been getting those forever on FC3.  They do not seem relevent to the USB
storage issues.

My system:

DELL Latitude D600 512MB RAM

External enclosure is:
T:  Bus=01 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1058 ProdID=0400 Rev= 1.04
S:  Manufacturer=Western Digital
S:  Product=External HDD
S:  SerialNumber=574D41454B32353030333637
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=64ms

In addition, All kernels that I have used on FC3 exhibit the issue with only
mounting USB storage devices once.  After that, it often takes a reboot before
the system will see them again.

Could we please ask that new kernels are put out with a bit more usb-related
messages generated?  As I said, I can install and test a new kernel, but it's
kind of difficult to provide useful info when the kernel simply locks up
silently, with exactly _zero_ messages.

I'd like to do my part in seeing this disastrous situation resolved, but I don't
have the time to manually modify kernel sources for print statements (nor do I
know the kernel sources, so it would take me a lot of time to get that right). 
But releasing a 'noisy' kernel at this point, where the usb/storage system is
obviously broken, sounds like a good strategy to gather more info from us users.

Just a suggestion...

OK, I'm lost.  It seems that no matter how much it is shown to be a Fedora Core
3 (three) release problem, most people are still picking on the Kernel.  As I
have stated above, I have tried ALL 2.6.x (kernel.org & rpm) kernel versions in
both FC2 and FC3, and it is ONLY in FC3 that the problem occurs ....  IT DOES
NOT HAPPEN IN Gentoo, Mandrake or Suse, or FC2!

Ergo,  NOT A PROBLEM WITH THE KERNEL, BUT IN FEDORA CORE THREE (3) SOMEWHERE

OK?  Got it now?  I am not a coder or developer, so I can only go on what
happens here.  All the testing I have done points at FC3 ... If you can show me
where I have not tested properly, let me know ... I really would appreciate the
help, or at least the reason why my testing is showing the wrong result, or even
where my assumptions from that testing and results is wrong  :-)

I really do prefer RH/FC and want to update to 3, but not if I cannot use my USB
pluggable devices properly, especially the usb-pen.

Re comment 49 above:
"Confirmed and additional info:
2.6.9-1.724_FC3 was the last 'working' kernel for external USB2 disk
enclosures. All kernels since that release will 'lock' the drive after
any serious I/O, or at a random time under very light I/O."

This is unfortunately not the case for all usb devices.  Using this
kernel and a usb flash disk:

Feb  8 11:05:27 maqroll kernel: usb 1-1.3: reset full speed USB device
using address 4
Feb  8 11:05:32 maqroll kernel: usb 1-1.3: control timeout on ep0in
Feb  8 11:05:33 maqroll kernel: usb 1-1.3: device not accepting
address 4, error -71
Feb  8 11:05:33 maqroll kernel: scsi: Device offlined - not ready
after error recovery: host 0 channel 0 id 0 lun 0
Feb  8 11:05:33 maqroll kernel: SCSI error : <0 0 0 0> return code =
0x50000
Feb  8 11:05:33 maqroll kernel: end_request: I/O error, dev sda,
sector 261506
Feb  8 11:05:33 maqroll kernel: Buffer I/O error on device sda2,
logical block 91073
Feb  8 11:05:33 maqroll kernel: lost page write due to I/O error on sda2
Feb  8 11:05:33 maqroll kernel: scsi0 (0:0): rejecting I/O to offline
device

Message from syslogd@maqroll at Tue Feb  8 11:05:34 2005 ...
maqroll kernel: journal commit I/O error
Feb  8 11:05:33 maqroll kernel: Buffer I/O error on device sda2,
logical block 91074
Feb  8 11:05:33 maqroll kernel: lost page write due to I/O error on sda2

...

That's it, filesystem hosed.  As far as I've seen, there is simply NO
KERNEL in the 2.6 series, as shipped with Fedora 2/3, which can
reliably address usb storage devices like the 2.4 kernel series did.  

And yes, re. comment 51, I've seen all these same problems with
Fedora2, so this is most definitely a kernel (2.6x) issue. You may
have had good results with FC2, but I definitely had all these same
filesystem corruption problems there.  Under RH9/FC1, on the same
hardware, these devices (USB flash drives and external IDE enclosures)
work flawlessly.

Please, could we at least get some feedback from kernel devs on any
hope of resolution of this problem, or even a workaround?  I am
willing to mail you my specific USB flash disk if you want to test
with it (though I can hardly imagine that you can't reproduce the
problem, as I've seen it with _every_ usb storage device I have and on
_every_ computer I've run FC2 or FC3).

I recommended folks on cc: list to quit hogging Andrew's bug.
Devices not accepting addresses and EHCI quitting under load
are entirely different symptoms (and root causes). About the
only thing in common is the message about the control timeout.

I do not have any specific help requests at this time, as David
asked in comment #48. Please keep reporting problems as they
arise, and thanks for keeping it factual (e.g. like Phil did
with "2.6.9-1.724_FC3 was the last 'working' kernel"). I pin my
hopes at EHCI race fixes David Brownell develops, but I have
to have folks testing new releases to know how it goes. What would
help if you add /proc/bus/usb/devices so I can see what is hooked
to where precisely.

Regarding adding messages, as in comment #50, I am sceptical.
Go ahead and file RFE so I can attach a memo to it with an
explanation why it's a bad idea without polluting this bug.

Well, I'll gladly file the info in the most appropriate place, it's
just that I'm not 100% sure where that is.  Since all these problems
report with the same visible message, it's really hard for us regular
users (I'm not a kernel guy) to guess what the true root cause may be.

Data corruption is a nasty problem, and right now this is causing me
no end of grief here, to the point where I'm considering reverting all
of our boxes to FC1.  But I would _much_ rather do my little part to
help fix the problem once and for all, for everyone.  Hence my request
for some more detailed info in dmesg (or anywhere) so we can give you
guys better details.

I certainly don't want to "hog Andrew's bug", so if you can give us
more specific instructions on where to file this info, and how to
distinguish the various problems, I'll gladly comply.  For example, I
filed 

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144866

because the error message looked a bit different.  Should I continue
putting info there instead?  Even if the message looks like ep0in timeout?

And thanks for the /proc/bus/usb/devices tip, next time I test this
I'll file with that info.  I see kernel -762 is out in testing, I'll
give it a run and report, but please let us know exactly where and how
you want this information.  I _am_ trying to be useful...

Created attachment 111152 [details]
/proc/bus/usb/devices

cat /proc/bus/usb/devices caused kernel: usb 3-4: cat timed out on ep0in

Woah, what a long thread...  I have been searching for the answers to
two of my problems:  

1) repeated usb hub/port disconnect/reconnects that junk/redo my
keyboard and mouse every 2-3 hours

2) USB card reader that will not consistently read my CF card

I was not going to post here as I felt I did not have sufficient
information to pin down any results.  I have FC3 and have tried every
2.6.10-1_7?? kernel as they have come down the pipe.  But reading
Pete's suggestion to list /proc/bus/usb/devices made sense so I cat
the "file".  Guess what--it took 3 seconds and generated

Feb 16 20:40:27 ideq kernel: usb 3-4: cat timed out on ep0in

Nice, eh?  So attached is /proc/bus/usb/devices, and some kernel logs
of the problems I've been having.

Created attachment 111153 [details]
port 3 disabled by hub (EMI?)...

I get this kernel/hal/usb problem almost ever two hours in the log

The caching of strings is implemented in 2.6.12, so a rebase _will_ fix that
particular aspect of this mess. I just don't know when. I'm still working
on the rest and I sill need folks willing to test to file separate bugs
for every stable configuration which reporduces it.

Well, with kernel:

[~]> uname -a
Linux maqroll 2.6.11-1.14_FC3 #1 Thu Apr 7 19:23:49 EDT 2005 i686 i686 i386
GNU/Linux

I still get the usual (connect USB flash drive, try to transfer a bunch of files
to it, transfer seems OK for a few minutes, then boom):

root[log]# tail -f messages
Apr 13 02:22:20 maqroll kernel: sda: Write Protect is off
Apr 13 02:22:20 maqroll kernel: sda: assuming drive cache: write through
Apr 13 02:22:20 maqroll kernel:  sda: sda1 sda2
Apr 13 02:22:20 maqroll kernel: Attached scsi removable disk sda at scsi0,
channel 0, id 0, lun 0
Apr 13 02:22:20 maqroll fstab-sync[5576]: added mount point /media/flashdskwin
for /dev/sda1
Apr 13 02:22:21 maqroll fstab-sync[5580]: added mount point /media/flashdsk for
/dev/sda2
Apr 13 02:22:36 maqroll kernel: FAT: utf8 is not a recommended IO charset for
FAT filesystems, filesystem will be case sensitive!
Apr 13 02:22:36 maqroll kernel: kjournald starting.  Commit interval 5 seconds
Apr 13 02:22:36 maqroll kernel: EXT3 FS on sda2, internal journal
Apr 13 02:22:36 maqroll kernel: EXT3-fs: mounted filesystem with ordered data mode.
Apr 13 02:26:32 maqroll kernel: usb 1-1.3: reset full speed USB device using
uhci_hcd and address 4
Apr 13 02:26:37 maqroll kernel: usb 1-1.3: scsi_eh_0 timed out on ep0in
Apr 13 02:26:37 maqroll kernel: usb 1-1.3: device descriptor read/8, error -110
Apr 13 02:26:42 maqroll kernel: usb 1-1.3: scsi_eh_0 timed out on ep0in
Apr 13 02:26:42 maqroll kernel: usb 1-1.3: device descriptor read/8, error -110
Apr 13 02:26:42 maqroll kernel: usb 1-1.3: reset full speed USB device using
uhci_hcd and address 4

The funny thing is that once this happens, the device isn't even listed in 

[matplotlib-0.80]> cat /proc/bus/usb/devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=235/900 us (26%), #Int=  3, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.11-1.14_FC3 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 4
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0416 ProdID=5518 Rev= 0.08
S:  Product=USB HUB
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=255ms

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=1.5 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=045e ProdID=0063 Rev=18.17
S:  Manufacturer=Microsoft
S:  Product=Microsoft Wireless Optical Desktop 1.00
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   6 Ivl=10ms

If I remove the flash drive and replug it in, it now appears as (ommitting
identical output to above):

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=ffff ProdID=ffff Rev= 1.00
S:  Product=USB Flash Drive
S:  SerialNumber=123456789ABCDEF
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms


I'll gladly file any of this info either elsewhere or as a new bug, if it is
supposed to be a new one.  As I said above, since all I get from the kernel is
the same 'time out on ep0in', this seemed like the most natural place.

Still hoping for usable usb-storage support in the 2.6 series someday...

Not like there isn't enough information here already, but for the record: I
regularly encounter this problem in two ways.  One is when I'm uploading
pictures from my USB camera (a Canon Powershot A80).  If I don't move the (PS/2)
mouse during the upload, everything's fine.  As soon as I do, boom.  Almost 100%
reproducible.

Two is when I'm using my Wacom USB drawing tablet.  Occasionally, if (PS/2)
keyboard events occur at the same time as tablet events, boom.  Happens about
30% of the time.

I've tried acpi=noirq and pci=noacpi (and both together) with no luck.

I'm running 2.6.11.6 SMP on a Dell Dimension XPS2.

At risk of adding further noise to this overloaded bug, I'm recording the
precise circumstances in which I have first encountered this "control timeout on
ep0in" message:

1) I am running Fedora core 2 (kernel 2.6.9-1.6_FC2smp).  This has remained
unchanged for some months.

2) The error has not occurred before today.  I have confirmed this by grepping
debug-level syslogs since Feb 2004.  This despite usb being in heavy use
(backups to usb disk, and usb scanner and printer attached, plus occasional usb
downloads from digital camera).

3) The error is (almost) consistently provoked today by attempts to connect by
dlpsh(1) to a brand new Palm Tungsten T5.  Apart from slight use of a usb
keydrive, this is the first device I have used on the USB controller of my Dell
monitor.  However, I've also tried it on a motherboard USB controller directly,
with the same error.

4) In searching for this error on the web, I note that the author of
http://www.hollants.com/external_usb_controller_chips.html interprets it as
being linked to a problem he encounters also under Windows XP, and on a variety
of hardware, and with a variety of Linux distros, and which he therefore
attributes to flaws in some USB controller chips.  My previous happy experiance
(2, above) combined with the new error on both available USB controllers (3,
above) argues against this attribution.

5) I have tried stopping the acpid service (see comment 45) and doing
   modprobe -r ohci_hcd ehci_hcd usb_storage asblp
   modprobe ohci_hcd ehci_hcd usb_storage asblp
(inspired by comment 26, but without rebooting)  which has the side-effect of
causing gpilotd to restart (comment 11).  This combination of actions does not
prevent the problem recurring.  Likewise, pausing gpilotd does not prevent the
problem.

Here's hoping that this very specific set of circumstances can shed some light
on the problem.  If further information would help, just ask.

I came to the opinion that the only way to make people stop gluing
UBSOLUTELY UNRELATED bugs together is to remove the goddamn message.
Perhaps then they'll start filing bugs tracking actual symptoms
and not some stupid message which is absolutely inconsequential.

The very first line of Graham's comment #61 makes it clear that
he KNEW THAT HE WAS DOING THE WRONG THING and he did it anyway. WHY?!

At the risk of being irrelevent, after some time I have decided to use Gentoo
(stage1).At the risk of being irrelevent, after some time I have decided to use
Gentoo (stage1).  Took me four goes, but it is now up and working extrememly well.

This includes ALL usb devices working without a hitch.

I always figured it was something in the FC3 distro, and this just proves it to
me.  

BTW, the FC2 box still has no USB problems.

(In reply to comment #60)
> [...] when I'm uploading
> pictures from my USB camera (a Canon Powershot A80).  If I don't move the
> (PS/2) mouse during the upload, everything's fine.  As soon as I do, boom.
> Almost 100% reproducible.
> 
> Two is when I'm using my Wacom USB drawing tablet.  Occasionally, if (PS/2)
> keyboard events occur at the same time as tablet events, boom.

I've only been running it for a few minutes, but so far I've been unable to
reproduce either problem with kernel 2.6.12 -- yippee!

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

This is still an issue with FC4 kernels.

I updated the kernel to 2.6.12-1.1372_FC3, and I am no longer seeing this message.

As can be seen above, others were not so fortunate; myself among them.

(BTW, can the fixed in kernel-2.6.7-1.494.2.2 tag be removed?)

It doesn't fix it for me either, see my comments in:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144866

I should note that the 'timeout on ep0in' message did NOT appear this time.  I
have no idea whether that provides any relevant clues.

I am no longer seeing this problem on kernel 2.6.12 when using a USB harddrive
enclosure (Genesys Logic, Inc; Vendor=05e3 ProdID=0702).  I also have a Linspire
(Debian) computer with kernel 2.6.10 and I continuously have this problem.  At
least in my case, the 2.6.12 kernel clears up the issue.  The troubling part
about this bug is that after a while, it causes all processes using the device
to hang indefinitely.

OK, I can report definite improvements.  This is on Fedora 3, using:

planck[~/tmp]> uname -a
Linux planck.colorado.edu 2.6.12-1.1376_FC3 #1 Fri Aug 26 23:27:26 EDT 2005 i686
i686 i386 GNU/Linux

Note that using kernel .12-1.1372 I was still seeing the bug.

Now the situation is this:

- Using an external IDE USB2 enclosure with a 120 GB hard disk: all is OK. 
Read/write work, transfer rate is fine (around 15MB/s, typical for a hard disk),
and no strange lockups or error messages on the console.

- Using my 'Handy Steno' 512MB USB flash drive, I have:

  * No error messages whatsoever, trying both read and write operations on large
and small files.  Finally!

  * Read performance is normal (around 4MB/s for this device):

planck[~/tmp]> d wxPython-src-2.6.1.0.tar.gz
/scratch/local/home/fperez/tmp
-rw-r--r--  1 fperez 18452406 Sep 12 17:24 wxPython-src-2.6.1.0.tar.gz

planck[~/tmp]> date && cp --reply=yes ~/flashdsk/wxPython-src-2.6.1.0.tar.gz .
&& sync && date
Mon Sep 12 17:24:07 MDT 2005
Mon Sep 12 17:24:12 MDT 2005

  * However, _write_ performance is absolutely catastrophic, to the point of
being unusable.  The operation of copying the same file in the opposite
direction gives me this:

planck[~/tmp]> date && cp --reply=yes wxPython-src-2.6.1.0.tar.gz ~/flashdsk/ &&
sync && date
Mon Sep 12 17:24:56 MDT 2005
Mon Sep 12 17:37:38 MDT 2005

We go from 5 seconds to 13 minutes for the same operation.  Note that the
problem is not the device nor the computer: I just tested the exact same
operation on an identical box which is still running RH 9.0 (kernel
2.4.20-43.9.legacy), and it writes the same file in the same 5 seconds.  So the
bug is definitely in the current kernel's USB code.

So many thanks for the improvements.  

I only hope that the write performance can go back to normal, since a 20KB/s
write performance makes a 512MB USB stick essentially useless in practice.  But
we're well on our way to the functionality of 2003, so it's a definite
improvement ;)

Hmm, I hope this works for Andrew too.

The write performance is likely to be related to the "sync" option.
Some versions of HAL add an /etc/fstab entry with "sync" spelled out,
and the update kernel actually observes it now...

Dead on, Pete:

root@planck[/etc]# grep sda2 fstab
/dev/sda2               /media/flashdsk         ext2   
pamconsole,exec,noauto,noatime,sync,managed 0 0

I edited manually the fstab to remove 'sync' _before mounting_ the USB device,
and then mounted and repeated the same file copy test from yesterday.  The
results now:

planck[~/tmp]> date && cp --reply=yes wxPython-src-2.6.1.0.tar.gz ~/flashdsk/ &&
sync && date
Tue Sep 13 11:43:47 MDT 2005
Tue Sep 13 11:43:55 MDT 2005


Perfect.

Now the question is: from userspace, how should this best be handled?  The write
performance with sync is just unusable, but I'm sure there's a good reason
behind it being the default.  What should I do to get usable performance without
root access?  Is this something which can be configured system wide for HAL?

Some pointers to resolve this problem once and for all would be very
appreciated, now that we're so close.

Let's stay on topic here. In particular, I am yet to hear from Andrew.

Please see bug 167174 for the discussion of sync option for FAT,
and configuration of /usr/share/hal/fdi/*

I currently not in a position to test this as I have loaned out all of my USB
devices. They were no longer of any use to me as I did not have a machine to use
them with. I am in the process of getting them back. I will report when I have
devices to test with.

Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.

2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.

This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Closing per previous comment.