[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <051e01c76072$fcdae290$4b00a8c0@donald>
Date: Wed, 7 Mar 2007 05:42:13 +0100
From: "Paul Rolland" <rol@...917.net>
To: "'David Brownell'" <david-b@...bell.net>
Cc: "'Adrian Bunk'" <bunk@...sta.de>, <linux-kernel@...r.kernel.org>,
<a.zummo@...ertech.it>, <rtc-linux@...glegroups.com>
Subject: RE: 2.6.21-rc2 : Oops in rtc_cmos...
Hello,
> > Yes, it does, so it's a Good One (tm),
>
> And points out that $SUBJECT is misleading; the root cause of
> the oops isn't rtc_cmos. Workaround, don't enable the legacy
> driver for this hardware.
Well, sorry for that, but my point was that without enabling
CONFIG_DRV_RTC_CMOS and only using CONFIG_RTC, my dmesg says :
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Having seem that, I got thru all the options, trying to find what I
could have forgot as an option, and added the RTC_CMOS one, that resulted
in an Oops...
> One of the good things about getting rtc-cmos merged: it
> exposes this new RTC framework to new mistakes, which helps
> fix some of the remaining rough spots.
Good ;)
> > pnp: Device 00:03 does not support disabling.
>
> Blame the PNP stack for that particular useless message.
> I'l send a fix for that one too.
OK, ready to test !
> > drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> Because probing 00:03 failed, was never fully usable.
> So then rtc0 couldn't be found. You'd get the same
> message if, say, the RTC was loaded as a module.
It seems to me that the DRV_RTC_CMOS and the "standard" CONFIG_RTC
shouldn't be used at the same time... Am I correct on that ?
Wouldn't it be better to have this dependancy enforced ?
Regards,
Paul
-
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