lkml.org 
[lkml]   [2012]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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


\
 
 \ /
  Last update: 2012-07-03 19:41    [W:0.954 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site