![]() | |||||||||||||
Messages in this thread |
> >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 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/ | ||||||||||||
| Last update: 2005-12-09 10:19 [from the cache] ©2003-2008 | |||||||||||||