Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Ralf Hoelzer]

Roland Mas wrote:
> I don't know what this magicdev thing is, but from what you say you
> turned off I assume it's something that accesses the CD drive and
> polls its status regularly.  So your problem looks remarkably like
> mine, which I have already reported here, except I do get a panic.  My
> problem occurs when the GNOME 2 CD applet is running, and it seems to
> me the culprit is an ioctl() that tries to get the status of the
> drive.  Look for my message with "Subject: Still [OOPS] ide-scsi
> panic, now in 2.4.21 too" (just reposted it, first time only went to
> specific people).

I have a very similar problem. I just installed 2.4.21 and as soon as I
mount my CD-RW (which uses ide-scsi emulation) the system dies.
I am NOT using magicdev. Everything works fine with 2.4.20.

I will try to capture some useful debugging output.

regards,
Ralf

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Dave Bentham]

On Tue, 24 Jun 2003 18:27:55 +0200
Ralf Hoelzer <ralf@well.com> wrote:

> Roland Mas wrote:
> > I don't know what this magicdev thing is, but from what you say you
> > turned off I assume it's something that accesses the CD drive and
> > polls its status regularly.  So your problem looks remarkably like
> > mine, which I have already reported here, except I do get a panic. 
> > My problem occurs when the GNOME 2 CD applet is running, and it
> > seems to me the culprit is an ioctl() that tries to get the status
> > of the drive.  Look for my message with "Subject: Still [OOPS]
> > ide-scsi panic, now in 2.4.21 too" (just reposted it, first time
> > only went to specific people).
> 
> I have a very similar problem. I just installed 2.4.21 and as soon as
> I mount my CD-RW (which uses ide-scsi emulation) the system dies.
> I am NOT using magicdev. Everything works fine with 2.4.20.
> 
> I will try to capture some useful debugging output.
> 
> regards,
> Ralf
> -

SNAP!

See my "2.4.21 panic on CDRW Mount" emails of a few days ago with my
panic output

Dave

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Douglas Gilbert]

Per Nystrom wrote:
 > Alright, I've really gotten it narrowed down now.
 >
 > The hard crash occurs only when magicdev is running.  I tried turning
 > off all my preferences for auto- mounting, running, and playing
 > data/audio cds in my preferences, and voila!  cdrecord works without a
 > hiccup in X too.

Per,
Interesting. My SCSI Yamaha 4416 burner also doesn't like magicdev
running during a burn by cdrecord. The effect is to lock up
burner (not the whole system). Since a device lockup leads
to an attempted device reset (and the latter is quite fragile
in the ide-scsi driver), my guess is that my Yamaha and your
Sony writer have the same firmware weakness.

Magicdev sends out a Test Unit Ready command every few seconds
and it seems some burners can't handle this while burning (or
in the final fixate stage). The simple solution is to turn off
magicdev (then your system will no longer detect CDROMs being
placed in the drive).

Doug Gilbert

PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Per Nystrom]

2.4.21 crashes hard running cdrecord in X.

I just compiled installed 2.4.21, and when I try to burn a cd in X,
everything locks up hard.  I've enabled kernel debugging and set up a
serial console to try to capture anything I can, but I don't even get a
panic or an oops message.  The following line is the last dying gasp
from syslogd:

Jun 15 16:21:54 spike kernel: scsi : aborting command due to timeout :
pid 569,
scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00

After that, everything is locked up hard.  Even the SysRq keys won't
work.  The command I was running that particular time was

cdrecord dev=0,0,0 blank=fast

This only seems to happen when I'm running in X.  I can use cdrecord to
burn cds all day when X is not running.  I haven't gotten any
finer-grained with it than that; I don't know if it's X itself, the
window manager, the desktop, nvidia's drivers, or any other bits that
are interacting badly with cdrecord.

My system is mostly Red Hat 8.  I updated the cdrecord rpm to the very
latest I could get when this started happening, cdrecord-2.0-10, but
that made no difference.  Here is the output from
/usr/src/linux/scripts/ver_linux:

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux spike.sunnydale 2.4.21 #6 Sun Jun 15 15:35:26 PDT 2003 i686 i686
i386 GNU/Linux

Gnu C                  3.2
Gnu make               3.79.1
util-linux             2.11r
mount                  2.11r
modutils               2.4.18
e2fsprogs              1.27
PPP                    2.4.1
isdn4k-utils           3.1pre4
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Procps                 2.0.7
Net-tools              1.60
Kbd                    1.06
Sh-utils               2.0.12
Modules Loaded         sr_mod awe_wave sb sb_lib uart401 sound nvidia
parport_pc lp parport nfsd lockd sunrpc autofs4 tulip iptable_filter
ip_tables ide-scsi scsi_mod vfat fat mousedev keybdev hid input usb-uhci
usbcore

