Skip to contentSkip to conversation

ide-cd: fix kernel crash on hppa regression

PATCH In review Helge Deller 3 participants 15 messages Apr 15, 2009 – Apr 26, 2009

lore
Share & tools
lore

Helge Deller

author
#0 lore raw

PATCH 1/1 ide-cd: fix kernel crash on hppa regression

With 2.6.30-rc2 I face a kernel crash on the 32bit hppa architecture due to ide-cd when udev creates the device nodes at startup:

Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
IIR: 4ab30048 ISR: 00000000 IOR: 00000024
CPU: 0 CR30: 8ed34000 CR31: ffff55ff
ORIG_R28: 00000000
IAOQ[0]: ide_complete_rq+0x2c/0x70 IAOQ[1]: ide_complete_rq+0x30/0x70
RP(r2): cdrom_newpc_intr+0x178/0x46c

Backtrace:
 [<1035c608>] cdrom_newpc_intr+0x178/0x46c
 [<1034c494>] ide_intr+0x1b0/0x214
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<102f7864>] superio_interrupt+0x88/0xbc
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
 [<10116068>] intr_return+0x0/0x4

This crash seems to happen due to an uninitialized variable "rc".
The compiler even warns about that:
CC drivers/ide/ide-cd.o
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c: In function `cdrom_newpc_intr':
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c:612: warning: `rc' might be used uninitialized in this function

After applying the trivial patch below, which just initializes the variable to zero, the kernel doesn't crash any longer:

Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
done.

Signed-off-by Helge Deller <[email protected]>
drivers/ide/ide-cd.c +1 -1
index 3aec19d..3d4e099 100644
@@ -609,7 +609,7 @@ static ide_startstop_t cdrom_newpc_intr(ide_drive_t *drive)
 	struct request *rq = hwif->rq;
 	ide_expiry_t *expiry = NULL;
 	int dma_error = 0, dma, thislen, uptodate = 0;
-	int write = (rq_data_dir(rq) == WRITE) ? 1 : 0, rc, nsectors;
+	int write = (rq_data_dir(rq) == WRITE) ? 1 : 0, rc = 0, nsectors;
 	int sense = blk_sense_request(rq);
 	unsigned int timeout;
 	u16 len;
#1 lore raw

Hi,

Quoted 22 lines · Helge Deller

With 2.6.30-rc2 I face a kernel crash on the 32bit hppa architecture due to ide-cd when udev creates the device nodes at startup:

Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
IIR: 4ab30048 ISR: 00000000 IOR: 00000024
CPU: 0 CR30: 8ed34000 CR31: ffff55ff
ORIG_R28: 00000000
IAOQ[0]: ide_complete_rq+0x2c/0x70 IAOQ[1]: ide_complete_rq+0x30/0x70
RP(r2): cdrom_newpc_intr+0x178/0x46c

Backtrace:
 [<1035c608>] cdrom_newpc_intr+0x178/0x46c
 [<1034c494>] ide_intr+0x1b0/0x214
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<102f7864>] superio_interrupt+0x88/0xbc
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
 [<10116068>] intr_return+0x0/0x4
Quoted 5 lines

This crash seems to happen due to an uninitialized variable "rc".
The compiler even warns about that:
CC drivers/ide/ide-cd.o
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c: In function `cdrom_newpc_intr':
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c:612: warning: `rc' might be used uninitialized in this function

can you do

gdb ./vmlinux

and then

(gdb) l *(cdrom_newpc_intr+0x178)

I think I have a suspect but I want to be sure. In order to do that you'll need a debug kernel (set CONFIG_DEBUG_INFO to 'y' in your .config). In case the oops above is not from a debug kernel, can you catch it again and _then_ do the gdb thing since the offset of 0x178 is most probably going to change. In that case, you have to do

(gdb) l *(cdrom_newpc_intr+NEW_OFFSET_FROM_THE_OOPS)

Thanks.

Signature · 2 lines
Regards/Gruss,
    Boris.
author
#2 lore raw

Hi Borislav,

Quoted 39 lines · Borislav Petkov

