Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 156831

Summary: sd _mod doesn't handle removable drives (USB floppy) well
Product: Red Hat Enterprise Linux 3 Reporter: Wendy Cheng <nobody+wcheng>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dff, jturner, ltroan, petrides, stuart_hayes, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2005-663 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-28 15:02:32 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:
Bug Depends On:    
Bug Blocks: 156320    
Attachments:
Description Flags
a simple and plain program to demonstrate the problem.
none
The agreed patch to address this issue.
none
The original proposed patch made by Dell's Stuart Hayes. none

Description Wendy Cheng 2005-05-04 15:41:11 UTC
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 15:41:11 UTC
Created attachment 114022 [details]
a simple and plain program to demonstrate the problem.

Comment 2 Wendy Cheng 2005-05-04 15:46:53 UTC
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 15:53:14 UTC
Created attachment 114024 [details]
The original proposed patch made by Dell's Stuart Hayes.

Comment 6 Wendy Cheng 2005-05-04 16:05:36 UTC
(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 19:31:19 UTC
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 19:32:02 UTC
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 19:40:03 UTC
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 21:26:30 UTC
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-27 02:25:48 UTC
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 19:43:38 UTC
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 15:02:32 UTC
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