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

Andi Kleen
2005-12-09T09:16:08Z

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

No they occur in random places - often even in idle.

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

Doesn't that refer to the CPUs ?

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

Like the removal of the HPET.*DANGEROUS hack and some others.

-Andi