Hi,

Quoted 22 lines · Helge Deller

With 2.6.30-rc2 I face a kernel crash on the 32bit hppa architecture due to ide-cd when udev creates the device nodes at startup:

Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
IIR: 4ab30048 ISR: 00000000 IOR: 00000024
CPU: 0 CR30: 8ed34000 CR31: ffff55ff
ORIG_R28: 00000000
IAOQ[0]: ide_complete_rq+0x2c/0x70 IAOQ[1]: ide_complete_rq+0x30/0x70
RP(r2): cdrom_newpc_intr+0x178/0x46c

Backtrace:
 [<1035c608>] cdrom_newpc_intr+0x178/0x46c
 [<1034c494>] ide_intr+0x1b0/0x214
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<102f7864>] superio_interrupt+0x88/0xbc
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
 [<10116068>] intr_return+0x0/0x4
Quoted 5 lines

This crash seems to happen due to an uninitialized variable "rc".
The compiler even warns about that:
CC drivers/ide/ide-cd.o
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c: In function `cdrom_newpc_intr':
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c:612: warning: `rc' might be used uninitialized in this function

can you do

gdb ./vmlinux

and then

(gdb) l *(cdrom_newpc_intr+0x178)

Quoted 7 lines

I think I have a suspect but I want to be sure. In order to do that you'll need a debug kernel (set CONFIG_DEBUG_INFO to 'y' in your .config). In case the oops above is not from a debug kernel, can you catch it again and _then_ do the gdb thing since the offset of 0x178 is most probably going to change. In that case, you have to do

(gdb) l *(cdrom_newpc_intr+NEW_OFFSET_FROM_THE_OOPS)

I tried to build a kernel with CONFIG_DEBUG_INFO.
There are two problem with that, because I'm cross-compiling:
a) I don't have a cross-gdb (but I could use addr2line instead though)
b) the resulting kernel is becoming too big and won't link/boot:
...
SYSMAP System.map
SYSMAP .tmp_System.map
/sbin/palo -f /mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6-32bit/palo.conf palo version 1.14 deller@p100 Fri Jul 28 22:55:11 CEST 2006
ELF32 executable
ipl: addr 2048 size 36864 entry 0x0
ko 0x0 ksz 0 k64o 0x0 k64sz 0 rdo 0 rdsz 0
<>
Your 32-bit-kernel is too big for your F0 partition
make[3]: *** [palo] Error 2

I could now just try to look into the assembly by hand and try to find which line produces the problem. But reading hppa assembly code for such a big function is not very easy though.

So, my question would be:
If you have an idea where the problem is, maybe you have a patch for me to try?
That would simplify the whole thing for me a lot, as just compiling/run-testing is much easier for me.

Best regards,
Helge

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

#3 lore raw

Hi,

On Thu, Apr 16, 2009 at 10:26:06PM +0200, Helge Deller wrote:

[..]

Quoted 16 lines

I tried to build a kernel with CONFIG_DEBUG_INFO.
There are two problem with that, because I'm cross-compiling:
a) I don't have a cross-gdb (but I could use addr2line instead though)
b) the resulting kernel is becoming too big and won't link/boot:
...
SYSMAP System.map
SYSMAP .tmp_System.map
/sbin/palo -f /mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6-32bit/palo.conf palo version 1.14 deller@p100 Fri Jul 28 22:55:11 CEST 2006
ELF32 executable
ipl: addr 2048 size 36864 entry 0x0
ko 0x0 ksz 0 k64o 0x0 k64sz 0 rdo 0 rdsz 0
<>
Your 32-bit-kernel is too big for your F0 partition
make[3]: *** [palo] Error 2

Quoted 3 lines

I could now just try to look into the assembly by hand and try to find which line produces the problem. But reading hppa assembly code for such a big function is not very easy though.

Thanks a lot for trying, I appreciate it. However, I think I have an easier idea I could try here first and maybe we won't need the hppa assembly exercise :).

Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

Signature · 2 lines
Regards/Gruss,
    Boris.
author
#4 lore raw
Quoted 22 lines · Borislav Petkov

