Messages in this thread | | | Date | Wed, 4 Jul 2012 01:06:08 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: long boot delays caused by 070ad7e7 floppy change |
| |
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 SUSE Labs
| |