> > Aug 26 03:43:51 BRaiN kernel: VFS: Disk change detected on device 16:40
> > Aug 26 03:43:51 BRaiN kernel: cdrom: entering CDROMMULTISESSION
> > Aug 26 03:43:51 BRaiN kernel: cdrom: CDROMMULTISESSION sucessful
> > Aug 26 03:44:04 BRaiN kernel: hdd: timeout waiting for DMA
> > Aug 26 03:44:04 BRaiN kernel: hdd: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> > Aug 26 03:44:04 BRaiN kernel: hdd: DMA disabled
> > Aug 26 03:44:04 BRaiN kernel: hdd: ATAPI reset complete
> > Aug 26 03:44:04 BRaiN kernel: ATAPI device hdd:
> > Aug 26 03:44:04 BRaiN kernel: Error: Unit attention -- (Sense key=0x06)
> > Aug 26 03:44:04 BRaiN kernel: Power on, reset or bus device reset occurred --
> > (asc=0x29, ascq=0x00)
> > Aug 26 03:44:04 BRaiN kernel: ISO 9660 Extensions: RRIP_1991A
> > Aug 26 03:44:04 BRaiN kernel: VFS: Disk change detected on device 16:40
I checked with 2.1.115, and it does just the same. Name a version,
and I'll check it for you, or better gimme a debugging version of any modules
and I'll compile it in and give you the results.
> This is the _exact_ same problem (with death in the exact same place)
> that the other guy who is reporting a problem has seen.
>
> When the CDROMMULTISESSION call was sent down to the ide-cd driver by
> the uniform cdrom driver, ide-cd then builds an ATAPI READ_TOC packet,
> and sends it on to the ide layer, which stuffs the packet down to the
> drive. When ide talks to the drive, the drive chokes and then the ide
> layer does its best to get the drive back into a safe, sane state via a
> reset.
Well, this happened in the past (at 2.0.xx) but the reset went on,
and the drive worked. It is probably because it spins up very slow,
but once it's spinning it reacts fast again.
> The only thing I can think of is that recent changes to the ide layer
> have somehow hosed things for the ide driver. Could you try a few older
> kernels to see if you can narrow down when this started happening?
Better prepare some debugging output rich version and I'll run it
for you.
> What
> compiler are you using to compile the kernel? If 2.7.2.x, have you tried
> egcs? If egcs, have you tried gcc 2.7.2.x?
Well, I just realized that I was stupid enough to upgrade SOMEHOW to
gcc 2.8.1 and the kernel was compiled with it. But I put back 2.7.2.3
and it didn't change the problem. Does egcs compile the kernel at all...?
I could try... if you insist...
> I have copied Andre M. Hedrick, the current ide driver guy, to see if he
> has any ideas here.
>
> Andre: we've got another one! Ugh. Any ideas where this could be going
> wrong? I'm stumped on this one. ide-cd hasn't changed this stuff for a
> long while, so I'm pretty sure this one is in ide. Did DMA or interrupt
> handling change recently?
Not necessarily recently since I ain't a kernel beta tester :)
(Means since arp was f'cked up I did not touch 2.1.xx since it's
essential for me. I didn't check it yet but could be I still can't use
it... but thats another topic.)
This cd problem could happen anywhere after 2.1.96 or so.
As mentioned, if I get an ide-cd producing debugging output,
I'll gladly :) compile and run it. I can think of no better help,
and since kernel compile time is above 60 minutes I don't feel
to checking every kernel from 2.1.96 up to 2.1.114 :)
===========================+=============================================
Peter "grin" Gervai | "It was like a visit by Don Corleone. I
Linux root at Cory-Net Ltd.|expected to find a bloody computer monitor in
Szekszard, Hungary |my bed the next day." -- Mark Andreessen of
grin@iRCnet on #linux.hu |Netscape regarding the visit from microsoft.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html