Re: Clock 3x too fast on AMD64 laptop [WAS Re: Various issues after rebooting]

From: Olivier Fourdan (fourdan_at_xfce.org)
Date: 03/31/05

  • Next message: Andi Kleen: "Re: Incorrect comment in leave_mm()?"
    To: john stultz <johnstul@us.ibm.com>, Dominik Brodowski <linux@dominikbrodowski.net>
    Date:	Thu, 31 Mar 2005 21:12:37 +0200
    
    

    Hi John, Dominik,

    On Tue, 2005-03-29 at 14:11 -0800, john stultz wrote:
    > Yea. From your description this is most likely the cause of the issue.
    > Currently the time of day is still tick-based, using the tsc/pmtmr/hpet
    > only for interpolating between ticks.

    Sorry for the late follow up. Unfortunately, a quick hack to disable the
    "pmtmr" check shows that even when "trusting" the PM-Timer, the clock
    and interrupts still run 3x too fast. That makes no difference.

    > Well, if you tried the time of day re-work I've been working on it would
    > mask the issue somewhat, but you'd still have the problem that you are
    > taking too many timer interrupts.

    Where could I get that patch from ? I'd be glad to do some testing for
    you if you need it.

    > One thing you could try is playing with the CLOCK_TICK_RATE value to see
    > if you just have very unique hardware.

    Problem is that the issue shows exactly after one quick power off/power
    on sequence. It doesn't show after a real cold start (leaving the laptop
    off for a couple of hours) or even after a reboot.

    > A similar sounding issue has also been reported here:
    > http://bugme.osdl.org/show_bug.cgi?id=3927

    Not sure if that's the exact same problem. What I can say, after reading
    that bug report, is that disabling ACPI and/or APIC makes no difference.
    Specifying the clock=... makes no difference either. It doesn't seem
    related to the AMD64 part of the kernel since it shows equally when
    using a 64bit kernel and a 32bit kernel.

    Moreover, when that bug shows, there are other different problems
    showing (such as the cdrom not being to mount anything, or ndiswrapper
    crashing the system with a MCE error).

    At first, I thought the issue might be related to the nforce3, but the
    bug refers to an ATI chipset so I guess it's not related to the nforce.

    Anyway, it doesn't seem to be an uncommon issue with AMD64 based
    hardware. I don't know where to start from though.

    Cheers,
    Olivier.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Andi Kleen: "Re: Incorrect comment in leave_mm()?"

    Relevant Pages

    • Re: Giving developers clue how many testers verified certain kernel version
      ... > there is a bug somewhere when one can't really know if that is the way ... even if we can't fix it because of our C and kernel skills. ... There had been need of rain for many days. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Possible shared mapping bug in 2.4.23 (at least MIPS/Sparc)
      ... > Don't blame the kernel - the kernel is only doing what the user asked it ... Surely it's better to fail the mmapon other archs ... It's a bug either way ... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • __make_request() bug and a fix variant
      ... It manifests itself by bread() randomly crashing (in different ... In this case the bug is ... leaving the final solution up to kernel wizards. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
      ... BUG: Unable to handle kernel NULL pointer dereference at virtual address ... And everytime without it, it runs fine. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 1/2] LogFS proper
      ... Please comment the structure with kernel doc comments and avoid the tail ... Do enums have a significant ... Also the BUG itself will give you enough clue where it happened, ... which leaves only the prepared filesystem image to worry about. ...
      (Linux-Kernel)