Re: amd64 cdrom access locks system

Jeff Wiegley
2005-06-10T01:26:49Z

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)