Red Hat Bugzilla – Bug 142835
RHEL4 U1: hwbrowser doesn't start with USB Floppy Drive connected
Last modified: 2007-11-30 17:07:15 EST
Description of problem:
RHEL4 pre-rc1: hwbrowser doent start with USB Floppy Drive conected.
OS: RHEL4 Pre-rc1
Platform: Dell PE1800
After connecting usb Floppy Drives , hwbrowser gives error and doesnt
come upith the device list
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RHEL4 PRE-RC1.
2. Update kernel to the above version specified.
3. Attatch USB Floppy Drive
4. Launch hwbrowser on X.
error window (attached)
hwbrowser should run
I will attach /var/log/messages, output of lsusb -v, and error window
Created attachment 108530 [details]
Created attachment 108531 [details]
error message window
The output of "lsusb -v" wasn't actually provided to me. Please let
me know if you need me to get it. Thanks.
This appears to be happening because hwbrowser is dividing by zero.
The zero is coming from hwbrowser's calculation of xoffset in the
file DeviceDisk.py's DiskStripeSlice.update, which is
calculating "totalSectors" by multiplying
disk.heads*disk.sectors*disk.cylinders, and then dividing something
by that value.
The problem is that disk.cylinders is 0. This is coming from
libparted's linux.c, function _device_probe_geometry(), where it
calculates dev->bios_geom.cylinders by dividing dev->length (0xb40 in
this case) by 63*255, which comes out to 0.
_device_probe_geometry() appears to be calculating dev-
>hw_geom.cylinders correctly (it comes out to 0x3c0), but I guess
hwbrowser is using the bios_geom numbers instead of the hw_geom
It seems to me that hwbrowser should use the hw_geom numbers rather
than the bios_geom numbers, but I'm really not familiar enough with
the implications to be certain of that.
Other possible fixes would be to modify hwbrowser so that it doesn't
crash if it gets a totalSectors of zero (i.e., don't divide by
totalSectors if it is zero), or to use some intelligence to decide
whether to use the bios_geom or the hw_geom (i.e., if
bios_geom.cylinders is 0, try the hw_geom instead)...
I see that pyparted is only returning bios_geom.cylinders
for .cylinders, so that hwbrowser wouldn't even have access to
Perhaps a better solution would be for hwbrowser to realize that the
USB floppy is a floppy, and not attempt to display it under hard
disks... I think that would eliminate the problem, since the
DiskStripeSlice is only generated for hard disks, and that's where
the divide by zero is occurring.
Upon reflection, I think the best solution is just to make hwbrowser
use disk.length for totalSectors if disk.cylinders * disk.heads *
disk.sectors comes out to zero. This seems to work fine, won't
change the way hwbrowser works in any case where it worked before,
and doesn't require any changes to parted, pyparted, or kudzu.
I copied a patch below, in case you agree that this is a good
--- DeviceDisk.py.original 2005-01-05 12:46:01.000000000 -0500
+++ DeviceDisk.py 2005-01-05 17:32:55.568940104 -0500
@@ -147,6 +147,8 @@
totalSectors = float(disk.heads
+ if totalSectors == 0:
+ totalSectors = float(disk.length)
xoffset = self.partition.geom.start / totalSectors *
xlength = self.partition.geom.length / totalSectors *
if self.partition.type & parted.PARTITION_LOGICAL
Created attachment 109447 [details]
patch to hwbrowser's DeviceDisk.py to fix divide by zero error with USB floppy
Unfortunately this won't make it into GA (I've been busy with other
stuff as you undoubtedly have noticed already). I plan to get your fix
integrated for U1 so bug me if you don't hear anything from me be say
end of next week.
Changing the title to reflect the Update in which a fix for this
issue has been committed or being tracked for..
The report today from one of our testers in Austin indicates "Can't
load the hwbrowser with the USB floppy drive attached" with RHEL 4 RC
x86, but still works on x86_64.
This should be fixed in hwbrowser-0.19-0.EL4.1.
Raghavendra from Dell has regressed and confirms that this issue is resolved
in U1 beta. Closing. Thanks!
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.