Hi,

On Thu, Apr 16, 2009 at 10:26:06PM +0200, Helge Deller wrote:

[..]

Quoted 16 lines

I tried to build a kernel with CONFIG_DEBUG_INFO.
There are two problem with that, because I'm cross-compiling:
a) I don't have a cross-gdb (but I could use addr2line instead though)
b) the resulting kernel is becoming too big and won't link/boot:ina
...
SYSMAP System.map
SYSMAP .tmp_System.map
/sbin/palo -f /mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6-32bit/palo.conf palo version 1.14 deller@p100 Fri Jul 28 22:55:11 CEST 2006
ELF32 executable
ipl: addr 2048 size 36864 entry 0x0
ko 0x0 ksz 0 k64o 0x0 k64sz 0 rdo 0 rdsz 0
<>
Your 32-bit-kernel is too big for your F0 partition
make[3]: *** [palo] Error 2

Quoted 6 lines
Quoted 3 lines

I could now just try to look into the assembly by hand and try to find which line produces the problem. But reading hppa assembly code for such a big function is not very easy though.

Thanks a lot for trying, I appreciate it. However, I think I have an easier idea I could try here first and maybe we won't need the hppa assembly exercise :).

Great, thanks!
If you want me to test something, just let me know.

Quoted 3 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Helge

#5 lore raw

On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote:
[..]

Quoted 4 lines
Quoted 3 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

Quoted 8 lines

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Is it possible to isolate it and test without the superio driver?

Signature · 2 lines
Regards/Gruss,
    Boris.
author
#6 lore raw
Quoted 13 lines · Borislav Petkov

On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote:
[..]

Quoted 10 lines
Quoted 2 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Quoted 1 line

Is it possible to isolate it and test without the superio driver?

No, since the superio controller provides the IDE ports.

Best regards,
Helge

#7 lore raw
Quoted 14 lines · On Wednesday 22 April 2009 23:13:12 Helge Deller wrote:
Quoted 13 lines · Borislav Petkov

On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote:
[..]

Quoted 10 lines
Quoted 2 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Quoted 3 lines
Quoted 1 line

Is it possible to isolate it and test without the superio driver?

No, since the superio controller provides the IDE ports.

Is 2.6.29 working ok? What about 2.6.30-rc1 + your fix?

author
#8 lore raw
Quoted 14 lines · Bartlomiej Zolnierkiewicz
Quoted 13 lines · On Wednesday 22 April 2009 23:13:12 Helge Deller wrote:
Quoted 12 lines · Borislav Petkov

On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote:
[..]

Quoted 10 lines
Quoted 2 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Quoted 4 lines
Quoted 2 lines
Quoted 1 line

Is it possible to isolate it and test without the superio driver?

No, since the superio controller provides the IDE ports.

Is 2.6.29 working ok? What about 2.6.30-rc1 + your fix?

* 2.6.29 works perfectly.
* 2.6.30-rc3 (includes my patch) does work as well, but I see quite often those messages:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
* drivers/parisc/superio.c had no (important) changes between 2.6.29 and 2.6.30-rcX
* to me it seems your changes to drivers/ide/ns87415.c have raised those problems.
* maybe you added some inb() in the new paths, which should call superio_ide_inb() (see to of ns87415.c) instead?
* it seems the problem happens more often in some fault-paths, for example when reading a faulty disc in the cdrom drive

Best regards,
Helge

#9 lore raw
Quoted 18 lines · On Saturday 25 April 2009 13:19:08 Helge Deller wrote:
Quoted 17 lines · Bartlomiej Zolnierkiewicz
Quoted 15 lines · On Wednesday 22 April 2009 23:13:12 Helge Deller wrote:
Quoted 12 lines · Borislav Petkov

On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote:
[..]

Quoted 10 lines
Quoted 2 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Quoted 1 line

Is it possible to isolate it and test without the superio driver?

No, since the superio controller provides the IDE ports.

Quoted 7 lines
Quoted 1 line

Is 2.6.29 working ok? What about 2.6.30-rc1 + your fix?

