amd64 cdrom access locks system

amd64 cdrom access locks system

[Jeff Wiegley]

I've been having this problem in 2.6.12-rc2 and 2.6.12-rc6.

Any continued access to /dev/hda causes a complete and total
lock up of the system. Nothing is logged to /var/log/kernel
or /var/log/messages. Just a solid freeze.

This happens with at least cdparanoia and cdrecord as well.

The machine is an AMD64 FX55 CPU running in a shuttle
ST20G5 chassis.

The specs for the chipset say:
   ATi RADEON XPRESS 200 + ULi 1573 chipset

lspci produces (but doesn't say anything about the spec'ed chips):
0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5950 (rev 01)
0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f
0000:00:06.0 PCI bridge: ATI Technologies Inc: Unknown device 5a38
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
0000:00:19.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge
0000:00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0000:00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0000:00:1c.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
0000:00:1c.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01)
0000:00:1d.0 0403: ALi Corporation: Unknown device 5461
0000:00:1e.0 ISA bridge: ALi Corporation: Unknown device 1573 (rev 31)
0000:00:1e.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
0000:00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7)
0000:00:1f.1 RAID bus controller: ALi Corporation: Unknown device 5287 
(rev 02)
0000:01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown 
device 5954
0000:02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 
Gigabit Ethernet PCI Express (rev 01)
0000:03:15.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host 
Controller (rev 80)
0000:03:16.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O 
Controller(rev 01)

Any ideas? I would really like to see this go away before 2.6.12
comes out. But it's been present for quite a while.

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

Re: amd64 cdrom access locks system

[Andrew Morton]

Jeff Wiegley <jeffw@cyte.com> wrote:
>
> I've been having this problem in 2.6.12-rc2 and 2.6.12-rc6.
> 
>  Any continued access to /dev/hda causes a complete and total
>  lock up of the system. Nothing is logged to /var/log/kernel
>  or /var/log/messages. Just a solid freeze.
> 
>  This happens with at least cdparanoia and cdrecord as well.
> 
>  The machine is an AMD64 FX55 CPU running in a shuttle
>  ST20G5 chassis.

Can you identify an earlier kernel which worked OK?

How locked up is it?  Does sysrq-P not work?  Is it pingable?  Tried
enabling the nmi watchdog?

Re: amd64 cdrom access locks system

[Jeff Wiegley]

Andrew Morton wrote:
> Jeff Wiegley <jeffw@cyte.com> wrote:
> 
>>I've been having this problem in 2.6.12-rc2 and 2.6.12-rc6.
>>
>> Any continued access to /dev/hda causes a complete and total
>> lock up of the system. Nothing is logged to /var/log/kernel
>> or /var/log/messages. Just a solid freeze.
>>
>> This happens with at least cdparanoia and cdrecord as well.
>>
>> The machine is an AMD64 FX55 CPU running in a shuttle
>> ST20G5 chassis.
> 
> 
> Can you identify an earlier kernel which worked OK?
> 
> How locked up is it?  Does sysrq-P not work?  Is it pingable?  Tried
> enabling the nmi watchdog?

Sorry for the length of this message. Based on you suggestions I
tried lots of various tests and although none of them fixed the
problem I at least have a wealth of information (possibly useless)
to report here...

When it locks up while running cdparanoia the machine is *not* pingable.

The NMI watchdog doesn't seem to be resetting anything. (Though I've
never used it before so maybe it's not enabled at all even though
I did compile in ACPI and passed nmi_watchdog=1 on the kernel
command line. (/proc/sys/kernel/unknown_nmi_panic is present, if that
helps)

sysrq-P does work. (I won't provide what it spat out since I have a
panic trace instead.)

Ah.. You need to be at a real console and not in X-windows to get
anything from sysrq. (I didn't know that.) anyhow, when I run
"cdparanoia -d /dev/hda 5" from a real console it fires up, copies
a few sectors from the drive and then panics with this... (I didn't
see the panic before because I was in X11)

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
CPU 0
Modules linked in: deflate zlib_deflate twofish serpent aes blowfish des 
sha256 sha1 crypto_null xfrm_user xfrm4_tunnel ipcomp esp4 ah4 af_key 
ipv6 alim15x3 ide_generic reiserfs tun thermal processor fan button ac 
battery i2c_ali15x3 i2c_ali1535 i2c_core ehci_hcd usbhid ohci_hcd tg3 
ohci1394 sbp2 ieee1394 psmouse ide_disk ide_cd ide_core sata_uli sr_mod 
cdrom sd_mod sata_promise libata sg usb_storage scsi_mod unix
Pid: 0, comm: swapper Not tainted 2.6.12-rc6-jw9
RIP: 0010:[<ffffffff80112704>] <ffffffff80112704>{timer_interrupt+244}
RSP: 0000:ffffffff803a09c0  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000010101
R10: 000000000000000e R11: 0000000000000000 R12: ffffffff803a0a38
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff803e1fb0
FS:  00002aaaab1a2640(0000) GS:ffffffff803d9f40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002aaaab51f430 CR3: 0000000074704000 CR4: 00000000000006e0
Process swapper (pid: 0, threadinfo ffffffff803e0000, task ffffffff802f62c0)
Stack: 0000000000000086 ffffffff802f6e00 0000000000000000 ffffffff803a0a38
        0000000000000000 ffffffff801547fc 0000000000000000 0000000000000000
        ffffffff803da040 ffffffff802f6e00
Call Trace: <IRQ> <ffffffff801547fc>{handle_IRQ_event+44} 
<ffffffff80154905>{__do_IRQ+213}
        <ffffffff80111402>{do_IRQ+66} <ffffffff8010edbd>{ret_from_intr+0}
        <ffffffff80138108>{__do_softirq+72} 
<ffffffff801381a5>{do_softirq+53}
        <ffffffff801382bc>{irq_exit+76} <ffffffff80111407>{do_IRQ+71}
        <ffffffff8010edbd>{ret_from_intr+0}  <EOI> 
<ffffffff8010eeed>{retint_kernel+38}
        <ffffffff8010c820>{default_idle+0} 
<ffffffff8010c844>{default_idle+36}
        <ffffffff8010c991>{cpu_idle+49} <ffffffff803e2863>{start_kernel+435}
        <ffffffff803e223f>{x86_64_start_kernel+319}

Code: 48 f7 f6 48 01 05 ba 67 29 00 e9 dd 00 00 00 83 f8 03 75 0d
RIP <ffffffff80112704>{timer_interrupt+244} RSP <ffffffff803a09c0>
  <0>Kernel panic - not syncing: Aiee, killing interrupt handler!

Ummm... I have no idea what to do with all of that; I hope it's
highly meaningful to you. From what I can read it looks like an
interrupt problem since the call trace is all IRQ-thingies.

Would it do any good to try a different physical CDRom drive? The
current one is listed as
     hda: SONY DVD RW DRU-500A, ATAPI CD/DVD-ROM drive.
(I have had problems with it being unable to burn DVD-R under windows 
(blech!) which it should be able to, so maybe the drive is
dead/misbehaving. But I don't want to rip apart my cases and swap
drives if it's a higher level IRQ/driver problem.)

I can use an external USB cdrom reader without problems.

By the way. This shuttle case/motherboard is relatively new and
it seems to have a lot of the chipsets in it that are not recognized
by the kernel:

lspci: [with recognized stuff snipped out]

0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown device 5950 (rev 01)
0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f
0000:00:06.0 PCI bridge: ATI Technologies Inc: Unknown device 5a38
0000:00:1d.0 0403: ALi Corporation: Unknown device 5461
0000:00:1e.0 ISA bridge: ALi Corporation: Unknown device 1573 (rev 31)
0000:00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7)
0000:00:1f.1 RAID bus controller: ALi Corporation: Unknown device 5287 
(rev 02)
0000:01:05.0 VGA compatible controller: ATI Technologies Inc: Unknown 
device 5954

Maybe these unknown devices are causing problems with interrupt
assignments or service? I would be willing to help in any way possible
to get this case/motherboard fully supported but I'm not a chipset
or kernel guru. But I've got some time and I'm willing to reboot
and test as much as is needed.

Back to the CD burner. I think 2.6.8 worked and was the highest
working kernel. And if I remember correctly it worked really slow
(max speed 4 or 8) because DMA couldn't be enabled for the device. But
I can't confirm that now since I had to switch to 2.6.9 or higher to
get the ULI serial ATA driver. So now I can't boot 2.6.8 on this machine
because it won't find a root filesystem. (I borrowed a promise SATA
card to do the original install.)

