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)
-
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/