On Thu, Jun 09, 2005 at 04:00:45PM -0700, Andrew Morton wrote:
> Jeff Wiegley <[email protected]> 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
-
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]
