Bug 156831 - sd _mod doesn't handle removable drives (USB floppy) well
sd _mod doesn't handle removable drives (USB floppy) well
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2005-05-04 11:41 EDT by Wendy Cheng
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 11:02:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a simple and plain program to demonstrate the problem. (305 bytes, text/plain)
2005-05-04 11:41 EDT, Wendy Cheng
no flags Details
The agreed patch to address this issue. (558 bytes, patch)
2005-05-04 11:46 EDT, Wendy Cheng
no flags Details | Diff
The original proposed patch made by Dell's Stuart Hayes. (1.77 KB, patch)
2005-05-04 11:53 EDT, Wendy Cheng
no flags Details | Diff

  None (edit)
Description Wendy Cheng 2005-05-04 11:41:11 EDT
Description of problem:
When a program attempts to open a USB floppy device (with something like 'open
("/dev/sdb", O_RDWR)'), and there is no media present in the drive, the system
doesn't generate the correct response--it allows the drive to be opened, and a
lot of error messages are spewed as the system attemts to "revalidate" the drive. 

Version-Release number of selected component (if applicable):
all the RHEL 3 releases.

How reproducible:
Always.

Steps to Reproduce:
1. (test program attached)
2.
3.
  
Actual results:
The "open" of user mode application returns success code but lots of error
messages in /var/log/messages file.

Expected results:
The open call fails with ENOMEDIUM error with errors in /var/log/messages subside.

Additional info:
Comment 1 Wendy Cheng 2005-05-04 11:41:11 EDT
Created attachment 114022 [details]
a simple and plain program to demonstrate the problem.
Comment 2 Wendy Cheng 2005-05-04 11:46:53 EDT
Created attachment 114023 [details]
The agreed patch to address this issue.

There have been discussions about this issue in the IT and the team (and
customer) has agreed with the uploaded patch.

Pete Zaitcev in the engineering end has been looking into this issue.
Comment 3 Wendy Cheng 2005-05-04 11:53:14 EDT
Created attachment 114024 [details]
The original proposed patch made by Dell's Stuart Hayes.
Comment 6 Wendy Cheng 2005-05-04 12:05:36 EDT
(3-3) updated by Dell's Stuart Hayes

That patch doesn't stop the ugly messages, though it does appear to cause the
right error code to be returned.  With this code:

fd = open ("/dev/sdb", O_RDWR);
if (fd<0) perror ("");

I get the following output on an unmodified 2.4.21-20.ELsmp:

sdb : READ CAPACITY failed.
sdb : status = 1, message = 00, host = 0, driver = 08
Current sd00:00: sense key Not Ready
Additional sense indicates Medium not present
sdb : block size assumed to be 512 bytes, disk size 1GB
sdb: Write Protect is on
I/O error: dev 08:10, sector 0
unable to read partition table
Read-only file system

With the smaller patch immediately above, I get this:

sdb : READ CAPACITY failed.
sdb : status = 1, message = 00, host = 0, driver = 08
Current sd00:00: sense key Not Ready
Additional sense indicates Medium not present
sdb : block size assumed to be 512 bytes, disk size 1GB
I/O error: dev 08:10, sector 0
unable to read partition table
No medium found

And with my patch that mimics what is done in the 2.6 kernel, I get this:

No medium found


So I think my original patch is better, but if you're worried about it breaking
something and prefer the smaller patch, I guess it is fine..
Comment 8 Pete Zaitcev 2005-05-04 15:31:19 EDT
I understand what Stuart is saying in comment #6. My concern is with the
"goto sd_init_onedisk_no_media;" regarding things like Fujitsu's MO drive
and stuff... That's why I proposed the minimal patch.
Comment 9 Ernie Petrides 2005-05-04 15:32:02 EDT
Pete, please remember to add the appropriate kernel pool maintainer
to the cc: list when (re)assigning bugs from "kernel-maint".  Thanks.
Comment 10 Stuart Hayes 2005-05-04 15:40:03 EDT
Pete may have a point, I'm not familiar with the Fujitsu MO drive.  His patch 
seem to address the real issue, in that it prevents the drive from being 
opened and returns the right error code.  I don't think anyone is going to 
complain about the extra error messages.
Comment 11 Pete Zaitcev 2005-05-19 17:26:30 EDT
OK, this bug is on track to fix the open(2). I'm posting for internal
acks right now, to target U6.

Regarding messages, they are very annoying, no question. Worse, they
eat into my precious dmesg buffer. I have a bug open for the messages,
see bug 157667. Stuart, you might want to get on cc: for it.
Comment 12 Ernie Petrides 2005-05-26 22:25:48 EDT
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.5.EL).
Comment 23 Ernie Petrides 2005-07-28 15:43:38 EDT
Rob, please read this:

http://post-office.corp.redhat.com/archives/rhkernel-list/2005-July/msg00822.html
Comment 25 Red Hat Bugzilla 2005-09-28 11:02:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-663.html

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