Bug 127163 - floppy is gone on return from suspend
floppy is gone on return from suspend
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-02 17:11 EDT by Michal Jaegermann
Modified: 2015-01-04 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.17-1.2142_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-16 14:08:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2004-07-02 17:11:30 EDT
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
Comment 1 Dave Jones 2005-01-14 00:43:14 EST
any improvemnet with todays 2.6.10 update ?
Comment 2 Michal Jaegermann 2005-01-15 17:37:32 EST
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.
Comment 3 Dave Jones 2005-04-16 00:05:57 EDT
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.
Comment 4 Michal Jaegermann 2005-09-11 21:38:27 EDT
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.
Comment 5 Dave Jones 2005-09-30 02:05:57 EDT
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.
Comment 6 Michal Jaegermann 2005-10-24 16:59:25 EDT
At last I had an opportunity to retest with 2.6.13-1.1532_FC4.  No change.
Comment 7 Dave Jones 2005-11-10 14:02:07 EST
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.
Comment 8 Michal Jaegermann 2005-11-11 14:52:34 EST
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.
Comment 9 Dave Jones 2006-02-03 00:10:51 EST
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.
Comment 10 Michal Jaegermann 2006-02-03 15:24:24 EST
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.
Comment 11 Dave Jones 2006-09-16 21:34:51 EDT
[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.
Comment 12 Michal Jaegermann 2006-09-17 00:20:04 EDT
> 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.
Comment 13 Dave Jones 2006-10-16 13:26:51 EDT
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.
Comment 14 Michal Jaegermann 2006-10-16 14:08:03 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.