| Message ID | 49E6638B.8090700@gmx.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi, On Thu, Apr 16, 2009 at 12:45:31AM +0200, Helge Deller wrote: > 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 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.
Hi Borislav, Borislav Petkov wrote: > Hi, > > On Thu, Apr 16, 2009 at 12:45:31AM +0200, Helge Deller wrote: >> 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 > > 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) 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... -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Apr 16, 2009 at 10:26:06PM +0200, Helge Deller wrote: [..] > 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. 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 :). > BTW, even with my patch ATAPI CDROM accesses don't work with the current kernel... What do you mean by that, please elaborate?
Borislav Petkov wrote: > Hi, > > On Thu, Apr 16, 2009 at 10:26:06PM +0200, Helge Deller wrote: > > [..] > >> 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 >> >> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Apr 16, 2009 at 12:45:31AM +0200, Helge Deller wrote: > 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 <deller@gmx.de> Acked-by: Borislav Petkov <petkovbb@gmail.com> 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.
On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote: [..] > >> 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... Is it possible to isolate it and test without the superio driver?
On Wednesday 22 April 2009 08:10:46 Borislav Petkov wrote: > Hi, > > On Thu, Apr 16, 2009 at 12:45:31AM +0200, Helge Deller wrote: > > 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 <deller@gmx.de> > Acked-by: Borislav Petkov <petkovbb@gmail.com> > > 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! -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Borislav Petkov wrote: > On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote: > [..] >>>> 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... > > Is it possible to isolate it and test without the superio driver? No, since the superio controller provides the IDE ports. Best regards, Helge -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 22 April 2009 23:13:12 Helge Deller wrote: > Borislav Petkov wrote: > > On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote: > > [..] > >>>> 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... > > > > 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? -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bartlomiej Zolnierkiewicz wrote: > On Wednesday 22 April 2009 23:13:12 Helge Deller wrote: >> Borislav Petkov wrote: >>> On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote: >>> [..] >>>>>> 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... >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 25 April 2009 13:19:08 Helge Deller wrote: > Bartlomiej Zolnierkiewicz wrote: > > On Wednesday 22 April 2009 23:13:12 Helge Deller wrote: > >> Borislav Petkov wrote: > >>> On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote: > >>> [..] > >>>>>> 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... > >>> 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. > * 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. > * 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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bart, Bartlomiej Zolnierkiewicz wrote: > On Saturday 25 April 2009 13:19:08 Helge Deller wrote: >> Bartlomiej Zolnierkiewicz wrote: >>> On Wednesday 22 April 2009 23:13:12 Helge Deller wrote: >>>> Borislav Petkov wrote: >>>>> On Fri, Apr 17, 2009 at 09:15:27AM +0200, Helge Deller wrote: >>>>> [..] >>>>>>>> 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... >>>>> 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. > >> * 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. > >> * 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. Reverting this commit still showed the errors mentioned above. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Sun, Apr 26, 2009 at 12:51:46AM +0200, Helge Deller wrote: .. > > 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. 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.
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: > .. > > > > 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). > > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c index 3aec19d..3d4e099 100644 --- a/drivers/ide/ide-cd.c +++ b/drivers/ide/ide-cd.c @@ -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;
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 <deller@gmx.de> -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html