Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 3 Jul 2012 10:07:59 -0700 | Subject | Re: long boot delays caused by 070ad7e7 floppy change |
| |
On Tue, Jul 3, 2012 at 6:47 AM, Calvin Walton <calvin.walton@kepstin.ca> wrote: > > I'm seeing the same issue, so I've given this a try. Here are the > messages printed when floppy debugging is enabled: > > [ 0.714318] floppy0: reschedule timeout lock fdc > [ 20.729798] floppy0: reschedule timeout do wakeup
Ok, that 20 s timeout is a hint.
20s is the floppy "max timeout" value, and it's used in various places. HOWEVER. The "lock fdc" case absolutely should not be using that timeout. It should use the floppy "UDP->timeout" value, which should be just 3s. Which is still a long time, but not nearly as long as that.
Can you add a DPRINT() to the lock_fdc() function just before calling reschedule_timeout() to print out what the "drive" is? Something like yhhis (whitespace-damaged due to cut-and-paste):
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index cce7df367b79..00b52cef9d22 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -876,6 +876,7 @@ static int lock_fdc(int drive, bool interruptible)
command_status = FD_COMMAND_NONE;
+ DPRINT("lock_fdc: %d (out of %d)\n", drive, N_DRIVE); reschedule_timeout(drive, "lock fdc"); set_fdc(drive); return 0;
because maybe the 'drive' variable is crap there. In fact, add a
WARN_ON_ONCE(dive < 0 || drive >= N_DRIVE);
in there too. Because if it is out of range, I'd want to see the call chain.
(And you still need floppy=debug to see that debug message, of course).
Linus
| |