By the way, cdrecord --scanbus works fine whether in text or X mode,
here's the output from it:

Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling
Linux sg driver version: 3.1.25
Using libscg version 'schily-0.7'
cdrecord: Warning: using inofficial libscg transport code version
(schily - Red
Hat-scsi-linux-sg.c-1.75-RH '@(#)scsi-linux-sg.c        1.75 02/10/21
Copyright
1997 J. Schilling').
scsibus0:
        0,0,0     0) 'SONY    ' 'CD-RW  CRX160E  ' '1.0e' Removable
CD-ROM
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *

More stuff about this box follows.  Any help would be greatly
appreciated!!!


lspci -vvv
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
(rev 02)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
        Latency: 64
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: <available only to root>

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 02)
(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 0000b000-0000bfff
        Memory behind bridge: e4000000-e5ffffff
        Prefetchable memory behind bridge: e6000000-e7ffffff
        BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B+

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
(prog-if 80
[Master])
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Region 4: I/O ports at f000 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
(prog-if 00 [UHCI])
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Interrupt: pin D routed to IRQ 14
        Region 4: I/O ports at c000 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin ? routed to IRQ 9

00:0e.0 RAID bus controller: CMD Technology Inc PCI0649 (rev 01)
        Subsystem: CMD Technology Inc PCI0649
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (500ns min, 1000ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at c400 [size=8]
        Region 1: I/O ports at c800 [size=4]
        Region 2: I/O ports at cc00 [size=8]
        Region 3: I/O ports at d000 [size=4]
        Region 4: I/O ports at d400 [size=16]
        Expansion ROM at e8000000 [disabled] [size=512K]
        Capabilities: <available only to root>

00:12.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet
10/100 model NC100 (rev 11)
        Subsystem: Linksys: Unknown device 0574
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (63750ns min, 63750ns max), cache line size 08
        Interrupt: pin A routed to IRQ 9
        Region 0: I/O ports at d800 [size=256]
        Region 1: Memory at ea000000 (32-bit, non-prefetchable)
[size=1K]
        Expansion ROM at e9000000 [disabled] [size=128K]
        Capabilities: <available only to root>

01:00.0 VGA compatible controller: nVidia Corporation NV5 [Riva TnT2
Ultra] (rev 11) (prog-if 00 [VGA])
        Subsystem: Creative Labs 3D Blaster RIVA TNT2 Ultra
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 248 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at e4000000 (32-bit, non-prefetchable)
[size=16M]
        Region 1: Memory at e6000000 (32-bit, prefetchable) [size=32M]
        Expansion ROM at e5000000 [disabled] [size=64K]
        Capabilities: <available only to root>

cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: SONY     Model: CD-RW  CRX160E   Rev: 1.0e
  Type:   CD-ROM                           ANSI SCSI revision: 02

cat /proc/scsi/sg/*
0
dev_max(currently)=7 max_active_device=1 (origin 1)
 scsi_dma_free_sectors=96 sg_pool_secs_aval=320 def_reserved_size=32768
32768
host    chan    id      lun     type    opens   qdepth  busy    online
0       0       0       0       5       0       5       0       1
SONY            CD-RW  CRX160E          1.0e
uid     busy    cpl     scatg   isa     emul
0       0       5       256     0       1
SCSI host adapter emulation for IDE ATAPI devices
30125   Version: 3.1.25 (20030529)

cat /proc/scsi/ide-scsi/*
SCSI host adapter emulation for IDE ATAPI devices

-- 
Per Nystrom <pnystrom@netmagic.net>

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Con Kolivas]

On Mon, 16 Jun 2003 10:22, Per Nystrom wrote:
> 2.4.21 crashes hard running cdrecord in X.
>
> I just compiled installed 2.4.21, and when I try to burn a cd in X,
> everything locks up hard.  I've enabled kernel debugging and set up a
> serial console to try to capture anything I can, but I don't even get a
> panic or an oops message.  The following line is the last dying gasp
> from syslogd:
>
> Jun 15 16:21:54 spike kernel: scsi : aborting command due to timeout :
> pid 569,
> scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00
>
> After that, everything is locked up hard.  Even the SysRq keys won't
> work.  The command I was running that particular time was
>
> cdrecord dev=0,0,0 blank=fast
>
> This only seems to happen when I'm running in X.  I can use cdrecord to
> burn cds all day when X is not running.  I haven't gotten any
> finer-grained with it than that; I don't know if it's X itself, the
> window manager, the desktop, nvidia's drivers, or any other bits that

Could you please try without the nvidia drivers. You will get no support here 
with them running. There is no way of knowing what happens when these are 
running. They have our source code, we don't have theirs.

Con

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Per Nystrom]

Ok, I've removed the nvidia driver and changed "Device" in XF86Config
back to Driver "nv".  Here's lsmod:

Module                  Size  Used by    Not tainted
sr_mod                 15960   0 (autoclean)
awe_wave              171296   0 (autoclean) (unused)
sb                      9332   0 (autoclean)
sb_lib                 44526   0 (autoclean) [sb]
uart401                 8484   0 (autoclean) [sb_lib]
sound                  73428   0 (autoclean) [awe_wave sb_lib uart401]
parport_pc             18980   1 (autoclean)
lp                      8352   1 (autoclean)
parport                36864   1 (autoclean) [parport_pc lp]
nfsd                   80112   8 (autoclean)
lockd                  58192   1 (autoclean) [nfsd]
sunrpc                 81884   1 (autoclean) [nfsd lockd]
autofs4                12244   1 (autoclean)
tulip                  45664   1
iptable_filter          2412   0 (autoclean) (unused)
ip_tables              14680   1 [iptable_filter]
ide-scsi               12176   0
scsi_mod               99476   2 [sr_mod ide-scsi]
vfat                   12780   1 (autoclean)
fat                    39160   0 (autoclean) [vfat]
mousedev                5524   0 (unused)
keybdev                 2944   0 (unused)
hid                    22116   1
input                   5760   0 [mousedev keybdev hid]
usb-uhci               26220   0 (unused)
usbcore                77440   1 [hid usb-uhci]


The behavior is exactly the same without nvidia's driver, but I won't go
back to running it until this thing is figured out.

Next thing I'm going to try is starting *just* X with nothing else, and
running cdrecord in a text console.  If that works, I'll try it with
just metacity running, and I'll keep stacking things up until it fails.

Thanks in advance,
Per


On Sun, 2003-06-15 at 17:55, Con Kolivas wrote:
> On Mon, 16 Jun 2003 10:22, Per Nystrom wrote:
> > 2.4.21 crashes hard running cdrecord in X.
> >
> > I just compiled installed 2.4.21, and when I try to burn a cd in X,
> > everything locks up hard.  I've enabled kernel debugging and set up a
> > serial console to try to capture anything I can, but I don't even get a
> > panic or an oops message.  The following line is the last dying gasp
> > from syslogd:
> >
> > Jun 15 16:21:54 spike kernel: scsi : aborting command due to timeout :
> > pid 569,
> > scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00
> >
> > After that, everything is locked up hard.  Even the SysRq keys won't
> > work.  The command I was running that particular time was
> >
> > cdrecord dev=0,0,0 blank=fast
> >
> > This only seems to happen when I'm running in X.  I can use cdrecord to
> > burn cds all day when X is not running.  I haven't gotten any
> > finer-grained with it than that; I don't know if it's X itself, the
> > window manager, the desktop, nvidia's drivers, or any other bits that
> 
> Could you please try without the nvidia drivers. You will get no support here 
> with them running. There is no way of knowing what happens when these are 
> running. They have our source code, we don't have theirs.
> 
> Con
> 
> -
> 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/
-- 
Per Nystrom <pnystrom@netmagic.net>

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Per Nystrom]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Alright, I've really gotten it narrowed down now.

The hard crash occurs only when magicdev is running.  I tried turning
off all my preferences for auto- mounting, running, and playing
data/audio cds in my preferences, and voila!  cdrecord works without a
hiccup in X too.

I will not revert to my nvidia driver for a few days anyway, in case I
can help debug this further -- just let me know what to do.  This looks
like a pretty serious problem, since the upshot is that userspace
programs are able to bring the kernel down.  I'd be happy to help if I
can.

Per


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Roland Mas]

Per Nystrom, 2003-06-15 19:46:31 -0700 :

> The hard crash occurs only when magicdev is running.  I tried
> turning off all my preferences for auto- mounting, running, and
> playing data/audio cds in my preferences, and voila!  cdrecord works
> without a hiccup in X too.

I don't know what this magicdev thing is, but from what you say you
turned off I assume it's something that accesses the CD drive and
polls its status regularly.  So your problem looks remarkably like
mine, which I have already reported here, except I do get a panic.  My
problem occurs when the GNOME 2 CD applet is running, and it seems to
me the culprit is an ioctl() that tries to get the status of the
drive.  Look for my message with "Subject: Still [OOPS] ide-scsi
panic, now in 2.4.21 too" (just reposted it, first time only went to
specific people).

  Glad to know I'm not alone :-)

Roland.
-- 
Roland Mas

OpenPGP keys on http://www.keyserver.net/

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Jan Knutar]

> The hard crash occurs only when magicdev is running.  I tried turning
> off all my preferences for auto- mounting, running, and playing
> data/audio cds in my preferences, and voila!  cdrecord works without
> a hiccup in X too.

Exactly the same experiences here, with 2 different motherboards and 2 
different CD-RW drives, with various stock kernels since 2.4.9 or so. 
Exactly the same resolution too, kill magicdev, and everything works 
fine.

My machine would sometimes survive slightly longer, usually locking up 
during fixating a disc. It would typically spit out massive amounts of 
SCSI and IDE errors, while effectively locking up the machine for, what 
at first was about 10 seconds at a time with a split second in an 
unlocked state, but that would eventually worsen into a permanently 
hard-locked state. 

Curiously enough, doing hdparm -y /dev/hdb (the cd burner), during one 
of those split second unlocked states, would usually save the system. 
It became standard practice for me to have an xterm su'd, in focus and 
ready with "hdparm -y /dev/hdb" in it, while wiggling the mouse to see 
when the pointer would freeze, to hit enter when/if it unfroze again 8-)

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Per Nystrom]

On Mon, 2003-06-16 at 05:56, Jan Knutar wrote:

> 
> Exactly the same experiences here, with 2 different motherboards and 2 
> different CD-RW drives, with various stock kernels since 2.4.9 or so. 
> Exactly the same resolution too, kill magicdev, and everything works 
> fine.
> 
> My machine would sometimes survive slightly longer, usually locking up 
> during fixating a disc. It would typically spit out massive amounts of 
> SCSI and IDE errors, while effectively locking up the machine for, what 
> at first was about 10 seconds at a time with a split second in an 
> unlocked state, but that would eventually worsen into a permanently 
> hard-locked state. 
> 
> Curiously enough, doing hdparm -y /dev/hdb (the cd burner), during one 
> of those split second unlocked states, would usually save the system. 
> It became standard practice for me to have an xterm su'd, in focus and 
> ready with "hdparm -y /dev/hdb" in it, while wiggling the mouse to see 
> when the pointer would freeze, to hit enter when/if it unfroze again 8-)

So counting myself, it sounds like there are at least 3 of us
experiencing a similar problem.  I didn't mention it in my original
post, but it's probably worth noting that I only started seeing this in
2.4.21.  I was running on 2.4.20 with the same setup for a long time,
and happily burning cds with magicdev running at the same time without
any trouble.


-- 
Per Nystrom <pnystrom@netmagic.net>

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Per Nystrom]

I should probably just start a new thread with a more correct
description of the problem, but for the sake of thread continuity I
won't just yet.

First, a recap:

What's actually happening is that 2.4.21 crashes hard when magicdev
(part of Red Hat's gnome) is polling the cdrom drive to auto mount/play
a disk when it's inserted, and I try to burn a disk with cdrecord at the
same time.  The problem did not show up until 2.4.21; I was burning cds 
just fine on 2.4.20 with magicdev polling at the same time.  The crash
happens 100% of the time with this combination, and my temporary
solution is to turn off magicdev before burning a cd.

My system is mostly Red Hat 8.  The details can be found in the parent
of this thread, and I'm happy to provide more info -- just ask.

Now, the latest:

I was finally able to get an oops report (I had to copy it by hand from
virtual term tty0; try as I might, it would not show up on the serial
console -- though everything else up to that point did).  I ran it
through ksymoops, and the output is below.  I'm not sure what the
warning is all about; this is exactly the same kernel and .map file that
generated the oops.

This looks a lot like Roland Mas' problem, please see his post titled
"[Roland Mas] Still [OOPS] ide-scsi panic, now in 2.4.21 too" sent
16-June.

Thanks,
Per

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

ksymoops 2.4.9 on i686 2.4.21.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.21/ (default)
     -m /boot/System.map-2.4.21 (specified)

Warning (compare_maps): ksyms_base symbol
__io_virt_debug_R__ver___io_virt_debug not found in System.map. 
Ignoring ksyms_base entry
kernel BUG at ide-iops.c:1262!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01ee226>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010082
eax: d096f640   ebx: 00000000   ecx: 00000032   edx: c135e37c
esi: ca3f2800   edi: c031bd84   ebp: c02dfeb4   esp: c02dfe8c
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c02df000)
Stack: 00000086 c02fb68e 00000082 ca3f2800 c031bcd4 c135e37c 00000092
00000000
       ca3f2800 00000000 c02dfec4 c01ee439 c031bd84 00000000 c02dfed0
d097089b
       c031bd84 c02dfef4 d095beaf ca3f2800 00000002 00000000 cf8c53f4
ca3f2800
Call Trace:    [<c01ee439>] [<d097089b>] [<d095beaf>] [<d095b2f5>]
[<d095b280>]
  [<c011f5cb>] [<c011ecc6>] [<c011baf2>] [<c011b9e6>] [<c011b816>]
[<c010a9ad>]
  [<c0107220>] [<c010d058>] [<c0107220>] [<c0107246>] [<c01072e2>]
[<c0105000>]
Code: 0f 0b ee 04 3f 64 28 c0 80 bf f9 00 00 00 20 74 0b 8b 45 0c


>>EIP; c01ee226 <do_reset1+26/220>   <=====

>>eax; d096f640 <[ide-scsi]idescsi_pc_intr+0/370>
>>edx; c135e37c <_end+103d844/104f5528>
>>esi; ca3f2800 <_end+a0d1cc8/104f5528>
>>edi; c031bd84 <ide_hwifs+504/2b48>
>>ebp; c02dfeb4 <init_task_union+1eb4/2000>
>>esp; c02dfe8c <init_task_union+1e8c/2000>

Trace; c01ee439 <ide_do_reset+19/20>
Trace; d097089b <[ide-scsi]idescsi_reset+1b/30>
Trace; d095beaf <[scsi_mod]scsi_reset+ff/370>
Trace; d095b2f5 <[scsi_mod]scsi_old_times_out+75/140>
Trace; d095b280 <[scsi_mod]scsi_old_times_out+0/140>
Trace; c011f5cb <run_timer_list+10b/170>
Trace; c011ecc6 <update_wall_time+16/40>
Trace; c011baf2 <bh_action+22/50>
Trace; c011b9e6 <tasklet_hi_action+46/70>
Trace; c011b816 <do_softirq+a6/b0>
Trace; c010a9ad <do_IRQ+bd/f0>
Trace; c0107220 <default_idle+0/40>
Trace; c010d058 <call_do_IRQ+5/d>
Trace; c0107220 <default_idle+0/40>
Trace; c0107246 <default_idle+26/40>
Trace; c01072e2 <cpu_idle+52/70>
Trace; c0105000 <_stext+0/0>

Code;  c01ee226 <do_reset1+26/220>
00000000 <_EIP>:
Code;  c01ee226 <do_reset1+26/220>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c01ee228 <do_reset1+28/220>
   2:   ee                        out    %al,(%dx)
Code;  c01ee229 <do_reset1+29/220>
   3:   04 3f                     add    $0x3f,%al
Code;  c01ee22b <do_reset1+2b/220>
   5:   64                        fs
Code;  c01ee22c <do_reset1+2c/220>
   6:   28 c0                     sub    %al,%al
Code;  c01ee22e <do_reset1+2e/220>
   8:   80 bf f9 00 00 00 20      cmpb   $0x20,0xf9(%edi)
Code;  c01ee235 <do_reset1+35/220>
   f:   74 0b                     je     1c <_EIP+0x1c>
Code;  c01ee237 <do_reset1+37/220>
  11:   8b 45 0c                  mov    0xc(%ebp),%eax

 <0>Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.

-- 
Per Nystrom <pnystrom@netmagic.net>

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Scott McDermott]

Per Nystrom on Tue 17/06 23:44 -0700:
> This looks a lot like Roland Mas' problem, please see his post titled
> "[Roland Mas] Still [OOPS] ide-scsi panic, now in 2.4.21 too" sent
> 16-June.

take a look also at my post
http://marc.theaimsgroup.com/?l=linux-kernel&m=105427695226660&w=2

I am pretty sure magicdev was running here as well.  I will have this
machine later tonight and report back if stopping magicdev fixes it.

Re: PROBLEM: 2.4.21 crashes hard running cdrecord in X.

[Alan Cox]

On Llu, 2003-06-16 at 01:55, Con Kolivas wrote:
> Could you please try without the nvidia drivers. You will get no support here 
> with them running. There is no way of knowing what happens when these are 
> running. They have our source code, we don't have theirs.

The IDE reset bug is one I know about. Its not the NV module for this
one, its mishandling of context for ide scsi timeouts.