* 2.6.29 works perfectly.
* 2.6.30-rc3 (includes my patch) does work as well, but I see quite often those messages:

   hda: command error: status=0x51 { DriveReady SeekComplete Error }
   hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
   ide: failed opcode was: unknown

That is kind of expected given your report about -rc2. Verifying -rc1 + fix would be useful in starting to narrow down the scope of changes to look at.

Quoted 4 lines

* drivers/parisc/superio.c had no (important) changes between 2.6.29 and 2.6.30-rcX
* to me it seems your changes to drivers/ide/ns87415.c have raised those problems.
* maybe you added some inb() in the new paths, which should call superio_ide_inb() (see to of ns87415.c) instead?

I checked this now and unfortunately it doesn't seem like it.

Quoted 2 lines

* it seems the problem happens more often in some fault-paths, for example when reading a faulty disc in the cdrom drive

I think that we should start with finding out whether this is ns87415 specific regression or a more general ide-cd one.

commit a6d67ffa7dfe9515d8f2051a76b14c82b748475a ("ns87415: use custom ->dma_{start,end} to handle ns87415_prepare_drive()") looks like a good candidate to make the distinction between potentially bad ns87415 changes and potentially bad ide-cd ones.

Thus please give commit 5ae5412d9a23b05ab08461b202bad21ad8f6b66d ("ide:
add ide_dma_prepare() helper") with your ide-cd fix applied a try.

[ You may also go ahead and do full git bisection between 2.6.29 and
2.6.30-rc2 applying/removing your ide-cd fix for each iteration. ]

Thanks,
Bart

author
#10 lore raw

Hi Bart,

Quoted 38 lines · Bartlomiej Zolnierkiewicz
Quoted 15 lines · On Saturday 25 April 2009 13:19:08 Helge Deller wrote:
Quoted 14 lines · Bartlomiej Zolnierkiewicz
Quoted 13 lines · On Wednesday 22 April 2009 23:13:12 Helge Deller wrote:
Quoted 12 lines · Borislav Petkov

On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote:
[..]

Quoted 10 lines
Quoted 2 lines
Quoted 1 line

BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel...

What do you mean by that, please elaborate?

I meant:
a) Without my patch the kernel did crash (see backtrace in original mail)
b) with my patch the kernel booted to login prompt, but I got those messages on the console:
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
Nevertheless, mounting a cdrom in the drive didn't suceeded with same/similiar messages, but this could even be because of the parisc superio driver...

Quoted 8 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line

Is it possible to isolate it and test without the superio driver?

No, since the superio controller provides the IDE ports.

Is 2.6.29 working ok? What about 2.6.30-rc1 + your fix?

* 2.6.29 works perfectly.
* 2.6.30-rc3 (includes my patch) does work as well, but I see quite often those messages:

   hda: command error: status=0x51 { DriveReady SeekComplete Error }
   hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
   ide: failed opcode was: unknown

That is kind of expected given your report about -rc2. Verifying -rc1 + fix would be useful in starting to narrow down the scope of changes to look at.

Quoted 4 lines

* drivers/parisc/superio.c had no (important) changes between 2.6.29 and 2.6.30-rcX
* to me it seems your changes to drivers/ide/ns87415.c have raised those problems.
* maybe you added some inb() in the new paths, which should call superio_ide_inb() (see to of ns87415.c) instead?

I checked this now and unfortunately it doesn't seem like it.

Quoted 2 lines

* it seems the problem happens more often in some fault-paths, for example when reading a faulty disc in the cdrom drive

Quoted 7 lines

I think that we should start with finding out whether this is ns87415 specific regression or a more general ide-cd one.

commit a6d67ffa7dfe9515d8f2051a76b14c82b748475a ("ns87415: use custom ->dma_{start,end} to handle ns87415_prepare_drive()") looks like a good candidate to make the distinction between potentially bad ns87415 changes and potentially bad ide-cd ones.

Reverting this commit still showed the errors mentioned above.

Quoted 2 lines

