Re: long boot delays caused by 070ad7e7 floppy change

From: Jiri Kosina
Date: Tue Jul 03 2012 - 19:06:15 EST

On Tue, 3 Jul 2012, Linus Torvalds wrote:

> >> What happens if you add a
> >>
> >> cancel_delayed_work(&fd_timeout);
> >>
> >> to before the queue_delayed_work() in __reschedule_timeout()? Does
> >> that possibly make the delay really be 3 seconds?
> >
> > Yes, it does...
> Ok. And I see the previous timeout - it's this:
> reschedule_timeout(MAXTIMEOUT, "floppy init");
> that sets the fd_timeout to 20 seconds initially.

Still doesn't explain why reverting 070ad7e793dc6 (which made the whole
thing completely serialized) doesn't fix it though; that's quite a mystery
to me.

> That whole fd_timeout code is broken, though. I'm not sure what the
> floppy init timeout is supposed to do, when the floppy reset code wants
> to re-use it.
> And yes, the 3-second timeout is still too long.
> Doing it asynchronously like Andi does helps a bit, but I suspect we
> could make the reset timeout shorter still just to make the initial
> "you don't have a floppy drive" code go faster.
> That said, why even compile in the floppy driver any more? Even if you
> have the hardware, it probably doesn't work after ten years of
> gathering dust. Those floppy drives weren't exactly reliable even back
> in the days..
> Anyway, I looked up the 82078 docs for reset. Holding the reset low
> *does* cause an interrupt, but I'm not finding how long the reset
> might take. But for the controller it really should be milliseconds,
> not seconds, I suspect. Can anybody find the appropriate reset
> timeout?

I will look into it once I am back again from vacation next week. In the
meantime, I'd propose to simply add the cancel_delayed_work() for 3.5;
it's an obvious bug I made during the timer -> workqueue conversion, as we
used to do del_timer() before.

Jiri Kosina
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at