[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080731225004.GD22426@elte.hu>
Date: Fri, 1 Aug 2008 00:50:04 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Suresh Siddha <suresh.b.siddha@...el.com>,
Wim Van Sebroeck <wim@...ana.be>,
Pádraig Brady <P@...igBrady.com>,
Andi Kleen <andi@...stfloor.org>,
"H. Peter Anvin" <hpa@...or.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
"roland@...hat.com" <roland@...hat.com>,
"drepper@...hat.com" <drepper@...hat.com>,
"mikpe@...uu.se" <mikpe@...uu.se>,
"chrisw@...s-sol.org" <chrisw@...s-sol.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 0/9] x86, xsave: xsave/xrstor support
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > But thats not what I see with for ex with, w83627hf_wdt.c
> >
> > Its done at the module_init time. (while I thought it should be
> > really done when some user level app opens the device, probably its
> > poorly written to take care if the kernel panics before starting
> > userland. but kernel can even die before the watchdog driver load
> > aswell ;-)
>
> Yeah, that's a _really_ broken watchdog timer driver. There's no way
> that it's correct to start the watchdog at init time, at least when
> compiled in.
>
> It also looks to me like it's not even probing for the hardware - it's
> just assuming it's there. That's scary. Am I missing something?
>
> It really shouldn't be activated until it's opened. And it really
> shouldn't just write to ports randomly without checking that they make
> sense...
there are a handful of old ISA-ish drivers that can crash randconfig
kernels in various ways. [indefinite lockups, crashes, stomped-over
hardware, non-working keyboard, etc.]
I mapped most of them out via many months of trial-and-error - but it
would still be nice to have some separate config option to disable the
known ones. CONFIG_ALLOW_NON_GENERIC or something like that - which i
would unset in the randconfig runs.
( They are not CONFIG_BROKEN per se, because often it's hardware that
cannot be probed in any reliable way - the driver just assumes it's
there. )
Ingo
--
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/
Powered by blists - more mailing lists