RE: [BUG] oops in net_rx_action on 64-bit powerpc
Chris Friesen wrote: I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar to a Maple board). The first time I booted I got the first log below via the serial console. I rebooted and got as far as a login prompt. I was able to log in via the serial console, but then got an almost identical oops again, as shown in the second log below. I configed out the gigE drivers for the backplane so the only remaining network link was the e100 link used for booting, but the problem remained. Anyone have any idea what might be causing this? Thanks, Chris Starting xinetd: [ OK ] Starting cron: [ OK ] Unable to handle kernel paging request for data at address 0x00100108 that 00100108 pattern looks familiar, I'm not much help here, but I think that had something to do with the list management of the poll_list in a netdev struct. so now you just have to figure out why someone's netdev struct is becoming NULL. :-) Faulting instruction address: 0xc028c1cc Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 Maple Modules linked in: NIP: c028c1cc LR: c028c13c CTR: REGS: cfff7b90 TRAP: 0300 Not tainted (2.6.27-05329-g39076ba) MSR: 90009032 EE,ME,IR,DR CR: 2224 XER: 2000 DAR: 00100108, DSISR: 0a00 TASK = c0017a061080[0] 'swapper' THREAD: c0017a078000 CPU: 1 GPR00: cfff7e10 c059bfe0 0020 GPR04: 0001 c00178179800 c027fda8 GPR08: 00200200 0001 00100100 GPR12: 2222 c05bc500 GPR16: GPR20: 000a 0001 0001 GPR24: c05a2280 c05f5134 fffd9bbe 00ec GPR28: c6e30c28 0020 c0543440 c0017a279b40 NIP [c028c1cc] .net_rx_action+0x1e4/0x26c LR [c028c13c] .net_rx_action+0x154/0x26c Call Trace: [cfff7e10] [c028c13c] .net_rx_action+0x154/0x26c (unreliable) [cfff7ec0] [c0056938] .__do_softirq+0xf8/0x1f4 [cfff7f90] [c0024334] .call_do_softirq+0x14/0x24 [c0017a07b970] [c000bcdc] .do_softirq+0xf0/0x104 [c0017a07ba10] [c0056ae8] .irq_exit+0x70/0x88 [c0017a07ba90] [c000ba18] .do_IRQ+0x14c/0x244 [c0017a07bb30] [c0004710] hardware_interrupt_entry+0x18/0x1c --- Exception: 501 at .raw_local_irq_restore+0x38/0x44 LR = .cpu_idle+0xd8/0x154 [c0017a07be20] [c0012068] .cpu_idle+0x118/0x154 (unreliable) [c0017a07bec0] [c03d4304] .start_secondary+0x310/0x3e8 [c0017a07bf90] [c00072b4] .start_secondary_prolog+0x10/0x14 Instruction dump: eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 7c0803a6 4e800020 e81f0010 7809ffe3 40820038 e93f0008 e97f f92b0008 f969 e95c0008 fb9f [EMAIL PROTECTED]:/root uname -a Linux 10.41.18.77 2.6.27-05329-g39076ba #1 SMP Tue Oct 21 16:46:06 CST 2008 ppc64 GNU/Linux [EMAIL PROTECTED]:/root Unable to handle kernel paging request for data at address 0x00100108 Faulting instruction address: 0xc028c1cc Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 Maple Modules linked in: NIP: c028c1cc LR: c028c13c CTR: REGS: cfff7b90 TRAP: 0300 Not tainted (2.6.27-05329-g39076ba) MSR: 90009032 EE,ME,IR,DR CR: 2224 XER: 2000 DAR: 00100108, DSISR: 0a00 TASK = c0017a061080[0] 'swapper' THREAD: c0017a078000 CPU: 1 GPR00: cfff7e10 c059bfe0 0020 GPR04: 0001 0001 c027fda8 GPR08: 00200200 0001 00100100 GPR12: 2222 c05bc500 GPR16: GPR20: 000a 0001 0001 GPR24: c05a2280 c05f5134 0001000387ff 010c GPR28: c6e30c28 0020 c0543440 c0017a2b0b40 NIP [c028c1cc] .net_rx_action+0x1e4/0x26c LR [c028c13c] .net_rx_action+0x154/0x26c Call Trace: [cfff7e10] [c028c13c] .net_rx_action+0x154/0x26c (unreliable) [cfff7ec0] [c0056938] .__do_softirq+0xf8/0x1f4 [cfff7f90] [c0024334] .call_do_softirq+0x14/0x24 [c0017a07b970] [c000bcdc] .do_softirq+0xf0/0x104 [c0017a07ba10] [c0056ae8] .irq_exit+0x70/0x88 [c0017a07ba90] [c000ba18] .do_IRQ+0x14c/0x244 [c0017a07bb30] [c0004710] hardware_interrupt_entry+0x18/0x1c --- Exception: 501 at
RE: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
Brice Goglin wrote: Adrian Bunk wrote: But considering that igb is in a similar situation it would be nice if all 3 drivers would handle it the same way. Jesse, What do you think of the below patch? Seems like a much better solution. I can have Jeff Kirsher work on the equivalent patches for igb, and ixgbe today. I am not very familiar with Kconfig, but it seems to solve the problem. If a Kconfig guru could double-check... Yeah, please Kconfig gurus on the list have a quick look. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [BUILD_FAILURE] 2.6.27-git2 - allyesconfig on powerpc selectsCONFIG_INTEL_IOATDMA=y
Adrian Bunk wrote: On Mon, Oct 13, 2008 at 03:45:59PM +0530, Kamalesh Babulal wrote: Hi, 2.6.27-git2 kernel build fails, while building the kernel with from subject, on PPC. allyesconfig option. The allyesconfig selects CONFIG_INTEL_IOATDMA=y CC drivers/dma/ioat_dca.o drivers/dma/ioat_dca.c: In function âdca_enabled_in_biosâ: drivers/dma/ioat_dca.c:81: error: implicit declaration of function âcpuid_eaxâ drivers/dma/ioat_dca.c: In function âsystem_has_dca_enabledâ: drivers/dma/ioat_dca.c:91: error: implicit declaration of function âboot_cpu_hasâ drivers/dma/ioat_dca.c:91: error: âX86_FEATURE_DCAâ undeclared (first use in this function) drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported only once drivers/dma/ioat_dca.c:91: error: for each function it appears in.) drivers/dma/ioat_dca.c: In function âioat_dca_get_tagâ: drivers/dma/ioat_dca.c:190: error: implicit declaration of function âcpu_physical_idâ make[2]: *** [drivers/dma/ioat_dca.o] Error 1 make[1]: *** [drivers/dma] Error 2 make: *** [drivers] Error 2 ... Thanks for the report, the MYRI10GE and IXGBE commits that introduced the select's are really broken. it fixed an obvious bug with CONFIG_IXGBE=y and CONFIG_INTEL_IOATDMA=m, unfortunate that it is so difficult to use Kconfig for the uninitiated. For fixing it I need to know the intended semantics. Brian, Jesse, is it OK to limit the drivers to m with CONFIG_INTEL_IOATDMA=m ? why is the IOATDMA driver not depending on x86? x86 hardware (32 and 64 bit) are the only machines that will have ioatdma support, since the ioatdma (and dca) device is only in Intel server chipsets since S5000 (aka S5000, S5400, S7400 and derivatives/followons) What we want, is myri10ge and ixgbe drivers that can build whether or not CONFIG_INTEL_IOATDMA is enabled. IF CONFIG_INTEL_IOATDMA *is* enabled (which it should not be on PPC) then there are several cases we want to work: CONFIG_INTEL_IOATDMA=m --- CONFIG_IXGBE=[m|n] CONFIG_INTEL_IOATDMA=y --- CONFIG_IXGBE=[m|y|n] CONFIG_INTEL_IOATDMA=n --- CONFIG_IXGBE=[m|y|n] CONFIG_INTEL_IOATDMA depends on X86 same for myri10ge I think. I hope that cleared something up, we can seriously use some help from the experts to get Kconfig correct for this. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
Benjamin Herrenschmidt wrote: The e1000 driver stores the content of the PCI resources into unsigned long's before ioremapping. This breaks on 32 bits platforms that support 64 bits MMIO resources such as ppc 44x. This fixes it by removing those temporary variables and passing directly the result of pci_resource_start/len to ioremap. the patch is mostly fine, but looking through the tree, doesn't every driver that has 64 bit capable resources have this problem? in fact, skeleton module has this problem, if I'm not mistaken. e1000 isn't the only one. :-) The side effect is that I removed the assignments to the netdev fields mem_start, mem_end and base_addr, which are totally useless for PCI devices. also, concerning this, ifconfig shows the output of these variables, I don't think we want to blatantly remove them, as it is actually removing information that is, if not used, at least displayed to user space. eth6 Link encap:Ethernet HWaddr 00:0E:01:0C:02:03 inet addr:134.134.3.121 Bcast:134.134.3.255 Mask:255.255.255.0 inet6 addr: fe80::20e:1ff:fe0c:203/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9022519 errors:0 dropped:0 overruns:0 frame:0 TX packets:1303701 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4044613454 (3857.2 Mb) TX bytes:118365109 (112.8 Mb) Base address:0xf000 Memory:feac-feae ^ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
