Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162559 - Transcend USB key; Current: sense key: No Sense
Summary: Transcend USB key; Current: sense key: No Sense
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-06 10:57 UTC by Patrick C. F. Ernzer
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-08-30 01:49:12 UTC

Attachments (Terms of Use)
part of /var/log/messages pertinent to this bug (deleted)
2005-07-06 10:58 UTC, Patrick C. F. Ernzer
no flags Details
dmesg under 2.6.12-1.1390_FC4 (deleted)
2005-07-11 13:42 UTC, Patrick C. F. Ernzer
no flags Details
dmesg under 2.6.12-1.1398_FC4 (deleted)
2005-07-18 06:21 UTC, Patrick C. F. Ernzer
no flags Details
the file pertinent to Comment #13 (deleted)
2005-08-11 14:30 UTC, Patrick C. F. Ernzer
no flags Details
Screenshot of garbage of the key (deleted)
2005-08-12 21:15 UTC, Giuseppe Castagna
no flags Details
Candidate #1 - workaround with setting removable to zero (deleted)
2005-08-18 21:33 UTC, Pete Zaitcev
no flags Details | Diff

Description Patrick C. F. Ernzer 2005-07-06 10:57:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
My Transcend 512 MB USB stick generates quite a few of the following messages:

Jul  6 13:51:56 a84-231-4-164 kernel: ioctl_internal_command: <7 0 0 0> return code = 8000002
Jul  6 13:51:56 a84-231-4-164 kernel:    : Current: sense key: No Sense
Jul  6 13:51:56 a84-231-4-164 kernel:     Additional sense: No additional sense information

should I worry about those?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. plug in USB stick
2. copy data off USB stick
3. umount USB stick (through nautilus context menu)
4. check syslog

Actual Results:  Many error messages (see attached /var/log/messages part, sprinkled liberally with logger commands that detail what is done when)

Expected Results:  No error messages

Additional info:

udev rule:
BUS="usb", SYSFS{serial}="MySerialNumber", KERNEL="sd?1", SYMLINK="pcfe-stick"

(obviously, in the real udev rule, MySerialNumber is the serial itself)

[pcfe@a84-231-4-164 ~]$ uname -r
[pcfe@a84-231-4-164 ~]$ rpm -q udev
[pcfe@a84-231-4-164 ~]$ rpm -q hotplug

Comment 1 Patrick C. F. Ernzer 2005-07-06 10:58:14 UTC
Created attachment 116403 [details]
part of /var/log/messages pertinent to this bug

Comment 2 Patrick C. F. Ernzer 2005-07-06 10:59:20 UTC
And the entries in /proc/bus/usb/devices that represents the stick:

[pcfe@a84-231-4-164 tmp]$ diff ~/tmp/mitkey ~/tmp/ohnekey
< T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
< D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
< P:  Vendor=0457 ProdID=0150 Rev= 1.00
< S:  Manufacturer=USBest Technology
< S:  Product=USB Mass Storage Device
< S:  SerialNumber=cd154831bbc41c
< C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 98mA
< I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
< E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
< E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
< E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=16ms

Comment 3 Pete Zaitcev 2005-07-06 17:31:46 UTC
In the future, please do not edit logs. Now I cannot trust them at all.
In this bug, this is probably immaterial, but only by luck.

Did this thing work with any other release? If yes, what kernel version?
The latter, the better.

Comment 4 Patrick C. F. Ernzer 2005-07-07 14:05:16 UTC

I currently have 2.6.11-1.35_FC3 (yes, an FC3 kernel on FC4) booted to be able
to sync my Tungsten T5 and the problem is also present there.

Do you want me to go through the other kernels I stil have on disk.

I cannot say for older FC releases as I only bought this USB stick after I
installed FC4 on my work laptop.

The only other machine I have available at this site is rather old (custom build
based on RHL 9 with kernel 2.4.20-33.9.CUSTMER)

I guess if the error exists in something that ancient this indicated a problem
with the stick and not the kernbel itself.

My original question remains;
  - should I worry about this
  - If there is nothing to worry, is there an easy way to mask these messages


P.S. when you say do not edit the logs, do you mean "do not use the logger
command to show what is being plugged when" or do you mean "do not crop an 800
KB /var/log/messasges down to the time you deem relevant to this bug"

Comment 5 Patrick C. F. Ernzer 2005-07-11 13:40:10 UTC
FWIW, problem persists under 2.6.12-1.1390_FC4.

dmesg output follows

Comment 6 Patrick C. F. Ernzer 2005-07-11 13:42:01 UTC
Created attachment 116601 [details]
dmesg under 2.6.12-1.1390_FC4

1) log onto VT1 as user
2) sudo su -
3) plug in USB stick
4) mount /media/pcfe-stick
5) copy some files off the stick
6) umount /media/pcfe-stick
7) dmesg > /tmp/dmesg.txt

