[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080203053507.GA21681@elte.hu>
Date: Sun, 3 Feb 2008 06:35:07 +0100
From: Ingo Molnar <mingo@...e.hu>
To: David Brownell <david-b@...bell.net>
Cc: Pavel Machek <pavel@....cz>, linux-pm@...ts.linux-foundation.org,
kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] sleepy linux self-test
* Ingo Molnar <mingo@...e.hu> wrote:
> i didnt have all RTC drivers enabled (it was a randconfig .config i
> started out with) - but this did not appear to cure the problem. New
> bootlog and new config attached.
i disabled all hpet items in the .config on the theory that they might
interfere - but that didnt change the end result:
[ 23.893598] Calling initcall 0xc0c518b0: be_sleepy+0x0/0x170()
[ 23.901601] PM: no wakelarm-capable RTC
[ 23.905599] initcall 0xc0c518b0: be_sleepy+0x0/0x170() returned 0.
[ 23.910879] initcall 0xc0c518b0 ran for 3 msecs: be_sleepy+0x0/0x170()
so close, yet so far away :-)
i also disabled ACPI in the .config, which caused this:
[ 13.300838] Calling initcall 0xc0c32370: cmos_init+0x0/0x20()
[ 13.307063] initcall 0xc0c32370: cmos_init+0x0/0x20() returned -19.
[ 13.312840] initcall 0xc0c32370 ran for 0 msecs: cmos_init+0x0/0x20()
is that expected?
btw., small observation: from looking at the bootlog it's not apparent
to me what kind of "RTC hardware" there is on this box. It's standard PC
stuff, so i suspect what covers it is: CONFIG_RTC_DRV_CMOS=y, which
says:
[ 14.900938] Calling initcall 0xc0c6f9c0: cmos_init+0x0/0x10()
[ 14.909178] pnp: the driver 'rtc_cmos' has been registered
[ 14.912945] rtc_cmos 00:04: disabling not supported
[ 14.916940] rtc_cmos: probe of 00:04 failed with error -16
[ 14.920959] initcall 0xc0c6f9c0: cmos_init+0x0/0x10() returned 0.
[ 14.926220] initcall 0xc0c6f9c0 ran for 11 msecs: cmos_init+0x0/0x10()
it might make sense to emit something like:
PC-style RTC detected.
so that people know that your cool new RTC code is in action. Also, it's
not apparent what the effects of that failure message is. When we fail
something then users generally want to know: was it fatal, is it a
warning, and what the limitations of that error condition are.
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