Thus please give commit 5ae5412d9a23b05ab08461b202bad21ad8f6b66d ("ide:
add ide_dma_prepare() helper") with your ide-cd fix applied a try.

That is a hard one. Just reverting it (with or without the other one above) prevents me to build a kernel due to compiler errors.

Instead I tried 2.6.30-rc1 and 2.6.30-rc2 (all with my simple patch).
2.6.30-rc1 worked without problems.
2.6.30-rc2 did showed the errors.
(I should mention, that the cdrom does work even if those messages are printed).
The diff of drivers/ide/ns87415.c between those two versions seems unproblematic. Then, after inserting "outb(ATA_DEVCTL_OBS, io_ports->ctl_addr);" to 2.6.30-rc2 didn't fixed it either.

So, I think there is some generic problems in the generic ide cdrom stack, which was introduced between 2.6.30-rc1 and -rc2.

Hope this helps you further.

Helge

#11 lore raw

Hi,

On Sun, Apr 26, 2009 at 12:51:46AM +0200, Helge Deller wrote:
..

Quoted 13 lines
Quoted 2 lines

Thus please give commit 5ae5412d9a23b05ab08461b202bad21ad8f6b66d ("ide:
add ide_dma_prepare() helper") with your ide-cd fix applied a try.

That is a hard one. Just reverting it (with or without the other one above) prevents me to build a kernel due to compiler errors.

Instead I tried 2.6.30-rc1 and 2.6.30-rc2 (all with my simple patch).
2.6.30-rc1 worked without problems.
2.6.30-rc2 did showed the errors.
(I should mention, that the cdrom does work even if those messages are printed).
The diff of drivers/ide/ns87415.c between those two versions seems unproblematic. Then, after inserting "outb(ATA_DEVCTL_OBS, io_ports->ctl_addr);" to 2.6.30-rc2 didn't fixed it either.

Quoted 4 lines

So, I think there is some generic problems in the generic ide cdrom stack, which was introduced between 2.6.30-rc1 and -rc2.

Hope this helps you further.

Not really, since I'm assuming that it is this particular hardware confguration you have that triggers this. It would still be very helpful if you'd bisected it since you've narrowed it down to the [30-rc1 30-rc2] interval and that isn't going to be a large number of kernel compiles :).

Thanks.

Signature · 2 lines
Regards/Gruss,
    Boris.
#12 lore raw
Quoted 10 lines · On Sunday 26 April 2009 08:33:32 Borislav Petkov wrote:

Hi,

On Sun, Apr 26, 2009 at 12:51:46AM +0200, Helge Deller wrote:
..

Quoted 5 lines
Quoted 2 lines

Thus please give commit 5ae5412d9a23b05ab08461b202bad21ad8f6b66d ("ide:
add ide_dma_prepare() helper") with your ide-cd fix applied a try.

That is a hard one. Just reverting it (with or without the other one above) prevents me to build a kernel due to compiler errors.

Sorry for not explaining this properly -- I meant doing git checkout at this commit not reverting it (anyway it isn't needed now as we know that this change is good since it was done before -rc1).

Quoted 10 lines
Quoted 10 lines

Instead I tried 2.6.30-rc1 and 2.6.30-rc2 (all with my simple patch).
2.6.30-rc1 worked without problems.
2.6.30-rc2 did showed the errors.
(I should mention, that the cdrom does work even if those messages are printed).
The diff of drivers/ide/ns87415.c between those two versions seems unproblematic. Then, after inserting "outb(ATA_DEVCTL_OBS, io_ports->ctl_addr);" to 2.6.30-rc2 didn't fixed it either.

So, I think there is some generic problems in the generic ide cdrom stack, which was introduced between 2.6.30-rc1 and -rc2.

Quoted 7 lines
Quoted 1 line

Hope this helps you further.

Not really, since I'm assuming that it is this particular hardware confguration you have that triggers this. It would still be very helpful if you'd bisected it since you've narrowed it down to the [30-rc1 30-rc2] interval and that isn't going to be a large number of kernel compiles :).

Yes, there is only 26 drivers/ide commits in-between, just do:

	git bisect start v2.6.30-rc1 v2.6.30-rc2 drivers/ide

build it, test it, mark it with:

git bisect bad

or

git bisect good

and then repeat build-test-mark cycle until the guilty commit is found.

Thanks,
Bart

Acked-by on v1 1/1
#13 lore raw
In reply to Helge Deller

Hi,

Quoted 31 lines · Helge Deller

With 2.6.30-rc2 I face a kernel crash on the 32bit hppa architecture due to ide-cd when udev creates the device nodes at startup:

Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
IIR: 4ab30048 ISR: 00000000 IOR: 00000024
CPU: 0 CR30: 8ed34000 CR31: ffff55ff
ORIG_R28: 00000000
IAOQ[0]: ide_complete_rq+0x2c/0x70 IAOQ[1]: ide_complete_rq+0x30/0x70
RP(r2): cdrom_newpc_intr+0x178/0x46c

Backtrace:
 [<1035c608>] cdrom_newpc_intr+0x178/0x46c
 [<1034c494>] ide_intr+0x1b0/0x214
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<102f7864>] superio_interrupt+0x88/0xbc
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
 [<10116068>] intr_return+0x0/0x4

This crash seems to happen due to an uninitialized variable "rc".
The compiler even warns about that:
CC drivers/ide/ide-cd.o
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c: In function `cdrom_newpc_intr':
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c:612: warning: `rc' might be used uninitialized in this function

After applying the trivial patch below, which just initializes the variable to zero, the kernel doesn't crash any longer:

Quoted 8 lines

Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
done.

Signed-off-by Helge Deller <[email protected]>
Acked-by Borislav Petkov <[email protected]>

The original fix was correct. Helge, sorry for the delay but I wanted to make sure that this wasn't caused by recent rewrite in another area of ide-cd, thanks.

Bart, please apply.

Signature · 2 lines
Regards/Gruss,
    Boris.
#14 lore raw
Quoted 41 lines · On Wednesday 22 April 2009 08:10:46 Borislav Petkov wrote:

Hi,

Quoted 38 lines · Helge Deller

With 2.6.30-rc2 I face a kernel crash on the 32bit hppa architecture due to ide-cd when udev creates the device nodes at startup:

Kernel Fault: Code=26 regs=8ed34c40 (Addr=00000024)
IASQ: 00000000 00000000 IAOQ: 1034b5ac 1034b5b0
IIR: 4ab30048 ISR: 00000000 IOR: 00000024
CPU: 0 CR30: 8ed34000 CR31: ffff55ff
ORIG_R28: 00000000
IAOQ[0]: ide_complete_rq+0x2c/0x70 IAOQ[1]: ide_complete_rq+0x30/0x70
RP(r2): cdrom_newpc_intr+0x178/0x46c

Backtrace:
 [<1035c608>] cdrom_newpc_intr+0x178/0x46c
 [<1034c494>] ide_intr+0x1b0/0x214
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<102f7864>] superio_interrupt+0x88/0xbc
 [<1016d284>] handle_IRQ_event+0x70/0x150
 [<1016d4b0>] __do_IRQ+0x14c/0x1cc
 [<10112efc>] do_cpu_irq_mask+0x9c/0xd0
 [<10116068>] intr_return+0x0/0x4

This crash seems to happen due to an uninitialized variable "rc".
The compiler even warns about that:
CC drivers/ide/ide-cd.o
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c: In function `cdrom_newpc_intr':
/mnt/sda4/home/cvs/parisc/git-kernel/linus-linux-2.6/drivers/ide/ide-cd.c:612: warning: `rc' might be used uninitialized in this function

After applying the trivial patch below, which just initializes the variable to zero, the kernel doesn't crash any longer:

Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54 <3>{ AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
done.

Quoted 8 lines
Quoted 1 line
Signed-off-by Helge Deller <[email protected]>
Acked-by Borislav Petkov <[email protected]>

The original fix was correct. Helge, sorry for the delay but I wanted to make sure that this wasn't caused by recent rewrite in another area of ide-cd, thanks.

Bart, please apply.

Ok, done!