> On Tue, Jan 16, 2007 at 01:13:33AM -0500, Norman Ramsey wrote: > > I have a 'modern' machine with no 3.5-inch floppy drive. > > For some reason though, my /dev includes a /dev/fd0. > > I suppose you're using udev and have a dynamic /dev, containing only devices > which are actually present? In that case, this is strange. Perhaps you can > try to switch off floppy support in the BIOS?
Oh, that's a smart idea. Here are the relevant lines from dmesg: Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Of course the issue is that the controller is on the motherboard, but there's nothing connected to it. Fiddling with the BIOS sounds like a brilliant idea; I'll try it at the next reboot. > > As a result, when I launch qtparted, it hangs trying to mess with > > /dev/fd0. Here's a sample from /var/log/kern.log: > > > > Jan 16 00:57:08 localhost kernel: Buffer I/O error on device fd0, logical > > block 0 Jan 16 00:57:20 localhost kernel: end_request: I/O error, dev > > fd0, sector 0 > ... > > This is probably a problem in some underlying library as gparted shows > > similar behavior. > > Actually, it looks more like a problem with your kernel. qtparted, being a > normal user-space program, should be unable to generate such messages in the > kernel log. Of course it would be nice if it would be able to handle such > kernel bugs, but IMO programs may rely on bug-free kernels and don't need > workarounds. That is, I'd suggest that this problem be fixed in the kernel, > not in *parted. If I properly understand it, of course. :-) I guess we have to disagree---presumably libparted or qtparted or whatever is trying to run sort of ioctl or open or read on /dev/fd0. (In fact I confirmed with strace that it's trying to read().) When the kernel returns these error codes, parted should cease and desist, rather than banging its head against the same error over and over again. The log messages do not indicate a bug in the kernel; they are there to help diagnose problems. A reasonable person might argue that it is a kernel bug to detect /dev/fd0 where a controller exists but no drive is connected to it. That one I'll leave to the kernel experts. Norman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
