Description of problem: Floppy disks do not work with RHEL 5.1 Version-Release number of selected component (if applicable): kernel-2.6.18-53.el5 How reproducible: Tried with two different rhel 5.1 machines and lots of disks (both blank and with data) non-rhel 5.1 machines worked. Steps to Reproduce: 1.Boot rhel 5.1 2.Insert floppy 3.Try to copy a file to it using mtools or dd Actual results: dd: opening '/dev/fd0': No such device or address or sometimes: dd: opening '/dev/fd0': Read-only file system dmesg says: end_request: I/O error, dev fd0, sector 0 Expected results: Floppy gets written to Additional info: The floppy module is loaded /dev/floppy points to /dev/fd0 dmesg shows the floppy drive being detected I tried with some older rhel 5.1 kernels and got the same result
Did you tried several floppy drives? And is it a problem only on RHEL 5.1?
I tried only one floppy drive, but Jeff Needle tried another one and he tried several RH OSs. 5.1 was the only one he tried that caused the problem.
Yeah, I had some floppies that worked fine in rawhide systems, but had the exact same behavior in my 5.1 x86_64 machine that it had in Ben's 5.1 i386 machine. I then tried the same floppies in some 5.1 machines that Jeff Burke had and the worked, so I really don't know what's going on here. It's 100% reproducible on my machine if you'd like me to gather some additional information.
Maybe the problem could be in cable... Could you please test another cable (from the system where a floppy drive works) in the system where the drive fails?
Umm, I booted the same machine with multiple operating systems and the only one that failed was 5.1. Unless you think I have a bad cable that is only bad when I boot 5.1, I doubt that's it.
Hello, I have built the latest kernel packages for i686 architecture. You can find them on http://people.redhat.com/ivecera/rhel-5/. Could you please test it and post here any report?
Is the fix in 2.6.18-89.el5xen? I'm currently running that on one box and 2.6.18-88.el5xen on another. Here's what I get: # mdir a: plain_io: Input/output error and in dmesg: printk: 1 messages suppressed. Buffer I/O error on device fd0, logical block 2 floppy0: unexpected interrupt floppy0: sensei repl[0]=80 floppy0: -- FDC reply errorfloppy0: unexpected interrupt floppy0: sensei repl[0]=80 floppy0: -- FDC reply errorfloppy0: unexpected interrupt floppy0: sensei repl[0]=80 floppy0: -- FDC reply errorfloppy0: unexpected interrupt floppy0: sensei repl[0]=80 floppy0: -- FDC reply errorend_request: I/O error, dev fd0, sector 16 Same command on a rawhide system: # mdir a: Volume in drive A has no label Directory for A:/ No files 1 457 664 bytes free Kernel is 2.6.25-0.204.rc8.git4.fc9.i686
Is it possible to try no-xen kernel?
Could you please unload floppy module and reinsert with debug flag? # rmmod floppy # modprobe floppy floppy="debug" Try some operations on floppy (like mdir a:) and send here the dmesg dump.
Good call. This seems to be a kernel-xen thing. Unfortunately, I just wiped out my update with the exact commands by forgetting that attaching a file wipes out the comment. Let me know if you need the exact output that the command got, but for now, /var/log/messages is attached. The last boot was kernel-xen with the debug flag on the floppy module.
I've recreated this on a Lenovo workstation running RHEL5.1 x86_64 and it's definitely a xen kernel issue. Running the non-ken kernel works fine. Symptom: When attempting an mdir a: or mformat a:, the light goes on on the floppy drive and the window hangs. /var/log/messages shows: sensei repl[0]=80 floppy0: unexpected interrupt Google reference is http://uwsg.iu.edu/hypermail/linux/kernel/9805.3/0451.html Raising severity to HIGH as this could impede certification of RHEL5 systems with floppy drives.
Need a release note in RHEL5.2 and a KBase article. Expext this will need to be a 5.3 consideration.
too late for RHEL5.2 release notes (we can put it in the RHEl5.2 release notes updates, though). anyhow, are there any workarounds for this other than "use the non-Virtualized kernel"? also, is this restricted to the x86 arch?
Could you please test a xen kernel package from: http://people.redhat.com/ivecera/rhel-5-xen/ Thanks
I hit this on x86_64 architecture becasue the system I'm certifying is x86_64 only; however, I will try x86 as well. Will try test kernel per comment #15. Reassigning NEEDINFO to me since I have recreated the problem.
Responding to comment #15..... > Could you please test a xen kernel package from: > http://people.redhat.com/ivecera/rhel-5-xen/ As before, the system locked up with the floppy drive light on and ^c will not break the sequence. The test kernel is 2.6.18-91.el5xen on x86_64 architecture.
Per Comment #16 From Larry Troan (ltroan) on 2008-04-28 15:13 EST > I hit this on x86_64 architecture becasue the system I'm certifying is x86_64 > only; however, I will try x86 as well. I loaded a SATA drive with RHEL5.1 x86. The xen kernel booted properly without the floppy attached. After powering down, adding the floppy and rebooting, the system hung during boot with the following on the screen: : ACPI: Getting cpuindex for acpiid 0x4 ACPI: Getting cpuindex for acpiid 0x5 ACPI: Getting cpuindex for acpiid 0x6 ACPI: Getting cpuindex for acpiid 0x7 Red Hat version 5.1.19.6 starting ata: COMRESET failed (errno=-16) ata: COMRESET failed (errno=-16) ata: COMRESET failed (errno=-16) ata: COMRESET failed (errno=-16) When I installed the kernel 2.6.18-53.el5PAE, the floppy worked fine. I was able to read/write files off 1.44MB media. There was no 32 bit kernel corresponding to the test kernel in comment #15 so I couldn't test it. Changed HARDWARE=All in the bug above (was i686).
oops.... above should be "Red Hat nash version 5.1.19.6 starting"
Tried to recreate the boot failure documented in comment #20 above. Turns out I had a loose drive cable and after I fixed that and reloaded x86 RHEL5.1, I am unable to recreate the boot problem. However, I hit the same problem with the x86 xen kernel that I did in comment #12 so this s both x86 and x86_64 kernel-xen. PAE works fine.
Tried on RHEL5.0 x86 but X not supported with the video chip on the system. In init=3, I mounted the floppy drive and it appeared to hang as it did in 5.1 with the floppy light "on". However, when I did a ^c to the mount command, I got a prompt back (I didn't on init+5 with xorg running on RHEL5.1)... I was then able to read the contents of the floppy disk.
Hi Larry, I tried to reproduce this on version 2.6.18-92.el5xen (i686). After "mdir a:" I got several "floppy0: sensei repl[0]=80 etc." messages but the contents of floppy disk was successfully read and shown. I tried to play with kernel command line params and with "noapic" param I got no problem... no unexpected interrupts. Could you please try parameter "noapic" and then "acpi=noirq"? Try mdir and mcopy and send me appropriate dmesg dumps.
Could anybody try to test latest xen kernel with 'noapic' and 'acpi=noirq' command line parameters?
Lost the system I hit this on. Will try to recreate it on another system this week and get back to you. Note that I hit it on x86_64. Others apparently hit it on x86 as well. By latest xen kernel, I assume you mean the one on your people page: http://people.redhat.com/ivecera/rhel-5-xen/ and boot with the 'noapic' and 'acpi=noirq' kernel line grub parms.
Jeff, I lost the Lenovo S10 where I hit this. Will try to recreate it on another system but you may want to try Ivan's people.page kernel as well so between us, we can get this into 5.3...
Please try one from http://people.redhat.com/ivecera/rhel-5-ivtest/
I attempted to recreate this on an FSC Esprimo desktop x86_64 -- I no longer have the Lenovo S10 where I hit the problem originally. No luck; the floppy works fine with the 5.2 x86_64 GA code. Will continue looking for another system and attempt to recreate this bug. Scott, you have the S10. Can you attempt to recreate the bug?
Comment on attachment 304049 [details] sosreport from comment #15 test kernel - failure No longer under NDA -- posted on HCL. Removing "private" flag on this attachment.
Larry, sure I'll get to that this afternoon.
Looks like the test kernel failed in a Dell Precision 450 (32bit Xeon).... Attempted verification using a Dell Precision 450 32bit. I was able to recreate the problem on it using RHEL5.2 rc bits (same as GA). [root@dhcp231-146 ~]# uname -a Linux dhcp231-146.rdu.redhat.com 2.6.18-92.el5.ivtestxen #1 SMP Mon May 19 12:06:02 EDT 2008 i686 i686 i386 GNU/Linux [root@dhcp231-146 ~]# Computer GUI hung when opening "Floppy". Green access light goes on for floppy drive but no engage. Message: Opening "Floppy Drive." You can stop this operation by clicking cancel. CANCEL_BUTTON Appears to have hung as before on the Lenovo S10 64bit system. Attempted to run sosreport. [root@dhcp231-146 ~]# sosreport sosreport (version 1.7) This utility will collect some detailed information about the hardware and setup of your Red Hat Enterprise Linux system. The information is collected and an archive is packaged under /tmp, which you can send to a support representative. Red Hat will use this information for diagnostic purposes ONLY and it will be considered confidential information. This process may take a while to complete. No changes will be made to your system. Press ENTER to continue, or CTRL-C to quit. <Caution as follows:> One or more plugins have detected a problem in your configuration. Please review the following messages: process: * one or more processes are in state D (sosreport might hang) Are you sure you would like to continue (y/n) ? y Please enter your first initial and last name [dhcp231-146]: ltroan Please enter the case number that you are generating this report for: bug401081 Progress [ 0% ][01:04/62:54] : : Progress [#################100%##################][12:16/12:16] : : Progress [#################100%##################][34:29/34:29] ^c ^c <after over half an hour - about 20 minutes with sosreport indicating 100% - I aborted with a ^c> SIGTERM received, multiple threads detected, waiting for all threads to exit <about 30 minutes later, SIGTERM had not completed so I closed the xterm window> Will run sosreport again after rebooting before attempting to run it after the error again so we have a baseline at least.
Larry, did you use 'noapic' kernel cmdline param?
Reproduced the problem on the original Lenovo S10 and 2.6.18-92.el5.ivtestxen #1 SMP Mon May 19 11:50:50 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux I have attempted with and without noapic. If I try acpi=noirq it causes immediate reboot after scanning the SATA ports so I did not use this option. Attaching the output from /var/log/messages and a sosreport
Created attachment 313405 [details] /var/log/messages output during mdir a: with floppy="debug" module option
Created attachment 313406 [details] Lenovo S10 sosreport ivtest kernel
> Comment #34 From Ivan Vecera 2008-08-04 16:43:40 EDT > Larry, did you use 'noapic' kernel cmdline param? Oops! I did not in my prior testing (comment #33). Just tried the two scenarios you requested and I got the following results: 1) noapic -- kernel panic on boot (looks like CPU0 not responding) I took a picture of the screen but can't pull it off the camera until tonight 2) acpi=noirq -- hung as before with mdir command Attaching dmesg as you requested.
Created attachment 313447 [details] dmesg log with acpi=noirq and mdir command
Larry, please put noapic on the Xen line in /boot/grub/menu.lst. Like this: ... root (hd0,0) kernel /xen.gz-2.6.18-101.el5.r8169.5 noapic module /vmlinuz-2.6.18-101.el5.r8169.5xen ro root=... rhgb quiet module /initrd-2.6.18-101.el5.r8169.5xen.img ... Could you please try it?
Created attachment 313516 [details] kernel panic screen shot from noapic parm 1) noapic -- kernel panic on boot (looks like CPU0 not responding) I took a picture of the screen but can't pull it off the camera until tonight
> Larry, please put noapic on the Xen line in /boot/grub/menu.lst. > Like this: > ... > root (hd0,0) > kernel /xen.gz-2.6.18-101.el5.r8169.5 noapic > module /vmlinuz-2.6.18-101.el5.r8169.5xen ro root=... rhgb quiet > module /initrd-2.6.18-101.el5.r8169.5xen.img > ... > > Could you please try it? Tried it and the Xterm hung when I issued an mdir.... Will append the dmesg log.
Created attachment 313571 [details] dmesg log from 'noapic' on cmd line and mdir command
Also repeated the test with acpi=noirq on the kernel line. It hung like the noapic test with the green light on the floppy drive on with the command and the xterm window hanging. dmesg attached as well.
Created attachment 313573 [details] dmesg from acpi=noirq and hang after issuing mdir command
Tracking this bug for the Red Hat Enterprise Linux 5.3 Release Notes.
This bug has been tagged for inclusion in the Red Hat Enterprise Linux 5.3 Release Notes. Please provide a release notes draft in the "Release Notes" field of this bug. thanks!
At this time no fix for Xen kernels are available so I'm obliged to postpone this issue to 5.4 release.
Since this bug was discovered by Red Hat, can we open it up as a public bug?
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Floppy drive media is not accessible when a xen kernel is active. This problem has been around since RHEL5 GA and is being tracked via private Bugzilla 401081 "Floppy disks do not work with RHEL 5.1". The bug will be fixed in a future RHEL5 minor release (update). The workaround is to install and boot a non-xen kernel in order to access the floppy drive to read/write/access a floppy diskette. Note that floppy drives attached via a USB connection do work in a Xen kernel. See also KBase article http://kbase.redhat.com/faq/FAQ_103_12981.shtm
Hi Larry, Thanks for submitting a draft release note! I have edited it and inserted it into the "Known issues" section of the 5.3 release notes.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1,3 @@ -Floppy drive media is not accessible when a xen kernel is active. This problem has been around since RHEL5 GA and is being tracked via private Bugzilla 401081 "Floppy disks do not work with RHEL 5.1". The bug will be fixed in a future RHEL5 minor release (update). +Diskette drive media will not be accessible when using the virtualized kernel. To work around this, use a USB-attached diskette drive instead. -The workaround is to install and boot a non-xen kernel in order to access the floppy drive to read/write/access a floppy diskette. +Note that diskette drive media works well with other non-virtualized kernels.- -Note that floppy drives attached via a USB connection do work in a Xen kernel. - -See also KBase article http://kbase.redhat.com/faq/FAQ_103_12981.shtm
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Per my request in comment #51,.... Opening this up as a public bug as it was discovered by Red Hat and there is no NDA information in it. Since some of our partners are hitting this problem during certification testing and since Red Hat does not plan to fix it (CLOSED=WONTFIX), this needs to be public.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,3 +1,3 @@ -Diskette drive media will not be accessible when using the virtualized kernel. To work around this, use a USB-attached diskette drive instead. +<para>Diskette drive media will not be accessible when using the virtualized kernel. To work around this, use a USB-attached diskette drive instead.</para> -Note that diskette drive media works well with other non-virtualized kernels.+<para>Note that diskette drive media works well with other non-virtualized kernels.</para>