Oops in IDE probing on ppc_440 when PCI is enabled in strapping

Oops in IDE probing on ppc_440 when PCI is enabled in strapping

[Ludo Van Put]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping

[Josh Boyer]

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.

>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

Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping

[Ludo Van Put]

2009/9/14 Josh Boyer <jwboyer@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 sl=
ot.
>>We had the PCI subsystem of the ppc disabled in strapping for quite a whi=
le,
>>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? =A0Really? =A0If that is truly the case, you probably aren't goin=
g 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 cal=
l
>>in the driver code for our CF returns a different address (compared to PC=
I
>>disabled in strapping), but using this address later on for accessing the=
 CF
>>goes wrong.
>
> Posting the oops output would perhaps help. =A0Or 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 ta=
inted
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
DAR: E3093000, DSISR: 00000000
TASK =3D c07cdb70[1] 'swapper' THREAD: c07ce000
Last syscall: 120
GPR00: 00000000 C07CFEA0 C07CDB70 E3093000 DFE829FE 00000100 C01184E8 C021B=
270
GPR08: C0220000 C02D0F60 C07CDEF8 C07CDEF8 00000000 70000000 1FFF6400 00000=
001
GPR16: 00000001 FFFFFFFF 1FFF06C0 00000000 00000001 C0220000 C0280000 00029=
000
GPR24: 00000000 C02D0F60 C01F0000 C0148040 00000080 00000000 DFE82A00 C02D0=
FF0
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!
 <0>Rebooting 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

Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping

[Benjamin Herrenschmidt]

On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote:
> 2009/9/14 Josh Boyer <jwboyer@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: 00000000
> TASK = c07cdb70[1] 'swapper' THREAD: c07ce000
> Last syscall: 120
> GPR00: 00000000 C07CFEA0 C07CDB70 E3093000 DFE829FE 00000100 C01184E8 C021B270
> GPR08: C0220000 C02D0F60 C07CDEF8 C07CDEF8 00000000 70000000 1FFF6400 00000001
> GPR16: 00000001 FFFFFFFF 1FFF06C0 00000000 00000001 C0220000 C0280000 00029000
> GPR24: 00000000 C02D0F60 C01F0000 C0148040 00000080 00000000 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!
>  <0>Rebooting 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.

> KR, 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

[Ludo Van Put]

2009/9/15 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote:
>> 2009/9/14 Josh Boyer <jwboyer@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? =A0Really? =A0If that is truly the case, you probably aren't g=
oing 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 device=
s (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. =A0Or 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 =A0 =
=A0Not tainted
>> MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
>> DAR: E3093000, DSISR: 00000000
>> TASK =3D c07cdb70[1] 'swapper' THREAD: c07ce000
>> Last syscall: 120
>> GPR00: 00000000 C07CFEA0 C07CDB70 E3093000 DFE829FE 00000100 C01184E8 C0=
21B270
>> GPR08: C0220000 C02D0F60 C07CDEF8 C07CDEF8 00000000 70000000 1FFF6400 00=
000001
>> GPR16: 00000001 FFFFFFFF 1FFF06C0 00000000 00000001 C0220000 C0280000 00=
029000
>> GPR24: 00000000 C02D0F60 C01F0000 C0148040 00000080 00000000 DFE82A00 C0=
2D0FF0
>> NIP [c0148050] ide_insw+0x10/0x24
>> LR [c013bc64] ata_input_data+0x74/0x114
>> Call backtrace:
>> =A0c013e6a4 try_to_identify+0x2ec/0x5ec
>> =A0c013eaa8 do_probe+0x104/0x304
>> =A0c013f0c4 probe_hwif+0x358/0x6c4
>> =A0c0140068 ideprobe_init+0xa8/0x1a0
>> =A0c02a4ef8 ide_generic_init+0x10/0x28
>> =A0c0001324 init+0xc4/0x244
>> =A0c0004254 kernel_thread+0x44/0x60
>> Kernel panic - not syncing: Attempted to kill init!
>> =A0<0>Rebooting 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

Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping

[Benjamin Herrenschmidt]

On Tue, 2009-09-15 at 10:57 +0200, Ludo Van Put wrote:
> 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?

No. If you pass the right physical address to ioremap64, the result
should be useable as-is. The TLB entries will be faulted in
automatically by the kernel when doing accesses.

At this stage, I can't say what's wrong, it looks like you may be
accessing the wrong virtual address or something like that. Hard to
tell. It's a data access exception, not a machine check, so that means
that in some ways, the virtual address accessed by ide_insw is not
mapped by the kernel page tables, which is what the kernel TLB miss
handler uses to populate the TLB.

2.6.10 is so old, that I really have little memories of what is going on
in that area and I'm afraid am of little help here. If you have a HW
debugger such as a BDI, you may want to trace through the access, what
kind of TLB faults it generates and why the TLB miss handler doesn't
handle it.

Cheers,
Ben.