Re: amd64 cdrom access locks system

[Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>]

On Thu, Jun 09, 2005 at 04:00:45PM -0700, Andrew Morton wrote:
> Jeff Wiegley <jeffw@cyte.com> 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 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/