Comment 7 Dave Jones 2005-07-15 21:45:32 UTC
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak

Thank you.

Comment 8 Patrick C. F. Ernzer 2005-07-18 06:19:01 UTC

problem persists under 2.6.12-1.1398_FC4

dmesg output follows

Comment 9 Patrick C. F. Ernzer 2005-07-18 06:21:57 UTC
Created attachment 116858 [details]
dmesg under 2.6.12-1.1398_FC4

1) boot
2) log onto VT1 as user
3) plug in USB stick
4) mount /media/pcfe-stick
5) copy some files off the stick
6) umount /media/pcfe-stick
7) dmesg > ~/tmp/dmesg.txt

Comment 10 Pete Zaitcev 2005-07-28 19:49:03 UTC
Patrick, I swear this bug sits on top of my list, but the swirl of patches
for the U2 keeps pushing it down every day. Please keep the reproducer
around for me a little longer...

Comment 12 Pete Zaitcev 2005-08-10 23:39:53 UTC
Can you get me usbmon trace of this? I'm afraid you better take a RawHide
kernel for it, however (I think FC4 has usb-storage which is resistant to
usbmon - you'll see a whole bunch of records tagged with 'D').

Another question... On the surface of it, everything seems fine, except
the key returns a check condition without actually returning a sense key.
This is not the end of the world, just somewhat out of line...
Is there any issue with data integrity or anything else _except_ the
silly messages?

Comment 14 Patrick C. F. Ernzer 2005-08-11 14:30:50 UTC
Created attachment 117648 [details]
the file pertinent to Comment #13

Comment 16 Giuseppe Castagna 2005-08-12 21:15:39 UTC
Created attachment 117693 [details]
Screenshot of garbage of the key

Comment 17 Giuseppe Castagna 2005-08-12 21:18:38 UTC
Same Key (but just 256M), same configuration, but different bug. The key appears
on the desktop but when I open it I obtain just garbage. See my previous
attached screenshot.
This is a FC4 bug. The key is formatted as vfat, but it contains stuff that I
saved on my FC3. Ah, and I have the same computer (my wife's one) still FC3 and
the key works as a charm

Sorry I'll be offline next forthnigh


Comment 18 Pete Zaitcev 2005-08-12 22:58:30 UTC
Giuseppe, file a new bug. Something is wrong with NLS or locale settings
on your box. Not a kernel issue (most likely).

Comment 19 Pete Zaitcev 2005-08-18 06:43:26 UTC
OK, usbmon trace says this:

c6e56100 3044521850 S Bo:003:01 -115 31 = 55534243 53000000 00000000 0000061e
00000001 00000000 00000000 000000
c6e56100 3044522037 C Bo:003:01 0 31 >
c6e56100 3044522052 S Bi:003:02 -115 13 <
c6e56100 3044522287 C Bi:003:02 0 13 = 55534253 53000000 00000000 01
c6e56100 3044522306 S Bo:003:01 -115 31 = 55534243 53000080 12000000 80000603
00000012 00000000 00000000 000000
c6e56100 3044522537 C Bo:003:01 0 31 >
c6e56100 3044522570 S Bi:003:02 -115 18 <
c6e56100 3044523038 C Bi:003:02 0 18 = 70000000 0000000a 00000000 00000000 0000
c6e56100 3044523078 S Bi:003:02 -115 13 <
c6e56100 3044523163 C Bi:003:02 0 13 = 55534253 53000080 00000000 00

The key replies with an empty sense to PREVENT ALLOW REMOVAL, known in

How about just suffering it, Patrick? I do not see a data integrity issue
here, because the I/O does not seem to be affected.

Comment 21 Patrick C. F. Ernzer 2005-08-18 20:57:44 UTC

certainly, my original question is fully answered. If the error does not mean my data is in danger we can 
close this as NOTABUG.


as you have a different bug (and I guess already opened one in response to Comment #18), you may 
want to post that bug number here, for other users who are following this and who are experiencing 
your bug and not mine, just so that they find your bug easily.


Comment 22 Pete Zaitcev 2005-08-18 21:33:23 UTC
Created attachment 117889 [details]
Candidate #1 - workaround with setting removable to zero

FC4 has a new and shiny flag which I think I can abuse for our purposes...

Comment 23 Patrick C. F. Ernzer 2005-08-22 16:02:02 UTC
sorry for the delay in verifying this, was a bit swamped.
The patch works for me, I applied it against 2.6.12-1.1398_FC4, built an smp
kernel and I have no more cruft in my syslog when I use the USB stick in question.

Comment 24 Pete Zaitcev 2005-08-23 00:24:18 UTC
Thanks. I sent this to Phil Dibowitz, to have it recirculated through upstream.

Comment 25 Dave Jones 2005-08-26 23:15:06 UTC
fixed in cvs, will be in next build.

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