Hmmm.. hdparm /dev/hda:
  IO_support   =  0 (default 16-bit)
  unmaskirq    =  0 (off)
  using_dma    =  0 (off)
  keepsettings =  0 (off)
  readonly     =  0 (off)
  readahead    = 256 (on)
  HDIO_GETGEO failed: Invalid argument

and I cannot manually enable DMA either (I kind of expected to be able
to)...
root@mail:~# hdparm -d 1 /dev/hda

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

Sorry I can't help more. The deepest I ever got in to the kernel
workings was a port mapped non-interrupt driven device driver for
an NTSC capture device (subject to NDA) in the 2.2 kernel. Everything
else is grand voodoo to me.

I hope you can help with this. Thanks.

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

Re: amd64 cdrom access locks system

[Jeff Wiegley]

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)

Re: amd64 cdrom access locks system

[Jeff Wiegley]

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)

Re: amd64 cdrom access locks system

[Jeff Wiegley]

Doh!! Apparently I'm not as sharp as I think I am...

In looking into the DMA enable issue I came across
a thread in google that indicated that somebody else
couldn't get DMA on ALI M5229 IDE controller to work
and the suggestion was to make sure Generic IDE
controller support was NOT enabled in the kernel.

I took that advice. recompiled another kernel
with generic IDE support disabled (I did have it enabled
because I didn't know exactly what IDE controller
this had since ALI M5229 wasn't an option, though
I also enabled the alim15x3 driver just in case.)
Well having them both there seems to be what caused
the error.

