> >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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
