Re: amd64 cdrom access locks system

Jeff Wiegley
2005-06-10T02:43:40Z

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)