When I compiled out the generic IDE stuff I also
avoided the recent workaround you provided. (Just to
see if it was needed when using the alim15x3 driver
or whether the presence of generic IDE was the root
of all of my problems.

Now, when I access the cdrom drive it does not lock
up. It doesn't even print anything about "many lost
ticks" anymore either.

But! I can only read from it (cdparanoia) I can't
write to it and this seems to be kernel related.

When I do:
    cdrecord -v -eject -dao dev=ATAPI:/dev/hda something.iso
cdrecord comes up and spits out:
...
   Warning: Using ATA Packet interface.
   Warning: The related Linux kernel interface code seems to be 
unmaintained.
   Warning: There is absolutely NO DMA, operations thus are slow.
   Using libscg version 'ubuntu-0.8ubuntu1'.
   cdrecord: Warning: using inofficial version of libscg 
(ubuntu-0.8ubuntu1 '@(#)scsitransp.c      1.91 04/06/17 Copyright 
1988,1995,2000-2004 J. Schilling').
   SCSI buffer size: 64512
   atapi: 1
   Device type    : Removable CD-ROM
   Version        : 0
   Response Format: 2
   Capabilities   :
   Vendor_info    : 'SONY    '
   Identifikation : 'DVD RW DRU-500A '
   Revision       : '2.0h'
   Device seems to be: Generic mmc2 DVD-R/DVD-RW.
   Current: 0x0009
   Profile: 0x001B
   Profile: 0x001A
   Profile: 0x0014
   Profile: 0x0013
   Profile: 0x0011
   Profile: 0x0010
   Profile: 0x000A
   Profile: 0x0009 (current)
   Profile: 0x0008
And then the cdrom device hangs. Not the whole machine, just the
cdrom drive. (I'm typing this while the cdrom drive is locked up
for instance) It never even starts to write anything.

What I do get after quite a wait in /var/log/kern.log is:
Jun  9 14:43:00 localhost kernel: ide-cd: cmd 0x3 timed out
Jun  9 14:43:00 localhost kernel: hda: lost interrupt
Jun  9 14:44:00 localhost kernel: ide-cd: cmd 0x3 timed out
Jun  9 14:44:00 localhost kernel: hda: lost interrupt
Jun  9 14:45:00 localhost kernel: hda: lost interrupt

So it looks like something is wrong with interrupt handling
still.

After a *very* long time the process seems to die and exit.
(Until I recompiled with some different options...)

I recompiled another kernel but this time:
   - I turned off the PM timer since I seem to have a HPET timer.
   - I turned off packet writing for CD writers.
   - I added back in the workaround patch you recently gave me.

Nothing of that helped. (And now it looks like no matter how
long I wait the stuck cd drive process doesn't seem to exit
ever.

So in summary:
    Reading works without the workaround patch but not if the
    generic IDE driver is in charge.
    Writing doesn't work under any circumstance.

That's all the compiling and rebooting I can handle for today.
Tomorrow I will try to turn on SCSI emulation and see if that
allows writing to work.

At least I can read CDs now though. Any thoughts on writing?

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

Re: amd64 cdrom access locks system

[Andrew Morton]

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
_

Re: amd64 cdrom access locks system

[Venkatesh Pallipadi]

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

Re: amd64 cdrom access locks system

[Robert Hancock]

Jeff Wiegley wrote:
>    cdrecord -v -eject -dao dev=ATAPI:/dev/hda something.iso
> cdrecord comes up and spits out:
> ...
>   Warning: Using ATA Packet interface.
>   Warning: The related Linux kernel interface code seems to be 
> unmaintained.
>   Warning: There is absolutely NO DMA, operations thus are slow.

I don't think this is the interface option you want to be using - try 
just dev=/dev/hda. I don't know if this is why you were getting errors 
though.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: amd64 cdrom access locks system

[Jeff Wiegley]

Andrew Morton said I should carbon copy the IDE developer on this
issue so I have in the hopes of re-opening this issue and making
some progress since I'm still unable to write anything with my
cd-burner.

Here's what I know to date:

    I have the alim15x3 IDE driver installed and running.
    I do NOT have any of the generic IDE drivers installed or
       even compiled as they grossly interfere with the alim15x3
       and cause a kernel panic.
    My hardware is an AMD64 FX55 in a Shuttle ST20G5 case with a
       serial ATA harddrive.
    I'm using a stock 2.6.12-rc6 kernel.
    Debian unstable distribution.

At first I can read from the drive fine.
    For instance I did two "cdparanoia -B -d /dev/hda" without
    a hitch. Nothing was reported in /var/log/kernel as a result.

The problem is that I can't write to the drive (burn cds with
cdrecord) with causing a lost interrupt and then nothing works;
even reads don't respond.

When I do:
    cdrecord -v -tao dev=ATAPI:/dev/hda something.iso

I get this output:
   Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C) 
1995-2004 Joerg Schilling
   NOTE: this version of cdrecord is an inofficial (modified) release of 
cdrecord
         and thus may have bugs that are not present in the original 
version.
         Please send bug reports and support requests to 
<cdrtools@packages.debian.org>.
         The original author should not be bothered with problems of 
this version.

   cdrecord: Warning: Running on Linux-2.6.12-rc6-jw14
   cdrecord: There are unsettled issues with Linux-2.5 and newer.
   cdrecord: If you have unexpected problems, please try Linux-2.4 or 
Solaris.
   TOC Type: 1 = CD-ROM
   scsidev: 'ATAPI:/dev/hda'
   devname: 'ATAPI:/dev/hda'
   scsibus: -2 target: -2 lun: -2
   Warning: Using ATA Packet interface.
   Warning: The related Linux kernel interface code seems to be 
unmaintained.
   Warning: There is absolutely NO DMA, operations thus are slow.
   Using libscg version 'ubuntu-0.8ubuntu1'.
   cdrecord: Warning: using inofficial version of libscg 
(ubuntu-0.8ubuntu1 '@(#)scsitransp.c      1.91 04/06/17 Copyright 
1988,1995,2000-2004 J. Schilling').
   SCSI buffer size: 64512
   atapi: 1
   Device type    : Removable CD-ROM
   Version        : 0
   Response Format: 2
   Capabilities   :
   Vendor_info    : 'SONY    '
   Identifikation : 'DVD RW DRU-500A '
   Revision       : '2.0h'
   Device seems to be: Generic mmc2 DVD-R/DVD-RW.
   Current: 0x0009
   Profile: 0x001B
   Profile: 0x001A
   Profile: 0x0014
   Profile: 0x0013
   Profile: 0x0011
   Profile: 0x0010
   Profile: 0x000A
   Profile: 0x0009 (current)
   Profile: 0x0008

And nothing else happens. (The drive light isn't even lit.)
The machine isn't locked up. (I'm typing this as it happened.)

after a minute, or so, /var/log/kern.log reports this:
   Jun 13 08:57:25 localhost kernel: ide-cd: cmd 0x3 timed out
   Jun 13 08:57:25 localhost kernel: hda: lost interrupt

A bit later (exactly one minute) kern.log again reports:
   Jun 13 08:58:25 localhost kernel: ide-cd: cmd 0x3 timed out
   Jun 13 08:58:25 localhost kernel: hda: lost interrupt

Then nothing else seems to happen through I've waited several minutes
more.

When I try to Ctrl-C the cdrecord process, it seems to be ignored.
But many minutes later the process dies after kern.log logs:
   Jun 13 09:05:05 localhost kernel: hda: lost interrupt
   Jun 13 09:06:05 localhost kernel: ide-cd: cmd 0x1e timed out
   Jun 13 09:06:05 localhost kernel: hda: lost interrupt

after this point all access to the cd drive takes a *very* long
time to complete (or doesn't seem to complete at all).
The first time I did: eject -v /dev/hda it took several minutes to
complete. During which time kern.log again reports:
   Jun 13 09:18:20 localhost kernel: hda: lost interrupt
   Jun 13 09:19:20 localhost kernel: hda: lost interrupt
   Jun 13 09:20:20 localhost kernel: ide-cd: cmd 0x1e timed out
   Jun 13 09:20:20 localhost kernel: hda: lost interrupt

The second time I did eject it didn't seem to complete at all and
kern.log reported:
   Jun 13 09:18:20 localhost kernel: hda: lost interrupt
   Jun 13 09:19:20 localhost kernel: hda: lost interrupt
   Jun 13 09:20:20 localhost kernel: ide-cd: cmd 0x1e timed out
   Jun 13 09:20:20 localhost kernel: hda: lost interrupt
   Jun 13 09:21:43 localhost kernel: hda: lost interrupt
   Jun 13 09:22:43 localhost kernel: ide-cd: cmd 0x3 timed out
   Jun 13 09:22:43 localhost kernel: hda: lost interrupt
   Jun 13 09:23:42 localhost kernel: ide-cd: cmd 0x3 timed out
   Jun 13 09:23:42 localhost kernel: hda: lost interrupt
   Jun 13 09:24:44 localhost kernel: hda: lost interrupt
   Jun 13 09:25:44 localhost kernel: hda: lost interrupt
   Jun 13 09:26:44 localhost kernel: ide-cd: cmd 0x25 timed out
   Jun 13 09:26:44 localhost kernel: hda: lost interrupt
   Jun 13 09:27:44 localhost kernel: ide-cd: cmd 0x25 timed out
   Jun 13 09:27:44 localhost kernel: hda: lost interrupt
   Jun 13 09:28:44 localhost kernel: hda: lost interrupt
   Jun 13 09:29:44 localhost kernel: hda: lost interrupt
   Jun 13 09:30:44 localhost kernel: hda: lost interrupt
   Jun 13 09:31:44 localhost kernel: hda: lost interrupt
   Jun 13 09:32:44 localhost kernel: hda: lost interrupt
   Jun 13 09:33:44 localhost kernel: hda: lost interrupt

Any ideas on how I can fix this?

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

Re: amd64 cdrom access locks system

[Bartlomiej Zolnierkiewicz]

[ Jens added to cc: ]

On 6/13/05, Jeff Wiegley <jeffw@cyte.com> wrote:
> Andrew Morton said I should carbon copy the IDE developer on this
> issue so I have in the hopes of re-opening this issue and making
> some progress since I'm still unable to write anything with my
> cd-burner.
> 
> Here's what I know to date:
> 
>     I have the alim15x3 IDE driver installed and running.
>     I do NOT have any of the generic IDE drivers installed or
>        even compiled as they grossly interfere with the alim15x3
>        and cause a kernel panic.
>     My hardware is an AMD64 FX55 in a Shuttle ST20G5 case with a
>        serial ATA harddrive.
>     I'm using a stock 2.6.12-rc6 kernel.
>     Debian unstable distribution.
> 
> At first I can read from the drive fine.
>     For instance I did two "cdparanoia -B -d /dev/hda" without
>     a hitch. Nothing was reported in /var/log/kernel as a result.
> 
> The problem is that I can't write to the drive (burn cds with
> cdrecord) with causing a lost interrupt and then nothing works;
> even reads don't respond.
> 
> When I do:
>     cdrecord -v -tao dev=ATAPI:/dev/hda something.iso
> 
> I get this output:
>    Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C)
> 1995-2004 Joerg Schilling
>    NOTE: this version of cdrecord is an inofficial (modified) release of
> cdrecord
>          and thus may have bugs that are not present in the original
> version.
>          Please send bug reports and support requests to
> <cdrtools@packages.debian.org>.
>          The original author should not be bothered with problems of
> this version.
> 
>    cdrecord: Warning: Running on Linux-2.6.12-rc6-jw14
>    cdrecord: There are unsettled issues with Linux-2.5 and newer.
>    cdrecord: If you have unexpected problems, please try Linux-2.4 or
> Solaris.
>    TOC Type: 1 = CD-ROM
>    scsidev: 'ATAPI:/dev/hda'
>    devname: 'ATAPI:/dev/hda'
>    scsibus: -2 target: -2 lun: -2
>    Warning: Using ATA Packet interface.
>    Warning: The related Linux kernel interface code seems to be
> unmaintained.

^^^

>    Warning: There is absolutely NO DMA, operations thus are slow.

^^^

What is the result of using "dev=/dev/hda" interface instead
(as suggested by Robert)?

Bartlomiej

Re: amd64 cdrom access locks system

[Jeff Wiegley]

using "dev=/dev/hda" yeilds the exact same behavior...

   Jun 14 03:21:50 localhost kernel: ide-cd: cmd 0x3 timed out
   Jun 14 03:21:50 localhost kernel: hda: lost interrupt
   Jun 14 03:22:50 localhost kernel: ide-cd: cmd 0x3 timed out
   Jun 14 03:22:50 localhost kernel: hda: lost interrupt
   Jun 14 03:23:30 localhost kernel: hda: lost interrupt

And I'm a little confused by Robert's suggestion... Should it
ever be possible for a user-space application to cause lost
interrupts and other kernel state problems regardless of what
"interface" is used?? Sure, if the application uses the wrong
interface it should get spanked somehow but should it be able to
mess up the kernel for other applications as well? (Like now
I can't read or eject.)

The output from the cdrecord command was:
   root@mail:~# cdrecord -v -eject -tao dev=/dev/hda stupid.iso
   Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C) 
1995-2004 Joerg Schilling
   NOTE: this version of cdrecord is an inofficial (modified) release of 
cdrecord
         and thus may have bugs that are not present in the original 
version.
         Please send bug reports and support requests to 
<cdrtools@packages.debian.org>.
         The original author should not be bothered with problems of 
this version.

   cdrecord: Warning: Running on Linux-2.6.12-rc6-jw14
   cdrecord: There are unsettled issues with Linux-2.5 and newer.
   cdrecord: If you have unexpected problems, please try Linux-2.4 or 
Solaris.
   TOC Type: 1 = CD-ROM
   scsidev: '/dev/hda'
   devname: '/dev/hda'
   scsibus: -2 target: -2 lun: -2
   Warning: Open by 'devname' is unintentional and not supported.
   Linux sg driver version: 3.5.27
   Using libscg version 'ubuntu-0.8ubuntu1'.
   cdrecord: Warning: using inofficial version of libscg 
(ubuntu-0.8ubuntu1 '@(#)scsitransp.c      1.91 04/06/17 Copyright 
1988,1995,2000-2004 J. Schilling').
   SCSI buffer size: 64512
   atapi: 1
   Device type    : Removable CD-ROM
   Version        : 0
   Response Format: 2
   Capabilities   :
   Vendor_info    : 'SONY    '
   Identifikation : 'DVD RW DRU-500A '
   Revision       : '2.0h'
   Device seems to be: Generic mmc2 DVD-R/DVD-RW.
   Current: 0x0009
   Profile: 0x001B
   Profile: 0x001A
   Profile: 0x0014
   Profile: 0x0013
   Profile: 0x0011
   Profile: 0x0010
   Profile: 0x000A
   Profile: 0x0009 (current)
   Profile: 0x0008

Since the kernel gets messed up and reports losts interrupts I'm
inclined to believe that this is a kernel/driver issue and not my
misuse of an application/interface. Though I realize cdrecord is
being run as the superuser and therefore might be overiding some
kernel security checks and messing with the kernel so I might be
wrong about that.

One question comes to mind... Would Robert's suggestion and my
results be affected by the fact that I don't have Packet Writing
for CD drives turned on the current kernel?

Any other ideas?

Bartlomiej Zolnierkiewicz wrote:
> [ Jens added to cc: ]
> 
> On 6/13/05, Jeff Wiegley <jeffw@cyte.com> wrote:
> 
>>Andrew Morton said I should carbon copy the IDE developer on this
>>issue so I have in the hopes of re-opening this issue and making
>>some progress since I'm still unable to write anything with my
>>cd-burner.
>>
>>Here's what I know to date:
>>
>>    I have the alim15x3 IDE driver installed and running.
>>    I do NOT have any of the generic IDE drivers installed or
>>       even compiled as they grossly interfere with the alim15x3
>>       and cause a kernel panic.
>>    My hardware is an AMD64 FX55 in a Shuttle ST20G5 case with a
>>       serial ATA harddrive.
>>    I'm using a stock 2.6.12-rc6 kernel.
>>    Debian unstable distribution.
>>
>>At first I can read from the drive fine.
>>    For instance I did two "cdparanoia -B -d /dev/hda" without
>>    a hitch. Nothing was reported in /var/log/kernel as a result.
>>
>>The problem is that I can't write to the drive (burn cds with
>>cdrecord) with causing a lost interrupt and then nothing works;
>>even reads don't respond.
>>
>>When I do:
>>    cdrecord -v -tao dev=ATAPI:/dev/hda something.iso
>>
>>I get this output:
>>   Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C)
>>1995-2004 Joerg Schilling
>>   NOTE: this version of cdrecord is an inofficial (modified) release of
>>cdrecord
>>         and thus may have bugs that are not present in the original
>>version.
>>         Please send bug reports and support requests to
>><cdrtools@packages.debian.org>.
>>         The original author should not be bothered with problems of
>>this version.
>>
>>   cdrecord: Warning: Running on Linux-2.6.12-rc6-jw14
>>   cdrecord: There are unsettled issues with Linux-2.5 and newer.
>>   cdrecord: If you have unexpected problems, please try Linux-2.4 or
>>Solaris.
>>   TOC Type: 1 = CD-ROM
>>   scsidev: 'ATAPI:/dev/hda'
>>   devname: 'ATAPI:/dev/hda'
>>   scsibus: -2 target: -2 lun: -2
>>   Warning: Using ATA Packet interface.
>>   Warning: The related Linux kernel interface code seems to be
>>unmaintained.
> 
> 
> ^^^
> 
> 
>>   Warning: There is absolutely NO DMA, operations thus are slow.
> 
> 
> ^^^
> 
> What is the result of using "dev=/dev/hda" interface instead
> (as suggested by Robert)?
> 
> Bartlomiej


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

