Re: long boot delays caused by 070ad7e7 floppy change

From: Linus Torvalds
Date: Tue Jul 03 2012 - 13:08:17 EST


On Tue, Jul 3, 2012 at 6:47 AM, Calvin Walton <calvin.walton@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/