* Oops in IDE probing on ppc_440 when PCI is enabled in strapping
@ 2009-09-14 12:36 Ludo Van Put
2009-09-14 12:51 ` Josh Boyer
0 siblings, 1 reply; 6+ messages in thread
From: Ludo Van Put @ 2009-09-14 12:36 UTC (permalink / raw)
To: linuxppc-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009-09-14 12:36 Oops in IDE probing on ppc_440 when PCI is enabled in strapping Ludo Van Put
@ 2009-09-14 12:51 ` Josh Boyer
2009-09-14 13:08 ` Ludo Van Put
0 siblings, 1 reply; 6+ messages in thread
From: Josh Boyer @ 2009-09-14 12:51 UTC (permalink / raw)
To: Ludo Van Put; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009-09-14 12:51 ` Josh Boyer
@ 2009-09-14 13:08 ` Ludo Van Put
2009-09-15 0:42 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 6+ messages in thread
From: Ludo Van Put @ 2009-09-14 13:08 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009-09-14 13:08 ` Ludo Van Put
@ 2009-09-15 0:42 ` Benjamin Herrenschmidt
2009-09-15 8:57 ` Ludo Van Put
0 siblings, 1 reply; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2009-09-15 0:42 UTC (permalink / raw)
To: Ludo Van Put; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009-09-15 0:42 ` Benjamin Herrenschmidt
@ 2009-09-15 8:57 ` Ludo Van Put
2009-09-15 9:44 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 6+ messages in thread
From: Ludo Van Put @ 2009-09-15 8:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Oops in IDE probing on ppc_440 when PCI is enabled in strapping
2009-09-15 8:57 ` Ludo Van Put
@ 2009-09-15 9:44 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2009-09-15 9:44 UTC (permalink / raw)
To: Ludo Van Put; +Cc: linuxppc-dev
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-09-15 9:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-14 12:36 Oops in IDE probing on ppc_440 when PCI is enabled in strapping Ludo Van Put
2009-09-14 12:51 ` Josh Boyer
2009-09-14 13:08 ` Ludo Van Put
2009-09-15 0:42 ` Benjamin Herrenschmidt
2009-09-15 8:57 ` Ludo Van Put
2009-09-15 9:44 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).