Description of problem: Acer Travelmate 230 laptop goes to sleep on certain conditions ('acpi_sleep=s3_bios' in boot parameters and ehci-hcd module unloaded before suspension attempts) and even wakes up fine. Various devices are there back with an exception of a floppy. The following shows up in logs: floppy0: unexpected interrupt floppy0: sensei repl[0]=c0 repl[1]=0 floppy0: sensei repl[0]=c1 repl[1]=0 floppy0: sensei repl[0]=c2 repl[1]=0 floppy0: sensei repl[0]=c3 repl[1]=0 and all subseqent access attempts will end up with i/o errors or will sit there in perpetuity with no results while floppy is spinning and its LED lights up. There are no troubles of that sort before the first suspension. "Other OS" somehow deals with that problem (although it does not exist anymore on that particular machine). Version-Release number of selected component (if applicable): kernel-2.6.6-1.435.2.3 and earlier from FC2. How reproducible: Always
any improvemnet with todays 2.6.10 update ?
With kernel 2.6.10-1.9_FC2 there are indeed changes but it is hard to call them "improvements". :-) Messages quoted in the original bug report indeed vanished. Still if a floppy was not mounted during a suspend and one tries to do that after a wakeup then a drive starts to spin, a control ligth lits up, and a driver loops at this state apparently any amount of time until an i/o error is provoked by a push on an eject button. If left spinning then floppy blocks shutdown by preventing pcmcia service from stopping. Doing 'modprobe -r floppy; modprobe floppy' has no effect on this condition. A message: Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 shows up in logs but that is about it. If a floppy is mounted during suspend then after a wake-up it appears still to be mounted and one can even do 'ls /mnt/floppy' with what appears to be correct results (probably cache). OTOH this shows up in logs: floppy driver state ------------------- now=4294892220 last interrupt=4294844770 diff=47450 last called handler=d0183dd8 timeout_message=lock fdc last output bytes: 7 90 4294843592 0 90 4294843592 1 90 4294843592 2 90 4294843592 12 90 4294843592 1b 90 4294843592 ff 90 4294843592 f 80 4294844283 0 90 4294844283 0 90 4294844283 8 81 4294844312 e6 80 4294844332 0 90 4294844332 0 90 4294844332 0 90 4294844332 1 90 4294844332 2 90 4294844332 12 90 4294844332 1b 90 4294844332 ff 90 4294844332 last result at 4294844770 last redo_fd_request at 4294844770 4 0 0 1 0 1 2 status=0 fdc_busy=1 do_floppy=d01852aa cont=d018f8a0 current_req=00000000 command_status=-1 Any attempt to access files on a floppy (say 'cat some_file_there') causes the above to show up again followed by: floppy0: floppy timeout called floppy0: disk absent or changed during operation end_request: I/O error, dev fd0, sector 1 many times, and possibly with slight variations, terminated with floppy0: disk absent or changed during operation end_request: I/O error, dev fd0, sector 33 Buffer I/O error on device fd0, logical block 33 and maybe also lost page write due to I/O error on fd0 for a good measure. After a reboot floppy again is fine until the next suspend.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.
There is still no floppy access after suspend with 2.6.12-1.1447_FC4 kernel. The only difference is that now a floppy, which does not present access troubles before suspend, is churned in a drive until forcibly ejected in a total silence. That means that there are no errors logged to a screen and/or log files with an exception of floppy0: disk removed during i/o end_request: I/O error, dev fd0, sector 0 when an eject button is pushed; which is not very surprising.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
At last I had an opportunity to retest with 2.6.13-1.1532_FC4. No change.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
There is a progress after all this tims. :-) With 2.6.14-1.1637_FC4 I am actually not loosing floppy after a suspend. Note: my helper script does 'modprobe -r floppy' when suspending and inserts that back on a wake-up (a leftover from my earlier attempts to revive that floppy). When I left those steps out then I immediately got trying to access a floppy after a suspension: floppy0: unexpected interrupt floppy0: sensei repl[0]=c0 repl[1]=0 floppy0: sensei repl[0]=c1 repl[1]=0 floppy0: sensei repl[0]=c2 repl[1]=0 floppy0: sensei repl[0]=c3 repl[1]=0 which looks exactly the same as in the initial report. Still after some commotion a floppy was accesible again. This does not happen if I will remove and insert back a floppy module. Due to that I will leave a decistion if this bug should be immediately closed to Dave.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
The situation is exactly like the one described in comment #8. That means that suspend is _not_ killing floppy but "sensei" messages are still there. If they should be really ignored I do not know.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
> Please retest with Fedora Core 5. The laptop in question is not really mine, there is no FC5 on it and, as this is "workhorse" machine, I am not in a position to play too much with it. When FC6 will show up it will get an upgrade. OTOH, as I wrote quite a while ago in comment #8 and comment #10 with later kernels floppy after suspend is accesible. There are always messages like those described in comment #8 but after that floppy works. This situation continues with 2.6.17-1.2142_FC4. If you think that "unexpected interrupt" messages are normal, or at least not worth paying attention to, then I would be inclined to close that bug.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I do not see a point in keeping that open now. Many things in that area changed and I believe that this will work with all current kernels. If this will turn out in the future not to be the case I will either file a new bug or will re-open this one with additional information.