Bug 58789
| Summary: | usb compact flash reader (sandisk SDDR-31) locks system completely after read | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Brent Michalski <bugzilla> | ||||||
| Component: | kernel | Assignee: | Pete Zaitcev <zaitcev> | ||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Brock Organ <borgan> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.2 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | athlon | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2004-01-22 01:24:16 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Brent Michalski
2002-01-24 17:29:26 UTC
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. |