Bug 58789 - usb compact flash reader (sandisk SDDR-31) locks system completely after read
Summary: usb compact flash reader (sandisk SDDR-31) locks system completely after read
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: athlon Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-01-24 17:29 UTC by Brent Michalski
Modified: 2007-04-18 16:39 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-22 01:24:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg with sysrq-t (15.14 KB, text/plain)
2002-09-16 20:48 UTC, Pete Zaitcev
no flags Details
ksymoopsed stacks, unfortunately lumped (14.94 KB, text/plain)
2002-09-16 20:50 UTC, Pete Zaitcev
no flags Details

Description Brent Michalski 2002-01-24 17:29:26 UTC
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:

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.

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..

Comment 1 Pete Zaitcev 2002-01-24 17:52:13 UTC
I wish I had the HW. Requestor, are you in the
SF Bay Area by any chance?

Comment 2 Brent Michalski 2002-01-24 18:27:11 UTC
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.

Comment 3 Brent Michalski 2002-01-24 19:02:11 UTC
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.

Comment 4 Pete Zaitcev 2002-01-24 19:07:49 UTC
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).

Comment 5 Pete Zaitcev 2002-03-13 21:00:51 UTC
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.

Comment 6 Pete Zaitcev 2002-03-26 18:09:14 UTC
Potential tester, perhaps.

From: brian@worldcontrol.com
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

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@worldcontrol.com>

Comment 7 Pete Zaitcev 2002-04-04 01:46:48 UTC
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


#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.

Comment 8 Pete Zaitcev 2002-05-29 02:40:28 UTC
I bought 256MB CF card, but cannot reproduce.
Will be working with junk cables now.

How is Alt-SysRq-T coming up?

Comment 9 Pete Zaitcev 2002-09-16 20:48:22 UTC
Created attachment 76284 [details]
dmesg with sysrq-t

Comment 10 Pete Zaitcev 2002-09-16 20:50:41 UTC
Created attachment 76285 [details]
ksymoopsed stacks, unfortunately lumped

Comment 11 Pete Zaitcev 2002-09-16 20:53:03 UTC
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.

Comment 12 Pete Zaitcev 2003-06-04 04:05:47 UTC
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.

Comment 13 Pete Zaitcev 2004-01-22 01:24:16 UTC
NEEDINFO for months - staled.

Note You need to log in before you can comment on or make changes to this bug.