Re: amd64 cdrom access locks system

From: Jeff Wiegley
Date: Thu Jun 09 2005 - 20:27:57 EST


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@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


--
Jeff Wiegley, PhD
Cyte.Com, LLC
(ignore:cea2d3a38843531c7def1deff59114de)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/