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): How reproducible: Always 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. Additional info: Link may help some, not the exact thing I am encountering though. http://groups.google.com/groups?hl=en&threadm=linux.kernel.20020110133534.C21482%40one-eyed-alien.net&rnum=3&prev=/groups%3Fq%3D%252B%2522SDDR-31%2522%2B%252Blinux%26hl%3Den 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". http://groups.google.com/groups?hl=en&selm=20010414213546.A1590%40devserv.devel.redhat.com 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. ----------------------------------------------- From: brian 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 CF card. 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 /mnt/cf. 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 <brian>
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 the console. 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. Comments: #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.