On Tuesday, January 13, 2009 you wrote: > On Mon, 2009-01-12 at 14:37 +0100, Geert Uytterhoeven wrote: >> On Fri, 9 Jan 2009, Roland Dreier wrote: >> > > Can you double check that the e1000 isn't copying the PCI resources into >> > > a unsigned long before ioremap'ing the result, thus cropping the top >> > > bits ? >> > >> > as far as I can see, e1000 is using pci_ioremap_bar(), which should do >> > the right thing as long as resource_size_t is the right type (which it >> > looks like it is on PowerPC 44x). >> >> Indeed, the full 36-bit address is passed to __ioremap() via >> pci_ioremap_bar(), >> as evidenced from the additional debug output below (see [1]). >> >> As I don't have any other 3.3V PCI Ethernet cards, I plugged in a 3.3V PCI >> USB >> 2.0 card in the second PCI slot, and got a similar crash (see [2]). >> >> Are the PCI slots on the Sequoia known broken under recent Linux kernels? >> I've >> never used them before...
> Hrm, something is indeed wrong, hard to say what tho. My canyonlands > works fine (460EPx) and I can try a Taishan one of these days (440GX > iirc). What is in sequoia ? I think it's a GX no ? Sequoia is equipped with 440EPx. I observe the 'mal_probe' crash on the Katmai board too (based on 440SPe): PPC 4xx OCP EMAC driver, version 3.54 Unable to handle kernel paging request for data at address 0x0000003c Faulting instruction address: 0xc01becb8 Oops: Kernel access of bad area, sig: 11 [#1] PowerPC 44x Platform Modules linked in: NIP: c01becb8 LR: c0232200 CTR: c0014d68 REGS: cfe47d30 TRAP: 0300 Not tainted (2.6.29-rc1-00014-g58a813f-dirty) MSR: 00029000 <EE,ME,CE> CR: 42144084 XER: 20000000 DEAR: 0000003c, ESR: 00000000 TASK = cfe00000[1] 'swapper' THREAD: cfe40000 GPR00: c08ce244 cfe47de0 cfe00000 00000000 c08ce22c c0158864 00000020 00029000 GPR08: 000000d0 c08ce254 000000d0 00000744 82144082 89003000 7ffe4300 00000000 GPR16: 7ffd901c 7ffde640 00000000 00000000 00000000 00000000 00000000 0000000d GPR24: c0751e80 c0415e0c dfec1e00 c0751e64 c04161c8 00000000 dff46a00 c08ce200 NIP [c01becb8] netif_napi_add+0x1c/0x58 LR [c0232200] mal_probe+0x1cc/0x668 Call Trace: [cfe47de0] [c0232194] mal_probe+0x160/0x668 (unreliable) [cfe47e10] [c01abe38] of_platform_device_probe+0x5c/0x36c [cfe47e30] [c0152c24] driver_probe_device+0xb8/0x1e8 [cfe47e50] [c0152df8] __driver_attach+0xa4/0xa8 [cfe47e70] [c0151fa8] bus_for_each_dev+0x5c/0x98 [cfe47ea0] [c0152a2c] driver_attach+0x24/0x34 [cfe47eb0] [c0152788] bus_add_driver+0x1d8/0x258 [cfe47ee0] [c0153008] driver_register+0x5c/0x158 [cfe47f00] [c01abd00] of_register_driver+0x54/0x70 [cfe47f10] [c031a160] mal_init+0x20/0x30 [cfe47f20] [c031a2c8] emac_init+0x158/0x1b4 [cfe47f60] [c0001170] do_one_initcall+0x34/0x1a0 [cfe47fd0] [c0300168] kernel_init+0x88/0xf4 [cfe47ff0] [c000d8c4] kernel_thread+0x4c/0x68 Instruction dump: 7fe3fb78 7c0803a6 bb210014 38210030 4e800020 38000000 90040024 90040020 90a40010 90c4000c 90840000 38040018 <8123003c> 3963003c 91240018 90840004 ---[ end trace 22428c4f73106ff5 ]--- This is with Linus's tree, head ae0..e10bb. The work-around from Matthias Fuchs (Jan 09, 2009) helps though. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev