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 155395 - Kernel panics with 120MB IDE floppy
Summary: Kernel panics with 120MB IDE floppy
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Brian Maly
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-19 21:44 UTC by jordan hargrave
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-19 20:08:55 UTC
Target Upstream Version:

Attachments (Terms of Use)
linux-2.4.21-idefloppy.patch (deleted)
2006-01-30 20:47 UTC, Samuel Benjamin
no flags Details | Diff
test patch (deleted)
2006-02-21 19:23 UTC, Brian Maly
no flags Details | Diff
avoid divide by zero in idefloppy_create_rw_cmd (deleted)
2006-04-04 19:49 UTC, Brian Maly
no flags Details | Diff

Description jordan hargrave 2005-04-19 21:44:59 UTC
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 18:10:22 UTC
Also happens with ZIP250 IDE Floppy drive

Comment 3 Charles Rose 2005-05-11 03:34:18 UTC
Opened Issue Tracker 72593

Comment 14 Samuel Benjamin 2006-01-30 20:47:50 UTC
Created attachment 123882 [details]

Moving patch from IT-81457 to the patch attachment section.

Comment 15 Samuel Benjamin 2006-02-09 20:13:30 UTC
Raising priority to high based on Dell's U8 consideration.

Comment 17 Brian Maly 2006-02-21 19:23:02 UTC
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 22:12:26 UTC
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 21:34:50 UTC
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 19:39:24 UTC
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 19:49:45 UTC
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 20:25:24 UTC
Have you built a kernel with this patch?

Comment 24 Samuel Benjamin 2006-04-05 14:30:21 UTC
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 19:25:31 UTC
Posted a test kernel tarball with the patch already applied: 

Comment 28 Bob Johnson 2006-04-11 16:31:00 UTC
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 20:39:56 UTC
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 17:45:02 UTC
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 21:33:13 UTC
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 21:01:28 UTC
RHEL3 U8 closed a couple of weeks ago.

Comment 41 Issue Tracker 2007-04-19 21:15:54 UTC
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.