Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

["Jan Beulich" <JBeulich@novell.com>]

>>> Andi Kleen <ak@suse.de> 08.12.05 23:47:35 >>>
>On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
>> I don't know how resume normally handles the re-syncing of the wall
>> clock, but the problem here is obvious: do_timer runs a loop to
>> increment jiffies, which may require significant amounts of time
>> (depending how long the system was sleeping).
>
>It would be good if someone could submit a patch to fix
>this up properly. It indeed sounds wrong.

With the nlkd patches I actually submitted code that does deal with the
calculation when significant amounts of ticks have been missed. However,
this is only part of the problem. What is more important first is for
the resume code to tell the timer interrupt handlers that it shouldn't
consider the last TSC (or other time stamp) value read prior to suspend,
but rather start anew.

>The HPET patch seems to be generally unhappy. With it applied
>I get lots of obviously wrong softlockup warnings from the
>softlockup watchdog thread on a dual NForce4 system. So something
>goes wrong with the timing there. The strange thing 
>is that the system doesn't even have a HPET table so HPET code
shouldn't
>be executed - but it goes away when I revert the patch. Very
>mysterious.

It doesn't only change the HPET code, the TSC code was suffering from
overflow problems, too, which the patch also tries to address. I can't,
however, see where or how it would cause softlockup reports. Do the
printed call stacks provide any useful information?

>Also I think vgettimeofday doesn't handle 64bit HPET correctly
>yet. Also why does it not use hpet_readq? 

For the simple reason that there is no way to know whether the entire
interconnect from CPU to HPET is (at least) 64 bits wide. At least
theoretically implementations are permitted to use 32-bit components;
the HPET spec specifically warns about that.

>I suspect the 64bit HPET patch needs some more cooking. I think
>I will drop it for now.
>
>I would suggest you submit the cleanups in there separately
>(without changing semantics yet) 
>then it will be easier to test in the future too.

What cleanups are you referring to here?

Jan

-
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/