From: Ludo Van Put <hidden> Date: 2009-09-14 12:36:18
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
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-09-15 00:42:32
On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote:
2009/9/14 Josh Boyer [off-list ref]:
quoted
On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote:
quoted
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...
quoted
quoted
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.
From: Ludo Van Put <hidden> Date: 2009-09-15 08:57:39
2009/9/15 Benjamin Herrenschmidt [off-list ref]:
On Mon, 2009-09-14 at 15:08 +0200, Ludo Van Put wrote:
quoted
2009/9/14 Josh Boyer [off-list ref]:
quoted
On Mon, Sep 14, 2009 at 02:36:15PM +0200, Ludo Van Put wrote:
quoted
Hi,
we're working with a PPC440GX on a board that has a.o. a compact flash=
slot.
quoted
quoted
quoted
We had the PCI subsystem of the ppc disabled in strapping for quite a =
while,
quoted
quoted
quoted
until we wanted to start using it.
However, when we enabled PCI in the strapping and in the (patched 2.6.=
10)
quoted
quoted
2.6.10? =A0Really? =A0If that is truly the case, you probably aren't g=
oing to get
quoted
quoted
a whole lot of help from the list, since that kernel is pretty ancient=
.
quoted
quoted
I can only acknowledge that, but we're stuck to that kernel for now...
quoted
quoted
kernel configuration, we triggered an oops when probing for IDE device=
s (to
quoted
quoted
quoted
read out the first 512 bytes of the CF). I can see that the ioremap64 =
call
quoted
quoted
quoted
in the driver code for our CF returns a different address (compared to=
PCI
quoted
quoted
quoted
disabled in strapping), but using this address later on for accessing =
the CF
quoted
quoted
quoted
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 =
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2009-09-15 09:45:25
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.