Re: amd64 cdrom access locks system

[Jeff Wiegley <jeffw@cyte.com>]

The answer to what timer is getting used appears to be:

   time.c: Using 3.579545 MHz PM timer.
   time.c: Detected 2612.615 MHz processor.
   time.c: Using HPET/TSC based timekeeping.

I'm still waiting for the compile to complete to test
Mr. Morton's workaround. Should have results posted
in about 15 minutes.

Thanks,

- Jeff

Venkatesh Pallipadi wrote:
> 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


-- 
Jeff Wiegley, PhD
Cyte.Com, LLC
(ignore:cea2d3a38843531c7def1deff59114de)