Re: amd64 cdrom access locks system

[Jeff Wiegley <jeffw@cyte.com>]

Your workaround does indeed seem to work around the problem.
I can rip tracks from a cd now and I don't get a lock up
anymore.

But the first time I do something with the CD I get this...

warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts.
rip __do_softirq+0x48/0xb0
Falling back to HPET

 From then on I'm guessing I'm using the HPET and I don't
get any more of these warnings.

I did check on DMA on for the device. I can't get it
to support DMA...

root@mail:/root# hdparm -d 1 /dev/hda

/dev/hda:
  setting using_dma to 1 (on)
  HDIO_SET_DMA failed: Operation not permitted
  using_dma    =  0 (off)

I don't know what else to "fiddle" with to get it working. My guess is 
that DMA is not currently supported at all for the chipset/motherboard
I have. (As I said before, lspci seems to indicate that a lot of stuff
on this motherboard is "unknown" hardware; would be nice to get it
"known" but I don't know how. I can only be somebody's guinea pig for
patches ;-) Or maybe I am missing some trick to enabling DMA? I have
it enabled by default in my kernel .config

Anyhow, thanks for the work around. I can at least use my burner now.
Though I suspect you want a "real" fix sometime as for why the HPET
tick obtained a 0 value.  If you want me to test another patch
towards this goal just let me know.

- Jeff

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:
> 
> 
>  arch/x86_64/kernel/time.c |   13 +++++++++----
>  1 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff -puN arch/x86_64/kernel/time.c~x86_64-div-by-zero-fix arch/x86_64/kernel/time.c
> --- 25/arch/x86_64/kernel/time.c~x86_64-div-by-zero-fix	Thu Jun  9 15:51:50 2005
> +++ 25-akpm/arch/x86_64/kernel/time.c	Thu Jun  9 15:53:08 2005
> @@ -75,6 +75,11 @@ unsigned long __wall_jiffies __section_w
>  struct timespec __xtime __section_xtime;
>  struct timezone __sys_tz __section_sys_tz;
>  
> +static inline unsigned long fixed_hpet_tick(void)
> +{
> +	return hpet_tick ? hpet_tick : 1;
> +}
> +
>  static inline void rdtscll_sync(unsigned long *tsc)
>  {
>  #ifdef CONFIG_SMP
> @@ -305,7 +310,7 @@ unsigned long long monotonic_clock(void)
>  
>  		} while (read_seqretry(&xtime_lock, seq));
>  		offset = (this_offset - last_offset);
> -		offset *=(NSEC_PER_SEC/HZ)/hpet_tick;
> +		offset *=(NSEC_PER_SEC/HZ)/fixed_hpet_tick();
>  		return base + offset;
>  	}else{
>  		do {
> @@ -393,11 +398,11 @@ static irqreturn_t timer_interrupt(int i
>  
>  	if (vxtime.mode == VXTIME_HPET) {
>  		if (offset - vxtime.last > hpet_tick) {
> -			lost = (offset - vxtime.last) / hpet_tick - 1;
> +			lost = (offset - vxtime.last) / fixed_hpet_tick() - 1;
>  		}
>  
> -		monotonic_base += 
> -			(offset - vxtime.last)*(NSEC_PER_SEC/HZ) / hpet_tick;
> +		monotonic_base +=  (offset - vxtime.last)*(NSEC_PER_SEC/HZ) /
> +					fixed_hpet_tick();
>  
>  		vxtime.last = offset;
>  #ifdef CONFIG_X86_PM_TIMER
> _


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