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 <[email protected]>
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Per Nystrom <[email protected]>
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
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
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/
> 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-)
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 <[email protected]>
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 <[email protected]>
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.
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.
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
On Tue, 24 Jun 2003 18:27:55 +0200
Ralf Hoelzer <[email protected]> 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