From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221
Description of problem:
Card is recognized fine, mounts fine on /dev/sda1 for me. After transferring
50-75 files (30-50Mb) it stops responding. I found 1 similar item on NNTP, and
it said that the driver was timing out.
This is particularly bad because the ONLY way to recover from this is to hit the
reset switch. Logging in as root and shutting down the system does NOT work,
the system just hangs - waiting for the device I'm guessing.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system
2. Plug in reader with card
3. Start to copy files (about 100 files, 80Mb)
Actual Results: Mounts fine.
Begin to copy, fine.
Reader stops responding after 54 - 79 files.
NO way to unmount, or shutdown system except power (or reset) switch!
Expected Results: Files should copy without a system lockup.
Reader should unmount without any lockups.
Link may help some, not the exact thing I am encountering though.
Also, I am on RH 7.2, Athalon 1.0Ghz proc, 768Mb RAM.
Tried with 2.4.17, 2.4.16, 2.4.9(?) - same results.
As for severity, it DOES prevent you from rebooting your system, but it only
happens with this reader so I am leaving it at Normal for now..
I wish I had the HW. Requestor, are you in the
SF Bay Area by any chance?
No, I am in St. Louis, MO....
If you want, I can pop onto IRC tonight and step through the whole process. I
have to do any testing from home, since that is where the hardware is.
Here is the link I was really looking for. It appears that this person says it
is a "known issue".
i believe i've tried both uhci and usb-uhci without any success, but i will try
again this evening just to make sure i did.
No, only the printout is a known issue.
Other distros (such as Turbo) simply commented it out.
What causes it is not known (typically it's a STALL
handshake from a device, for a multitude of reasons).
We aquired SDDR-31, and it does seem to throw stalls, but only
when I change the card. Seem stable on transfers. But perhaps
my card is too small, only 8MB.
Potential tester, perhaps.
Date: Mon, 25 Mar 2002 12:19:47 -0800
I'm running Linux 2.4.19pre4 on a Sony VAIO FXA32
(Duron 900MHz with 384MB RAM)
When I plug a Sandisk SDDR-31 CF reader/writer in it is
recognized and much of the time I can read and write the
However, sometimes I get a usb_timeout while reading and
then all access to the device freezes. Things like the 'df'
command, or any attempt to access /mnt/cf causes the commands
to freeze up and become unkillable. Look to be in the D
state according to ps.
The rest of the system works so long as I stay away from
This happens with both the uhci and usb-uhci drivers.
% cp /mnt/cf/dc265_01/*.jpg /tmp
top kernel: usb_control/bulk_msg: timeout
top kernel: usb-uhci.c: interrupt, status 3, frame# 571
It had copied about 10MBs of data when the timeout occured.
Brian Litzinger <email@example.com>
Requestor, please do this:
0. Reboot with a Red Hat kernel (2.4.9-31 for instance)
1. "echo 1 > /proc/sys/kernel/sysrq"
2. Kill extra processes (exit X11)
3. Reproduce the problem
4. Hit <Alt><SysRq>T, this should spew a lot of output to
5. Collect the result with "dmesg > /tmp/05.d"
6. Collect symbols with "cat /proc/ksyms > /tmp/05.ks"
7. [do necessary corrective actions to get a working system,
such as "sync", reset]
8. Attach /tmp/05.d and /tmp/05.ks to the bug, but
PLEASE DO NOT DROP THEM INTO COMMENTS BOX.
#0 is needed for me to run ksymoops. The 05.ks is not going to have
necessary symbols, only module load offsets. ksymoops extracts
names from /lib/modules/*. If you can do ksymoops processing yourself,
you can use any kernel.
#2 is needed to reduce the amount of output. dmesg can be easily
overflown if too many processes exist.
I bought 256MB CF card, but cannot reproduce.
Will be working with junk cables now.
How is Alt-SysRq-T coming up?
Created attachment 76284 [details]
dmesg with sysrq-t
Created attachment 76285 [details]
ksymoopsed stacks, unfortunately lumped
Sorry to drop the ball on the bug. I am helping an issue
which I think may be similar in the community tree (in 2.4.19).
Attached dmesg is from Brian @worldcontrol.
It may be possibly fixed now, or at any rate, ther recovery from errors
should be fixed. Please try 2.4.20-18 errata (in your case 2.4.20-18.7).
One thing though, make sure that ehci-hcd is not meddling. It is known
to wreak havoc with some VIA based boards. Old kernels didn't have it enabled.
NEEDINFO for months - staled.