On Thu, Jun 09, 2005 at 04:00:45PM -0700, Andrew Morton wrote:
Jeff Wiegley <jeffw@xxxxxxxx> wrote:
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip default_idle+0x24/0x30
Falling back to HPET
divide error: 0000 [1] PREEMPT
...
RIP: 0010:[<ffffffff80112704>] <ffffffff80112704>{timer_interrupt+244}
The timer code got confused, fell back to the HPET timer and then got a
divide-by-zero in timer_interrupt(). Probably because variable hpet_tick
is zero.
- It's probably a bug that the cdrom code is holding interrupts off for
too long.
Use hdparm and dmesg to see whether the driver is using DMA. If it
isn't, fiddle with it until it is.
- It's possibly a bug that we're falling back to HPET mode just because
the cdrom driver is being transiently silly.
- It's surely a bug that hpet_tick is zero after we've switched to HPET mode.
Please test this workaround:
Only reason I can see for hpet_tick to be zero is when there was some error in hpet_init(), and we start using PIT. But, later we try to fallback to an uninitilized HPET.
Can you look at your dmesg before the hang and check what timer is getting used?
The dmesg line will look something like this...
time.c: Using ______ MHz ___ timer.
Thanks,
Venki