Re: amd64 cdrom access locks system

[Bartlomiej Zolnierkiewicz]

On 6/14/05, Jeff Wiegley <jeffw@cyte.com> wrote:
> using "dev=/dev/hda" yeilds the exact same behavior...
> 
>    Jun 14 03:21:50 localhost kernel: ide-cd: cmd 0x3 timed out
>    Jun 14 03:21:50 localhost kernel: hda: lost interrupt
>    Jun 14 03:22:50 localhost kernel: ide-cd: cmd 0x3 timed out
>    Jun 14 03:22:50 localhost kernel: hda: lost interrupt
>    Jun 14 03:23:30 localhost kernel: hda: lost interrupt

Jens, any idea?

> And I'm a little confused by Robert's suggestion... Should it
> ever be possible for a user-space application to cause lost
> interrupts and other kernel state problems regardless of what
> "interface" is used?? Sure, if the application uses the wrong
> interface it should get spanked somehow but should it be able to
> mess up the kernel for other applications as well? (Like now
> I can't read or eject.)

It shouldn't be possible unless it is "raw" interface
(requires CAP_SYS_RAWIO) w/o checking all possible
parameters (it is not always possible) or device is buggy.

Also it is quite unlikely that somebody will fix obsolete
interface (hey, it got obsoleted for some reason ;-).

> The output from the cdrecord command was:
>    root@mail:~# cdrecord -v -eject -tao dev=/dev/hda stupid.iso
>    Cdrecord-Clone 2.01.01a01 (x86_64-unknown-linux-gnu) Copyright (C)
> 1995-2004 Joerg Schilling
>    NOTE: this version of cdrecord is an inofficial (modified) release of
> cdrecord
>          and thus may have bugs that are not present in the original
> version.
>          Please send bug reports and support requests to
> <cdrtools@packages.debian.org>.
>          The original author should not be bothered with problems of
> this version.
> 
>    cdrecord: Warning: Running on Linux-2.6.12-rc6-jw14
>    cdrecord: There are unsettled issues with Linux-2.5 and newer.
>    cdrecord: If you have unexpected problems, please try Linux-2.4 or
> Solaris.
>    TOC Type: 1 = CD-ROM
>    scsidev: '/dev/hda'
>    devname: '/dev/hda'
>    scsibus: -2 target: -2 lun: -2
>    Warning: Open by 'devname' is unintentional and not supported.
>    Linux sg driver version: 3.5.27
>    Using libscg version 'ubuntu-0.8ubuntu1'.
>    cdrecord: Warning: using inofficial version of libscg
> (ubuntu-0.8ubuntu1 '@(#)scsitransp.c      1.91 04/06/17 Copyright
> 1988,1995,2000-2004 J. Schilling').
>    SCSI buffer size: 64512
>    atapi: 1
>    Device type    : Removable CD-ROM
>    Version        : 0
>    Response Format: 2
>    Capabilities   :
>    Vendor_info    : 'SONY    '
>    Identifikation : 'DVD RW DRU-500A '
>    Revision       : '2.0h'
>    Device seems to be: Generic mmc2 DVD-R/DVD-RW.
>    Current: 0x0009
>    Profile: 0x001B
>    Profile: 0x001A
>    Profile: 0x0014
>    Profile: 0x0013
>    Profile: 0x0011
>    Profile: 0x0010
>    Profile: 0x000A
>    Profile: 0x0009 (current)
>    Profile: 0x0008
> 
> Since the kernel gets messed up and reports losts interrupts I'm
> inclined to believe that this is a kernel/driver issue and not my
> misuse of an application/interface. Though I realize cdrecord is
> being run as the superuser and therefore might be overiding some
> kernel security checks and messing with the kernel so I might be
> wrong about that.
> 
> One question comes to mind... Would Robert's suggestion and my
> results be affected by the fact that I don't have Packet Writing
> for CD drives turned on the current kernel?

No.

Bartlomiej

Re: amd64 cdrom access locks system

[David C. Young]

This is in response to Jeff Wiegley () cyte ! com problem with amd64 and 
ide cdrom.  I tried to contact him directly but the email bounced.  I 
apologize in advance for using kernel list bandwidth to address this.

Jeff,

I have a amd64 running on a Asus board (K8V SE Deluxe) and I have been 
having problems similar to your cdrom lockups.  The board has on-board 
IDE/ATA and SATA.  I am only using two SATA drives and one DVD/CD burner 
on the secondary IDE/ATA connector.

The system lockups occurred with kde (all the time) and gnome 
(occasionally).  I killed the haldaemon and went through 2.6.12.[0-3] 
but I would access, or the haldaemon would access, the cdrom and 
/dev/hdc would lock up, the system would slow down and occasionally lock 
up (in particular during cd-burning).  I got logs full of drive busy, 
drive opcode unknown and drive not ready followed by ATAPI resets.  The 
situation was better but not fixed completely when I disabled the haldaemon.

I solved my cdrom/ide problem by building a custom kernel.  I haven't 
gone back to check all the permutations but I continued having problems 
until I disabled scsi cdrom support.  I left generic scsi and disk 
support on but once the scsi cdrom support was eliminated the slowdowns 
and/or lockups went away.  I did get one error message from trying to 
access past the end of the drive when I tried to mount a blank cd.  Past 
that, my logs are clean of /dev/hdc problems.

It seems to me that the ide-ata works fine in burning mode and the 
generic scsi cdrom support just confuses the issue.  That is only my 
opinion and I don't profess to be a kernel hack.  I do burn iso images 
fairly often and my command is:
	cdrecord dev=/dev/hdc fs=16MB -eject <filename>

Also, I make sure the cpu is running at full speed instead of power 
saving mode and I run as root for the actual burning.

Hope this helps,

David

Re: amd64 cdrom access locks system

[Aric Cyr]

Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> writes:

> 
> On 6/14/05, Jeff Wiegley <jeffw <at> cyte.com> wrote:
> > using "dev=/dev/hda" yeilds the exact same behavior...
> > 
> >    Jun 14 03:21:50 localhost kernel: ide-cd: cmd 0x3 timed out
> >    Jun 14 03:21:50 localhost kernel: hda: lost interrupt
> >    Jun 14 03:22:50 localhost kernel: ide-cd: cmd 0x3 timed out
> >    Jun 14 03:22:50 localhost kernel: hda: lost interrupt
> >    Jun 14 03:23:30 localhost kernel: hda: lost interrupt
> 
> Jens, any idea?
> 
> > And I'm a little confused by Robert's suggestion... Should it
> > ever be possible for a user-space application to cause lost
> > interrupts and other kernel state problems regardless of what
> > "interface" is used?? Sure, if the application uses the wrong
> > interface it should get spanked somehow but should it be able to
> > mess up the kernel for other applications as well? (Like now
> > I can't read or eject.)
> 
> It shouldn't be possible unless it is "raw" interface
> (requires CAP_SYS_RAWIO) w/o checking all possible
> parameters (it is not always possible) or device is buggy.
> 
> Also it is quite unlikely that somebody will fix obsolete
> interface (hey, it got obsoleted for some reason .
> 
> Bartlomiej
> 

Has this problem been fixed at all or any workarounds known?  I am having the
exact same issue with similar hardware and the alim15x3 driver.  In my case it
does not matter which method I use for cdrecord (ATA:, ATAPI: or dev=/dev/hda),
I will always get the lost interrupts from the command "cdrecord -atip".  I have
tried other drives without success so I don't believe that is the problem. 
Interestingly cdrdao does not have any problems at all and burns perfectly, so I
suspect that cdrecord might be throwing some command that ide-cd or the IDE
drive doesn't like and fails to recover from.  However, disabling DMA on the
drive via hdparm makes cdrecord work perfectly, so I suspect the alim15x3 driver
more than anything else.  I can play DVDs for hours with DMA enabled just fine
though... go figure.  My current kernel is 2.6.14-gentoo-r6, but I have had this
problem since I first had got the system (around 2.6.12).

I'm really anxious to track this down so if anyone has any information, or need
something from me (logs or debugging) please don't hesitate to ask.

Regards,
  Aric

Re: amd64 cdrom access locks system

[Christer Bäckström]

 > Aric Cyr <Aric.Cyr () gmail ! com> writes:
> > Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> writes:
> 
>> 
>> On 6/14/05, Jeff Wiegley <jeffw <at> cyte.com> wrote:
>> > using "dev=/dev/hda" yeilds the exact same behavior...
>> > 
>> >    Jun 14 03:21:50 localhost kernel: ide-cd: cmd 0x3 timed out
>> >    Jun 14 03:21:50 localhost kernel: hda: lost interrupt
>> >    Jun 14 03:22:50 localhost kernel: ide-cd: cmd 0x3 timed out
>> >    Jun 14 03:22:50 localhost kernel: hda: lost interrupt
>> >    Jun 14 03:23:30 localhost kernel: hda: lost interrupt
>> 
>> Jens, any idea?
>> 
>> > And I'm a little confused by Robert's suggestion... Should it
>> > ever be possible for a user-space application to cause lost
>> > interrupts and other kernel state problems regardless of what
>> > "interface" is used?? Sure, if the application uses the wrong
>> > interface it should get spanked somehow but should it be able to
>> > mess up the kernel for other applications as well? (Like now
>> > I can't read or eject.)
>> 
>> It shouldn't be possible unless it is "raw" interface
>> (requires CAP_SYS_RAWIO) w/o checking all possible
>> parameters (it is not always possible) or device is buggy.
>> 
>> Also it is quite unlikely that somebody will fix obsolete
>> interface (hey, it got obsoleted for some reason .
>> 
>> Bartlomiej
>> 
> 
> Has this problem been fixed at all or any workarounds known?  I am having the
> exact same issue with similar hardware and the alim15x3 driver.  In my case it
> does not matter which method I use for cdrecord (ATA:, ATAPI: or dev=/dev/hda),
> I will always get the lost interrupts from the command "cdrecord -atip".  I have
> tried other drives without success so I don't believe that is the problem. 
> Interestingly cdrdao does not have any problems at all and burns perfectly, so I
> suspect that cdrecord might be throwing some command that ide-cd or the IDE
> drive doesn't like and fails to recover from.  However, disabling DMA on the
> drive via hdparm makes cdrecord work perfectly, so I suspect the alim15x3 driver
> more than anything else.  I can play DVDs for hours with DMA enabled just fine
> though... go figure.  My current kernel is 2.6.14-gentoo-r6, but I have had this
> problem since I first had got the system (around 2.6.12).

Exactly the same problems here, on a laptop (Amd64, Mandriva 2006, 
linux-2.6.15) with an:

ALi Corporation M5229 IDE (rev c7)

The cd-writer locks up if the DMA is enabled, as above. But the drive is 
usable if it is disabled.

The only other potential problem I've found is that the UDMA timings for 
the /dev/hda is "???" (see below).

----------------------------------------------
#> cat /proc/ide/ali

                                 Ali M15x3 Chipset.
                                 ------------------
PCI Clock: 0.
CD_ROM FIFO:No , CD_ROM DMA:Yes
FIFO Status: contains 1 Words, runs.

----------------primary channel---------secondary channel---------

channel status:       Off			Off
both channels togth:  Yes			Yes
Channel state:        busy			OK
Add. Setup Timing:    1T			1T
Command Act. Count:   3T			3T
Command Rec. Count:   1T			1T

----------------drive0----------drive1----------drive0----------drive1------

DMA enabled:	Yes		No		Yes		No
FIFO threshold:	4 Words		4 Words		4 Words		4 Words
FIFO mode:	FIFO Off	FIFO Off	FIFO Off	FIFO Off
Dt RW act. Cnt	3T		8T		3T		8T
Dt RW rec. Cnt	1T		16T		1T		16T

-----------------------------------UDMATimings--------------------------------

UDMA:		OK		No		OK		No
UDMA timings:	???		1.5T		2.5T		1.5T

--------------------------------------

> 
> I'm really anxious to track this down so if anyone has any information, or need
> something from me (logs or debugging) please don't hesitate to ask.
> 

The same situation here. I've seen a few reports about this behaviour 
with the alim15x3 driver before, so I just wanted to report my problems 
too. If someone has any idea what's happening I'd be glad to try out any 
patches. Please CC me, as I am not subscribed to the list.

/Chris
> Regards,
>   Aric
> 

Re: amd64 cdrom access locks system

[Alan Cox]

On Mer, 2006-01-18 at 01:31 +0100, Christer Bäckström wrote:
> ALi Corporation M5229 IDE (rev c7)
> 
> The cd-writer locks up if the DMA is enabled, as above. But the drive is 
> usable if it is disabled.

Under what circumstances does the writer lock - when writing or in
general ?

Re: amd64 cdrom access locks system

[Bartlomiej Zolnierkiewicz]

On 1/18/06, Christer Bäckström <cbackstrom@letterboxes.org> wrote:
>  > Aric Cyr <Aric.Cyr () gmail ! com> writes:
> > > Bartlomiej Zolnierkiewicz <bzolnier <at> gmail.com> writes:
> >
> >>
> >> On 6/14/05, Jeff Wiegley <jeffw <at> cyte.com> wrote:
> >> > using "dev=/dev/hda" yeilds the exact same behavior...
> >> >
> >> >    Jun 14 03:21:50 localhost kernel: ide-cd: cmd 0x3 timed out
> >> >    Jun 14 03:21:50 localhost kernel: hda: lost interrupt
> >> >    Jun 14 03:22:50 localhost kernel: ide-cd: cmd 0x3 timed out
> >> >    Jun 14 03:22:50 localhost kernel: hda: lost interrupt
> >> >    Jun 14 03:23:30 localhost kernel: hda: lost interrupt
> >>
> >> Jens, any idea?
> >>
> >> > And I'm a little confused by Robert's suggestion... Should it
> >> > ever be possible for a user-space application to cause lost
> >> > interrupts and other kernel state problems regardless of what
> >> > "interface" is used?? Sure, if the application uses the wrong
> >> > interface it should get spanked somehow but should it be able to
> >> > mess up the kernel for other applications as well? (Like now
> >> > I can't read or eject.)
> >>
> >> It shouldn't be possible unless it is "raw" interface
> >> (requires CAP_SYS_RAWIO) w/o checking all possible
> >> parameters (it is not always possible) or device is buggy.
> >>
> >> Also it is quite unlikely that somebody will fix obsolete
> >> interface (hey, it got obsoleted for some reason .
> >>
> >> Bartlomiej
> >>
> >
> > Has this problem been fixed at all or any workarounds known?  I am having the
> > exact same issue with similar hardware and the alim15x3 driver.  In my case it
> > does not matter which method I use for cdrecord (ATA:, ATAPI: or dev=/dev/hda),
> > I will always get the lost interrupts from the command "cdrecord -atip".  I have
> > tried other drives without success so I don't believe that is the problem.
> > Interestingly cdrdao does not have any problems at all and burns perfectly, so I
> > suspect that cdrecord might be throwing some command that ide-cd or the IDE
> > drive doesn't like and fails to recover from.  However, disabling DMA on the
> > drive via hdparm makes cdrecord work perfectly, so I suspect the alim15x3 driver
> > more than anything else.  I can play DVDs for hours with DMA enabled just fine
> > though... go figure.  My current kernel is 2.6.14-gentoo-r6, but I have had this
> > problem since I first had got the system (around 2.6.12).
>
> Exactly the same problems here, on a laptop (Amd64, Mandriva 2006,
> linux-2.6.15) with an:
>
> ALi Corporation M5229 IDE (rev c7)
>
> The cd-writer locks up if the DMA is enabled, as above. But the drive is
> usable if it is disabled.
>
> The only other potential problem I've found is that the UDMA timings for
> the /dev/hda is "???" (see below).
>
> ----------------------------------------------
> #> cat /proc/ide/ali
>
>                                  Ali M15x3 Chipset.
>                                  ------------------
> PCI Clock: 0.
> CD_ROM FIFO:No , CD_ROM DMA:Yes
> FIFO Status: contains 1 Words, runs.
>
> ----------------primary channel---------secondary channel---------
>
> channel status:       Off                       Off
> both channels togth:  Yes                       Yes
> Channel state:        busy                      OK
> Add. Setup Timing:    1T                        1T
> Command Act. Count:   3T                        3T
> Command Rec. Count:   1T                        1T
>
> ----------------drive0----------drive1----------drive0----------drive1------
>
> DMA enabled:    Yes             No              Yes             No
> FIFO threshold: 4 Words         4 Words         4 Words         4 Words
> FIFO mode:      FIFO Off        FIFO Off        FIFO Off        FIFO Off
> Dt RW act. Cnt  3T              8T              3T              8T
> Dt RW rec. Cnt  1T              16T             1T              16T
>
> -----------------------------------UDMATimings--------------------------------
>
> UDMA:           OK              No              OK              No
> UDMA timings:   ???             1.5T            2.5T            1.5T
>
> --------------------------------------
>
> >
> > I'm really anxious to track this down so if anyone has any information, or need
> > something from me (logs or debugging) please don't hesitate to ask.
> >
>
> The same situation here. I've seen a few reports about this behaviour
> with the alim15x3 driver before, so I just wanted to report my problems
> too. If someone has any idea what's happening I'd be glad to try out any
> patches. Please CC me, as I am not subscribed to the list.

This issue is being tracked in the kernel bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=5786

Please add yourself to cc:.

Bartlomiej

Re: amd64 cdrom access locks system

[Christer Bäckström]

Alan Cox skrev:
> On Mer, 2006-01-18 at 01:31 +0100, Christer Bäckström wrote:
> 
>>ALi Corporation M5229 IDE (rev c7)
>>
>>The cd-writer locks up if the DMA is enabled, as above. But the drive is 
>>usable if it is disabled.
> 
> 
> Under what circumstances does the writer lock - when writing or in
> general ?
> 
> 

It locks while writing and using DMA. I get the errors:

ide-cd: cmd 0x3 timed out
hdc: lost interrupt

And the cd-writer hangs. Disabling DMA makes it possible to write
(slowly, and only after rebooting). Reading always works. Other
functions also works while using DMA, like "cdrecord -checkdrive" or
"cdrecord -scanbus". However not things like "cdrecord -dummy".

A few snippets:
-------
lspci -v:
-------
00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a 
[Master SecP PriP])
	Subsystem: Unknown device 1631:c00e
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 255
	I/O ports at 1100 [size=16]
	Capabilities: [60] Power Management version 2
-------

dmesg:
-------
Bootdata ok (command line is BOOT_IMAGE=2615 root=306 noinitrd 
hdc=ide-cdrom resume=/dev/hda5 resume2=/dev/hda5 splash=silent 3)
Linux version 2.6.15 (root@localhost) (gcc version 4.0.1 (4.0.1-5mdk for 
Mandriva Linux release 2006.0)) #7 PREEMPT Sun Jan 8 18:23:09 CET 2006
...
CPU: AMD Turion(tm) 64 Mobile Technology ML-30 stepping 02
...
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:00:1f.0
ACPI: PCI Interrupt 0000:00:1f.0[A]: no GSI
ALI15X3: chipset revision 199
ALI15X3: not 100% native mode: will probe irqs later
     ide0: BM-DMA at 0x1100-0x1107, BIOS settings: hda:DMA, hdb:pio
     ide1: BM-DMA at 0x1108-0x110f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: WDC WD800UE-00HCT0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: _NEC DVD+/-RW ND-6650A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, 
UDMA(100)
hda: cache flushes supported
  hda: hda1 hda2 hda3 < hda5 hda6 >
hdc: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
-------

The irq and ioports in the dmesg are the same as presented in windows, 
if that helps in any way. Bartlomiej Zolnierkiewicz pointed out there 
are a bugzilla entry for this:

http://bugzilla.kernel.org/show_bug.cgi?id=5786

I'm going to look into the posts 'til tomorrow, and continue with this 
problem over there.

Cheers,

/Chris

-- 
Dr. Chris Backstrom, BSc, PhD.

Re: amd64 cdrom access locks system

[Erwin Rol]

On Wed, 2006-01-18 at 01:31 +0100, Christer Bäckström wrote:
>  > Aric Cyr <Aric.Cyr () gmail ! com> writes:
> >> > 
> >> >    Jun 14 03:21:50 localhost kernel: ide-cd: cmd 0x3 timed out
> >> >    Jun 14 03:21:50 localhost kernel: hda: lost interrupt
> >> >    Jun 14 03:22:50 localhost kernel: ide-cd: cmd 0x3 timed out
> >> >    Jun 14 03:22:50 localhost kernel: hda: lost interrupt
> >> >    Jun 14 03:23:30 localhost kernel: hda: lost interrupt
> >> 
> >> 
> Exactly the same problems here, on a laptop (Amd64, Mandriva 2006, 
> linux-2.6.15) with an:
> 
> ALi Corporation M5229 IDE (rev c7)
> 
> The cd-writer locks up if the DMA is enabled, as above. But the drive is 
> usable if it is disabled.
> 

I just wanted to add a "me too". I have a Shuttle ST20G5 with a M5229
rev c7:

00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if fa)
        Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f391
        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 185
        I/O ports at 8880 [size=16]

Reading CD's and DVD's always works, but writing or blanking hangs the
drive, with the following entries in the log files;

ide-cd: cmd 0x3 timed out
hda: lost interrupt
hda: request sense failure: status=0x51 { DriveReady SeekComplete Error }
hda: request sense failure: error=0x40 { LastFailedSense=0x04 }
hda: lost interrupt
hda: lost interrupt

The "lost interrupt" message is than repeated endlessly until i reboot,
and every program that tries to access the drive (including reading)
will hang for example:

31527 pts/0    D+     0:00 cat /proc/ide/hda/capacity

This is also on a AMD64, so i don't know maybe it is a AMD64 problem
only.

- Erwin