Description of problem: RHEL4 pre-rc1: hwbrowser doent start with USB Floppy Drive conected. OS: RHEL4 Pre-rc1 Kernel :2.6.9-1.871.4.1_EL.libata.update.1smp Platform: Dell PE1800 Description. After connecting usb Floppy Drives , hwbrowser gives error and doesnt come upith the device list Version-Release number of selected component (if applicable): How reproducible: Easy 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. Actual results: error window (attached) Expected results: hwbrowser should run Additional info: I will attach /var/log/messages, output of lsusb -v, and error window
Created attachment 108530 [details] /var/log/messages
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 numbers. 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 hw_geom.cylinders. 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 solution. Thanks! --- 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 * disk.sectors * disk.cylinders) + if totalSectors == 0: + totalSectors = float(disk.length) xoffset = self.partition.geom.start / totalSectors * CANVAS_WIDTH xlength = self.partition.geom.length / totalSectors * CANVAS_WIDTH 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. http://rhn.redhat.com/errata/RHBA-2005-101.html