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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
