Bug 155395 - Kernel panics with 120MB IDE floppy
Kernel panics with 120MB IDE floppy
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Brian Maly
Brian Brock
Depends On:
Blocks: 186960 190430
  Show dependency treegraph
Reported: 2005-04-19 17:44 EDT by jordan hargrave
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-19 16:08:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
linux-2.4.21-idefloppy.patch (499 bytes, patch)
2006-01-30 15:47 EST, Samuel Benjamin
no flags Details | Diff
test patch (540 bytes, patch)
2006-02-21 14:23 EST, Brian Maly
no flags Details | Diff
avoid divide by zero in idefloppy_create_rw_cmd (496 bytes, patch)
2006-04-04 15:49 EDT, Brian Maly
no flags Details | Diff

  None (edit)
Description jordan hargrave 2005-04-19 17:44:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Description of problem:
On systems with a LS120 IDE floppy attached, if the kernel is booted with an unformatted floppy in the drive, the kernel may panic.  This is due to a bug in drivers/ide/ide-floppy.c; the bs_factor is initialized to 0 and never set properly for unformatted floppies.  If a read is issued to the drive, a divide by zero occurs in idefloppy_do_request.

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

How reproducible:

Steps to Reproduce:
1.Install RHEL3 U4 with a 120MB IDE Floppy
2.Insert unformatted 120MB floppy in drive
3.Boot system

Actual Results:  Kernel panics at idefloppy_do_request.

Expected Results:  Kernel should not panic.

Additional info:

         switch (rq->cmd) {
                 case READ:
                 case WRITE:
                         if (rq->sector % floppy->bs_factor ||
                             rq->nr_sectors % floppy->bs_factor) {

Divide by zero occurs here; bs_factor is initialized to zero.
Comment 2 jordan hargrave 2005-04-20 14:10:22 EDT
Also happens with ZIP250 IDE Floppy drive
Comment 3 Charles Rose 2005-05-10 23:34:18 EDT
Opened Issue Tracker 72593
Comment 14 Samuel Benjamin 2006-01-30 15:47:50 EST
Created attachment 123882 [details]

Moving patch from IT-81457 to the patch attachment section.
Comment 15 Samuel Benjamin 2006-02-09 15:13:30 EST
Raising priority to high based on Dell's U8 consideration.
Comment 17 Brian Maly 2006-02-21 14:23:02 EST
Created attachment 124976 [details]
test patch

can we get some testing on this patch?

its probably a safer patch (as it minimizes possible regression).
hopefully it resolves the issue
Comment 19 Guy Streeter 2006-03-30 17:12:26 EST
I don't believe this second patch is better. It sets bs_factor in only one of
the cases. There are many paths through the code where it doesn't get set. In
issue 81475, the problem isn't an unformatted floppy, it's a non-standard
("virtual media") floppy drive (empty).
Comment 20 Samuel Benjamin 2006-03-31 16:34:50 EST
This problem was also recreated with a zip device with an unformatted disk on a
PE2500. This setup  reproduced the kernel panic with an automated reboot cycle
on this system. See c#4.

Is the Dell submitted patch (linux-2.4.21-idefloppy.patch) any better ?
Comment 21 Brian Maly 2006-04-04 15:39:24 EDT
on closer inspection, it looks like the divide by zero error occurs in
idefloppy_create_rw_cmd() which is called from idefloppy_do_request() since all
stack traces associated with this bug appear to be traceable to


in idefloppy_create_rw_cmd()
 int block = sector / floppy->bs_factor;
 int blocks = rq->nr_sectors / floppy->bs_factor;

I think the best fix is actually (from comment #6):

if (!floppy->bs_factor ||
        rq->sector % floppy->bs_factor ||
        rq->nr_sectors % floppy->bs_factor)

this fix will keep idefloppy_create_rw_cmd() from being called and the divide by
zero from occuring. this seems like a better approach than setting
floppy->bs_factor = 1 being that bs_factor is used in many places and could have
undefined, unexpected or unintended results and is thus more risky.

Ill re-work the patch and post for testing...

Comment 22 Brian Maly 2006-04-04 15:49:45 EDT
Created attachment 127310 [details]
avoid divide by zero in idefloppy_create_rw_cmd

patch avoids divide by zero in idefloppy_create_rw_cmd(), which will prevent a
kernel panic and seems safer than setting bs_factor=1. now an error will be
thrown instead... would also appreciate any feedback anyone has on the
consequences of throwing an error as opposed to setting bs_factor=1.

can we get some testing on this patch also?
Comment 23 Guy Streeter 2006-04-04 16:25:24 EDT
Have you built a kernel with this patch?
Comment 24 Samuel Benjamin 2006-04-05 10:30:21 EDT
If you have a patched test kernel, I can test this fix on a system with a 120MB
floppy disk.
Comment 25 Brian Maly 2006-04-06 15:25:31 EDT
Posted a test kernel tarball with the patch already applied:


Comment 28 Bob Johnson 2006-04-11 12:31:00 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 3.8 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 3.8 release.
Comment 30 Brian Maly 2006-04-20 16:39:56 EDT
can Dell please test this patch/kernel and verify this resolves the issue? 

Comment #22 is the patch
Comment #25 is the kernel with the patch applies
Comment 32 Samuel Benjamin 2006-04-28 13:45:02 EDT
I will test the fix in the GSS lab on Dell's behalf and report the results shortly.
Comment 33 Issue Tracker 2006-05-01 17:33:13 EDT
The kernel panic was recreated on PE 2500 with a IOMEGA FLOPPY DISK
attached to a add-on ATA/133 ide controller running a continuous reboot
test. The problem normally occurs within 5 reboot cycles. The kernel has
been rebuilt with the patch and the test system has been rebooted at least
30 times without a kernel panic. The problem seems to have been fixed.

I will continue the reboot test overnight to confirm this and report if
anything changes.

This event sent from IssueTracker by sbenjamin 
 issue 72593
Comment 35 Ernie Petrides 2006-05-02 17:01:28 EDT
RHEL3 U8 closed a couple of weeks ago.
Comment 41 Issue Tracker 2007-04-19 17:15:54 EDT
This issue has been rejected by Engineering for inclusion in RHEL3.9, as
code changes in that release are being limited to the most critical of
fixes. We will be unable to address this issue in RHEL3. 

Internal Status set to 'Waiting on Customer'
Status set to: Waiting on Client
Resolution set to: 'Rejected'

This event sent from IssueTracker by gcase 
 issue 72593

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