linux-kernel - Re: long boot delays caused by 070ad7e7 floppy change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 4 Jul 2012 01:06:08 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Calvin Walton <calvin.walton@...stin.ca>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	shemminger@...tta.com
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/