Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009/9/15 Benjamin Herrenschmidt b...@kernel.crashing.org: On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote: 2009/9/14 Josh Boyer jwbo...@linux.vnet.ibm.com: On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote: Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) 2.6.10? Really? If that is truly the case, you probably aren't going to get a whole lot of help from the list, since that kernel is pretty ancient. I can only acknowledge that, but we're stuck to that kernel for now... kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Posting the oops output would perhaps help. Or maybe not. josh Here it goes, you never know: Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C0148050 LR: C013BC64 SP: C07CFEA0 REGS: c07cfdf0 TRAP: 0300 Not tainted MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 DAR: E3093000, DSISR: TASK = c07cdb70[1] 'swapper' THREAD: c07ce000 Last syscall: 120 GPR00: C07CFEA0 C07CDB70 E3093000 DFE829FE 0100 C01184E8 C021B270 GPR08: C022 C02D0F60 C07CDEF8 C07CDEF8 7000 1FFF6400 0001 GPR16: 0001 1FFF06C0 0001 C022 C028 00029000 GPR24: C02D0F60 C01F C0148040 0080 DFE82A00 C02D0FF0 NIP [c0148050] ide_insw+0x10/0x24 LR [c013bc64] ata_input_data+0x74/0x114 Call backtrace: c013e6a4 try_to_identify+0x2ec/0x5ec c013eaa8 do_probe+0x104/0x304 c013f0c4 probe_hwif+0x358/0x6c4 c0140068 ideprobe_init+0xa8/0x1a0 c02a4ef8 ide_generic_init+0x10/0x28 c0001324 init+0xc4/0x244 c0004254 kernel_thread+0x44/0x60 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds.. ide_insw is a asm routine to read in 16bit words and swap them. Copied from arch/ppc/kernel/misc.S. Works fine when PCI is disabled. Probably because ide_insw uses isnw which offsets everything from _IO_BASE which changes value when you have a PCI bus with an IO space... If your IDE isn't PCI IO space based you shouldn't use ide_insw but the MMIO variants instead. Ben. Thnx for the suggestion, but the ide_insw is in fact of copy of the _insw assembly routine, and it gets passed the effective address, without the _IO_BASE offset. I was thinking about TLB stuff. I'm not a u-boot expert, but could it be that I need to tweak/reconfigure u-boot so I can access the address returned from ioremap64? KR, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Oops in IDE probing on ppc_440 when PCI is enabled in strapping
Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Does someone has an idea why this might go wrong? Can I end up with overlapping address ranges due to the PCI subsystem being enabled? Is this easy to check? As far as I know, the HW address of the PCI controller is in a non-overlapping range with the addresses we have setup in the EBC registers to probe for the CF (u-boot can see the IDE device just fine and it also has PCI turned on). TIA, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009/9/14 Josh Boyer jwbo...@linux.vnet.ibm.com: On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote: Hi, we're working with a PPC440GX on a board that has a.o. a compact flash slot. We had the PCI subsystem of the ppc disabled in strapping for quite a while, until we wanted to start using it. However, when we enabled PCI in the strapping and in the (patched 2.6.10) 2.6.10? Really? If that is truly the case, you probably aren't going to get a whole lot of help from the list, since that kernel is pretty ancient. I can only acknowledge that, but we're stuck to that kernel for now... kernel configuration, we triggered an oops when probing for IDE devices (to read out the first 512 bytes of the CF). I can see that the ioremap64 call in the driver code for our CF returns a different address (compared to PCI disabled in strapping), but using this address later on for accessing the CF goes wrong. Posting the oops output would perhaps help. Or maybe not. josh Here it goes, you never know: Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C0148050 LR: C013BC64 SP: C07CFEA0 REGS: c07cfdf0 TRAP: 0300Not tainted MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 DAR: E3093000, DSISR: TASK = c07cdb70[1] 'swapper' THREAD: c07ce000 Last syscall: 120 GPR00: C07CFEA0 C07CDB70 E3093000 DFE829FE 0100 C01184E8 C021B270 GPR08: C022 C02D0F60 C07CDEF8 C07CDEF8 7000 1FFF6400 0001 GPR16: 0001 1FFF06C0 0001 C022 C028 00029000 GPR24: C02D0F60 C01F C0148040 0080 DFE82A00 C02D0FF0 NIP [c0148050] ide_insw+0x10/0x24 LR [c013bc64] ata_input_data+0x74/0x114 Call backtrace: c013e6a4 try_to_identify+0x2ec/0x5ec c013eaa8 do_probe+0x104/0x304 c013f0c4 probe_hwif+0x358/0x6c4 c0140068 ideprobe_init+0xa8/0x1a0 c02a4ef8 ide_generic_init+0x10/0x28 c0001324 init+0xc4/0x244 c0004254 kernel_thread+0x44/0x60 Kernel panic - not syncing: Attempted to kill init! 0Rebooting in 180 seconds.. ide_insw is a asm routine to read in 16bit words and swap them. Copied from arch/ppc/kernel/misc.S. Works fine when PCI is disabled. KR, Ludo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
