On Tue, 2003-12-30 at 12:48, Karol Kozimor wrote:
> Hi,
> Booting with clock=pmtmr causes weird problems here (the system
> complains that clock override failed and the bogomips loop produces bogus
> values). Below is the dmesg output as well as /proc/cpuinfo.
> I have CONFIG_X86_LOCAL_APIC=y and CONFIG_X86_PM_TIMER=y.
>
> I don't really know whether this box (ASUS L3800C, more data at
> http://bugme.osdl.org/show_bug.cgi?id=1185) has a PM timer or not, but even
> if it doesn't, the code should account for that gracefully.
> I'll be happy to provide any additional info.
If the override boot option failed, its most likely your system doesn't
have an ACPI PM time source. Instead it seems your system is having
trouble using the PIT as a time source (which seems not all that
uncommon unfortunately).
I guess we can just re-call select_timer() without an override if the
override fails, that way you'll fall back to the default time source on
your system. Try the (compile tested) patch below and see if that helps.
Thanks for the feedback!
-john
diff -Nru a/arch/i386/kernel/timers/timer.c b/arch/i386/kernel/timers/timer.c
--- a/arch/i386/kernel/timers/timer.c Mon Jan 5 14:09:26 2004
+++ b/arch/i386/kernel/timers/timer.c Mon Jan 5 14:09:26 2004
@@ -43,21 +43,40 @@
cur_timer = &timer_pit;
}
-/* iterates through the list of timers, returning the first
- * one that initializes successfully.
+/* helper function to iterates through the list of timers,
+ * returning the first one that initializes successfully.
*/
-struct timer_opts* select_timer(void)
+static struct timer_opts* pick_timer(char* override)
{
int i = 0;
/* find most preferred working timer */
while (timers[i]) {
if (timers[i]->init)
- if (timers[i]->init(clock_override) == 0)
+ if (timers[i]->init(override) == 0)
return timers[i];
++i;
}
-
- panic("select_timer: Cannot find a suitable timer\n");
return NULL;
+}
+
+struct timer_opts* select_timer(void)
+{
+ struct timer_opts* ret;
+
+ /* pick the best time source*/
+ ret = pick_timer(clock_override);
+
+ /* if we didn't find anything, try without the override */
+ if (!ret && clock_override) {
+ printk("Warning: 'clock=%s' override failed.\n", clock_override);
+ ret = pick_timer(NULL);
+ }
+
+ /* if we still didn't find anything, we're ruined */
+ /* note that this won't happen, as the PIT always succeeds*/
+ if (!ret)
+ panic("select_timer: Cannot find a suitable timer\n");
+
+ return ret;
}
diff -Nru a/arch/i386/kernel/timers/timer_pit.c b/arch/i386/kernel/timers/timer_pit.c
--- a/arch/i386/kernel/timers/timer_pit.c Mon Jan 5 14:09:26 2004
+++ b/arch/i386/kernel/timers/timer_pit.c Mon Jan 5 14:09:26 2004
@@ -24,7 +24,7 @@
{
/* check clock override */
if (override[0] && strncmp(override,"pit",3))
- printk(KERN_ERR "Warning: clock= override failed. Defaulting to PIT\n");
+ return -ENODEV;
count_p = LATCH;
return 0;
Thus wrote john stultz:
> If the override boot option failed, its most likely your system doesn't
> have an ACPI PM time source. Instead it seems your system is having
Well, I don't have the slightest idea on how to determine this, though I
read somewhere that all ACPI-compliant systems have those.
> trouble using the PIT as a time source (which seems not all that
> uncommon unfortunately).
Perhaps, though bear in mind it behaves so only if clock=pmtmr has been
appended and works fine with clock=pit.
> I guess we can just re-call select_timer() without an override if the
> override fails, that way you'll fall back to the default time source on
> your system. Try the (compile tested) patch below and see if that helps.
That would be PIT again, as TSC is unusable due to CPUFreq.
I'll try it ASAP -- should I test with Dmitry's patch applied?
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
Thus wrote john stultz:
> > > If the override boot option failed, its most likely your system doesn't
> > > have an ACPI PM time source. Instead it seems your system is having
> > Well, I don't have the slightest idea on how to determine this, though I
> > read somewhere that all ACPI-compliant systems have those.
> More debug output is probably needed.
I'll be happy to provide it :)
> > > trouble using the PIT as a time source (which seems not all that
> > > uncommon unfortunately).
> > Perhaps, though bear in mind it behaves so only if clock=pmtmr has been
> > appended and works fine with clock=pit.
> Ah, I must have missed that point. Indeed that is very odd. When booting
> without the clock= what time source is used? Does booting w/
> "clock=crazy" also show the problem?
It depends -- generally either PIT (that's 2.4) or TSC, the latter switches
back to PIT once CPUFreq is used. I've never seen any problems with the
bogomips loop or /proc/cpuinfo, except when it could be directly attributed
to CPUFreq bugs.
I booted the following with clock=crazy:
1) 2.6.1-rc1-mm1 with Dmitry's patch: deadlock as before
2) 2.6.0-test11-almost vanilla (Nigel's swsusp patches): passed, results
similar to -rc1-mm1 vanilla, i.e. cpuinfo shows 0 MHz and bogomips is
miscalculated.
So it seems to be a more generic problem.
2.6.1-rc1 is on the way.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
On Mon, 2004-01-05 at 14:17, Karol Kozimor wrote:
> Thus wrote john stultz:
> > If the override boot option failed, its most likely your system doesn't
> > have an ACPI PM time source. Instead it seems your system is having
>
> Well, I don't have the slightest idea on how to determine this, though I
> read somewhere that all ACPI-compliant systems have those.
More debug output is probably needed.
> > trouble using the PIT as a time source (which seems not all that
> > uncommon unfortunately).
>
> Perhaps, though bear in mind it behaves so only if clock=pmtmr has been
> appended and works fine with clock=pit.
Ah, I must have missed that point. Indeed that is very odd. When booting
without the clock= what time source is used? Does booting w/
"clock=crazy" also show the problem?
> > I guess we can just re-call select_timer() without an override if the
> > override fails, that way you'll fall back to the default time source on
> > your system. Try the (compile tested) patch below and see if that helps.
>
> That would be PIT again, as TSC is unusable due to CPUFreq.
> I'll try it ASAP -- should I test with Dmitry's patch applied?
No, my patch is just against 2.6.1-rc1 (really I should have checked if
it applies onto mm2, but I didn't). Due to the misunderstanding above,
I'm actually more interested in the questions I just asked then if the
last patch worked (but if you're feeling bored, don't let me stop you
from testing it :)
thanks
-john
Thus wrote john stultz:
> Ah, I must have missed that point. Indeed that is very odd. When booting
> without the clock= what time source is used? Does booting w/
> "clock=crazy" also show the problem?
A quick follow-up: booting with 2.6.1-rc1 + plus your patch:
clock=crazy: doesn't even pass the Uncompressing kernel... Booting Linux
stage,
clock=pmtmr: see above
clock=tsc : boots normally
clock=pit : as well
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
On Mon, 2004-01-05 at 15:18, Karol Kozimor wrote:
> Thus wrote john stultz:
> > Ah, I must have missed that point. Indeed that is very odd. When booting
> > without the clock= what time source is used? Does booting w/
> > "clock=crazy" also show the problem?
>
> A quick follow-up: booting with 2.6.1-rc1 + plus your patch:
> clock=crazy: doesn't even pass the Uncompressing kernel... Booting Linux
> stage,
Grrr. That def shouldn't happen. Let me do some further local testing
and I'll get back to you with another patch.
> clock=pmtmr: see above
Expected, as 2.6.1-rc1 doesn't have the ACPI pm time source, so
pmtmr=crazy ;)
> clock=tsc : boots normally
> clock=pit : as well
I'm still curious about what default time source is selected (when not
using the clock= option) using 2.6.1-rc1-mm1. As well as what happens
there w/ clock=crazy.
thanks so much for the feedback.
-john
On Monday 05 January 2004 05:11 pm, john stultz wrote:
> If the override boot option failed, its most likely your system doesn't
> have an ACPI PM time source. Instead it seems your system is having
> trouble using the PIT as a time source (which seems not all that
> uncommon unfortunately).
>
Or that Karol's laptop has ACPI PM timer that is accessed through the
memory (ACPI_ADR_SPACE_SYSTEM_MEMORY), is there such implementations?
Right now timer_pm.c only supports IO-port based timer access.
Dmitry
Thus wrote Dmitry Torokhov:
> Or that Karol's laptop has ACPI PM timer that is accessed through the
> memory (ACPI_ADR_SPACE_SYSTEM_MEMORY), is there such implementations?
> Right now timer_pm.c only supports IO-port based timer access.
Apparently, the PM timer now works as of 2.6.1-mm4:
#v+
Detected 1700.569 MHz processor.
Using pmtmr for high-res timesource
#v-
But the BogoMIPS loop is still wrong:
#v+
Calibrating delay loop... 1683.45 BogoMIPS
#v-
It looks as if it needed to be multiplied by two, right?
Additionally, the /proc/cpuinfo is not updated on governor change (I'm
using the speedstep-ich driver which otherwise works fine), although the
real CPU frequency certainly is. I'm not sure if this is in any way
related though.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
Thus wrote Dmitry Torokhov:
[...]
Another follow-up, this time the BogoMIPS value is completely
bogus.
#v+
Linux version 2.6.2-rc1-mm2 (sziwan@nadir) (gcc version 3.3.2) #11 Fri Jan 23 22:45:18 CET 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff9000 (usable)
BIOS-e820: 000000000fff9000 - 000000000ffff000 (ACPI data)
BIOS-e820: 000000000ffff000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
zapping low mappings.
On node 0 totalpages: 65529
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61433 pages, LIFO batch:14
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ASUS L3C with broken BIOS detected. Refusing to enable the local APIC.
ACPI: RSDP (v000 ASUS ) @ 0x000f6890
ACPI: RSDT (v001 ASUS P4_L3CS 0x42302e31 MSFT 0x31313031) @ 0x0fff9000
ACPI: FADT (v001 ASUS P4_L3CS 0x42302e31 MSFT 0x31313031) @ 0x0fff9080
ACPI: BOOT (v001 ASUS P4_L3CS 0x42302e31 MSFT 0x31313031) @ 0x0fff9040
ACPI: DSDT (v001 ASUS P4_L3CS 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
Built 1 zonelists
current: c031ea60
current->thread_info: c0386000
Initializing CPU#0
Kernel command line: BOOT_IMAGE=2.6 ro root=305 resume=/dev/hda1 acpi_sleep=s3_bios clock=pmtmr
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 1700.567 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Memory: 255896k/262116k available (1878k kernel code, 5512k reserved, 704k data, 132k init, 0k highmem)
Calibrating delay loop... 8.19 BogoMIPS
#v-
FYI, it was around 1700 BogoMIPS with 2.6.1-mm4 (using pmtmr).
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]