Bug 6104

Original downstream report is at http://bugs.gentoo.org/120362

A workaround is known (clock=pmtmr notsc), so if this is one of those things
that just can't be fixed by default please close this bug.

However, it would obviously be nice if this could work out of the box.

clock=pmtmr doesn't exist on the 64bit kernel and notsc should
be automatically selected on the X2. Please give full boot log
without any options.

It was broken on the -mm* kernels, but linus kernels should be 
ok. Can you double check you're not using an -mm* kernel?

Andi,

It's not a complete log and it is not from a boot with no added parameters, but
maybe this helps (taken from downstream bug):

Kernel command line: ro root=/dev/sda6 video=vesafb:mtrr,ywrap,1024x768-32@85
clock=pmtmr notsc
notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Warning: clock= override failed. Defaulting to PIT
Detected 2010.493 MHz processor.
Using pit for high-res timesource

It looks like you are correct in saying that notsc has no effect and pmtmr is
not available -- however it looks like the invalid "clock=" argument is causing
the kernel to fall back on PIT, maybe it defaults to some other source when no
argument is given?

Widu, please attach a "dmesg" log from a 2.6.16-rc4 boot with no additional
parameters when convenient.

No i need the full log without any options (clock=.... notsc)
The point is to find out why notsc isn't used by default on this
machine as it should.

Also can you confirm this is really a vanilla linus kernel without 
any additional patches?

It appears you're running a 32bit i386-arch kernel, is that correct?  
 

Yes john is right. Sorry my earlier comments only applied to 64bit kernels
(which should do this correctly)

But it looks like 32bit needs fixing.

hi,
sorry for being late with additional information, but the machine serves as a
ltsp-server in our workshop, so I don't "play around" with it during daytime.
so:
yes the kernel (2.6.16-rc4) is pure vanilla without any patches.
and yes I'm running a 32bit i386-arch kernel.
because bootloging doesn't work right on that machine, I can only provide you
the full output of dmesg, directly after reboot without any additional kernel
parameters. And because that's a bit long, I did put it here:
http://www.radgeber-freiburg.de/widu/dmesg.log
If that's not usable, I have to collect some info first of how to make
bootlogging work.

Could you ensure that CONFIG_X86_PM_TIMER is enabled in your config? 

Are you sure you have CONFIG_X86_PM_TIMER enabled?

It doesn't look like it from the boot log. 

I took a look at the 32bit code
and it should definitely try the pmtmr before the tsc timer (that's a bit
inefficient, but should have correct results)

>> Could you ensure that CONFIG_X86_PM_TIMER is enabled in your config?
no, indeed its not set. Should it be set?, If so I could recompile the kernel,
but could test it only tomorrow, cause I only have ssh acces for now. 

Yes it should.

Also your clock=pmtmr thing couldn't have possibly worked. Most
likely you fell back to PIT timer because of the notsc.

John - in the 64bit kernel i made it an CONFIG_EMBEDDED option. 
would be probably a good idea for 32bit too. Can you perhaps
send akpm a patch for that for 2.6.16?
The only people left in the rain would be those that compile without
CONFIG_ACPI then, but these tend to be real oddballs.

now I enabled CONFIG_X86_PM_TIMER and it seems to work. Since the machine is a
desktop system I didn't care much about acpi, and there's nothing in the help
text, that tells me I should enable it if I'm building an SMP kernel. maybe you
could add something like that.
thanks a lot for your help
widu

You have ACPI already enabled.

I don't have rights to close the bug,  but someone should set it to INVALID

Thanks.