[PATCH] stop send queue before resetting gianfar
After a transmit timed out, the reset task will be called, which will free the
allocated resources(stop_gfar). If gfar_poll will be called before the
resources get allocated again gfar_clean_tx_ring will call
dev_kfree_skb_any(NULL).
This Patch calls netif_stop_queue before calling stop_gfar.
Signed-off-by: Markus Brunner super.firetwis...@gmail.com
---
ops: Kernel access of bad area, sig: 11 [#1]
PREEMPT RSBBA100
Modules linked in:
NIP: c01a10c4 LR: c013b254 CTR: c013c038
REGS: c02e7d20 TRAP: 0300 Not tainted (2.6.27.20)
MSR: 1032 ME,IR,DR CR: 2482 XER: 2000
DAR: 00a0, DSISR: 2000
TASK = c02ce578[0] 'swapper' THREAD: c02e6000
GPR00: 00a0 c02e7dd0 c02ce578 0040 0001 c02ec1c0
1032
GPR08: c080d1e0 df9ea800 2482 0404f000
GPR16: ffbf ffdff7ff c02d0fd4 00100100
00200200
GPR24: c031220c 0001 0001 df849800 ff109000
df849b80
NIP [c01a10c4] dev_kfree_skb_irq+0x18/0x70
LR [c013b254] gfar_clean_tx_ring+0x70/0x11c
Call Trace:
[c02e7dd0] [c003e978] update_wall_time+0x730/0x744 (unreliable)
[c02e7df0] [c013b254] gfar_clean_tx_ring+0x70/0x11c
[c02e7e10] [c013c07c] gfar_poll+0x44/0x150
[c02e7e30] [c01a064c] net_rx_action+0xa8/0x19c
[c02e7e70] [c00251d4] __do_softirq+0x64/0xc0
[c02e7e90] [c0006384] do_softirq+0x40/0x58
[c02e7ea0] [c00250a8] irq_exit+0x40/0x9c
[c02e7eb0] [c000642c] do_IRQ+0x90/0xac
[c02e7ec0] [c0010ab4] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x9c/0xf8
LR = cpu_idle+0x9c/0xf8
[c02e7f80] [c0009820] cpu_idle+0x58/0xf8 (unreliable)
[c02e7fa0] [c01fb8c8] __got2_end+0x7c/0x90
[c02e7fc0] [c026c794] start_kernel+0x2c0/0x2d4
[c02e7ff0] [3438] 0x3438
Instruction dump:
7fa00124 80010024 bba10014 38210020 7c0803a6 4e800020 9421ffe0 7c0802a6
7c6b1b78 90010024 380300a0 bfa10014 7d200028 3129 7d20012d 40a2fff4
Kernel panic - not syncing: Fatal exception in interrupt
--- linux-2.6.29/drivers/net/gianfar.c.orig 2009-03-24 00:12:14.0
+0100
+++ linux-2.6.29/drivers/net/gianfar.c 2009-04-15 09:47:04.0 +0200
@@ -1534,8 +1534,10 @@ static void gfar_reset_task(struct work_
struct net_device *dev = priv-dev;
if (dev-flags IFF_UP) {
+ netif_stop_queue(dev);
stop_gfar(dev);
startup_gfar(dev);
+ netif_start_queue(dev);
}
netif_tx_schedule_all(dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
gianfar ooops after transmit timed out
Hi, my mpc8349 based board is known to have some problems with one ethernet phy and is producing more ( 0.001%) frame errors than it should. This is enough for the gianfar driver (of 2.6.27.20) to oops when I create lot's of packets with a ping flood. The oops occurs after NETDEV WATCHDOG reports that a transmit timed out. The driver does not oops on the other phy, which does not produce frame errors. Any Ideas? Markus ops: Kernel access of bad area, sig: 11 [#1] PREEMPT RSBBA100 Modules linked in: NIP: c01a10c4 LR: c013b254 CTR: c013c038 REGS: c02e7d20 TRAP: 0300 Not tainted (2.6.27.20) MSR: 1032 ME,IR,DR CR: 2482 XER: 2000 DAR: 00a0, DSISR: 2000 TASK = c02ce578[0] 'swapper' THREAD: c02e6000 GPR00: 00a0 c02e7dd0 c02ce578 0040 0001 c02ec1c0 1032 GPR08: c080d1e0 df9ea800 2482 0404f000 GPR16: ffbf ffdff7ff c02d0fd4 00100100 00200200 GPR24: c031220c 0001 0001 df849800 ff109000 df849b80 NIP [c01a10c4] dev_kfree_skb_irq+0x18/0x70 LR [c013b254] gfar_clean_tx_ring+0x70/0x11c Call Trace: [c02e7dd0] [c003e978] update_wall_time+0x730/0x744 (unreliable) [c02e7df0] [c013b254] gfar_clean_tx_ring+0x70/0x11c [c02e7e10] [c013c07c] gfar_poll+0x44/0x150 [c02e7e30] [c01a064c] net_rx_action+0xa8/0x19c [c02e7e70] [c00251d4] __do_softirq+0x64/0xc0 [c02e7e90] [c0006384] do_softirq+0x40/0x58 [c02e7ea0] [c00250a8] irq_exit+0x40/0x9c [c02e7eb0] [c000642c] do_IRQ+0x90/0xac [c02e7ec0] [c0010ab4] ret_from_except+0x0/0x14 --- Exception: 501 at cpu_idle+0x9c/0xf8 LR = cpu_idle+0x9c/0xf8 [c02e7f80] [c0009820] cpu_idle+0x58/0xf8 (unreliable) [c02e7fa0] [c01fb8c8] __got2_end+0x7c/0x90 [c02e7fc0] [c026c794] start_kernel+0x2c0/0x2d4 [c02e7ff0] [3438] 0x3438 Instruction dump: 7fa00124 80010024 bba10014 38210020 7c0803a6 4e800020 9421ffe0 7c0802a6 7c6b1b78 90010024 380300a0 bfa10014 7d200028 3129 7d20012d 40a2fff4 Kernel panic - not syncing: Fatal exception in interrupt The Trace with kgdb: dev_kfree_skb_irq (skb=0x0) at arch/powerpc/include/asm/atomic.h:165 165 __asm__ __volatile__( (gdb) bt #0 dev_kfree_skb_irq (skb=0x0) at arch/powerpc/include/asm/atomic.h:165 #1 0xc013b254 in gfar_clean_tx_ring (dev=0xdf849800) at drivers/net/gianfar.c:1384 #2 0xc013c07c in gfar_poll (napi=0xdf849ba4, budget=value optimized out) at drivers/net/gianfar.c:1705 #3 0xc01a064c in net_rx_action (h=value optimized out) at net/core/dev.c:2384 #4 0xc00251d4 in __do_softirq () at kernel/softirq.c:208 #5 0xc0006384 in do_softirq () at arch/powerpc/kernel/irq.c:430 #6 0xc00250a8 in irq_exit () at kernel/softirq.c:284 #7 0xc000642c in do_IRQ (regs=value optimized out) at arch/powerpc/kernel/irq.c:325 #8 0xc0010ab4 in ret_from_except_full () #9 0xc0009820 in cpu_idle () at arch/powerpc/kernel/idle.c:59 #10 0xc01fb8c8 in rest_init () at init/main.c:481 #11 0xc026c794 in start_kernel () at init/main.c:691 #12 0x3438 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: UIO not working on ppc405 onchip registers
On Tuesday 22 July 2008, Ben Nizette wrote: But I'll let you get back to solving the UIO problem at hand :-D I already surrendered and created (hacked) a read/write driver, which let me use the old userspace drivers I'm trying to port (with some changes of course). This was way faster than understanding all the involved APIs and creating glue code between them. And the amount of time it needs was easy to estimate. However accidently I ran over the old school userland mmap code with /dev/mem. I already knew mapping with /dev/mem is possible but I haven't thought this could make a difference. http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023811.html Also I was wrong with my assumption that uio worked well on the peripherals. It worked (very) well on the leds, just to fool me!!! But it returned crap on some version registers. With a working and a non working version of mmap it should be rather easy to trace this bug. Unfortunately I was already short of time before running into this (and other) problems and it didn't get any better. So I would need some help from someone with more experience to fix this. Any instructions? Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] add a simple 405EP based board
This adds support for a simple ppc405ep board.
At the moment, there are no 405ep boards in arch/powerpc, so this can be used
as a template
for new boards, or migrating them from arch/ppc.
I2c, UART and EMAC are working. PCI could not be tested, so it was not included
in the dts.
Signed-off-by: Markus Brunner [EMAIL PROTECTED]
---
boot/dts/ppc405ep.dts| 218 +++
platforms/40x/Kconfig|8 +
platforms/40x/Makefile |1
platforms/40x/ppc405ep.c | 58
4 files changed, 285 insertions(+)
diff -upNr linux-2.6.27-rc4-orig/arch/powerpc/boot/dts/ppc405ep.dts
linux-2.6.27-rc4/arch/powerpc/boot/dts/ppc405ep.dts
--- linux-2.6.27-rc4-orig/arch/powerpc/boot/dts/ppc405ep.dts1970-01-01
01:00:00.0 +0100
+++ linux-2.6.27-rc4/arch/powerpc/boot/dts/ppc405ep.dts 2008-08-21
09:35:45.722031912 +0200
@@ -0,0 +1,218 @@
+/*
+ * Device Tree Source for ppc405ep
+ *
+ * (c) 2008 Markus Brunner [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ model = company,ppc405ep;
+ compatible = company,ppc405ep;
+ dcr-parent = /cpus/[EMAIL PROTECTED];
+
+ aliases {
+ ethernet0 = EMAC0;
+ ethernet1 = EMAC1;
+ serial0 = UART0;
+ serial1 = UART1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ device_type = cpu;
+ model = PowerPC,405EP;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by u-boot */
+ timebase-frequency = 0; /* Filled in by u-boot */
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
+ i-cache-size = 4000;
+ d-cache-size = 4000;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = ; /* Filled in by u-boot */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 9;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ plb {
+ compatible = ibm,plb3;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by u-boot */
+
+ SDRAM0: memory-controller {
+ compatible = ibm,sdram-405ep;
+ dcr-reg = 010 2;
+ };
+
+ MAL: mcmal {
+ compatible = ibm,mcmal-405ep, ibm,mcmal;
+ dcr-reg = 180 62;
+ num-tx-chans = 4;
+ num-rx-chans = 4;
+ interrupt-parent = UIC0;
+ interrupts =
+ b 4 /* TXEOB */
+ c 4 /* RXEOB */
+ a 4 /* SERR */
+ d 4 /* TXDE */
+ e 4 /* RXDE */;
+ };
+
+ POB0: opb {
+ compatible = ibm,opb-405ep, ibm,opb;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = ef60 ef60 a0;
+ dcr-reg = 0a0 5;
+ clock-frequency = 0; /* Filled in by u-boot */
+
+ UART0: [EMAIL PROTECTED] {
+ device_type = serial;
+ compatible = ns16550;
+ reg = ef600300 8;
+ virtual-reg = ef600300;
+ clock-frequency = 0; /* Filled in by u-boot */
+ current-speed = 1c200;
+ interrupt-parent = UIC0;
+ interrupts = 0 4;
+ };
+
+ UART1: [EMAIL PROTECTED] {
+ device_type = serial;
+ compatible = ns16550;
+ reg = ef600400 8;
+ virtual-reg = ef600400;
+ clock-frequency = 0; /* Filled in by u-boot */
+ current-speed = 1c200
UIO not working on ppc405 onchip registers
= {
+ .name = uio_gpio,
+ .version = 0.0.0,
+ .irq = UIO_IRQ_NONE,
+ .irq_flags = 0,
+.mem[0].addr = 0xef600700,
+.mem[0].size = 0x1000,
+ .mem[0].memtype = UIO_MEM_PHYS,
+};
+
+static int __devinit uio_gpio_probe(struct device *dev)
+{
+ if (uio_register_device(dev, info)){
+ printk(KERN_ERR uio_gpio: uio_register_device failed\n);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+static int uio_gpio_remove(struct device *dev)
+{
+ uio_unregister_device(info);
+ info.mem[0].addr = 0;
+ info.mem[0].size = 0;
+ return 0;
+}
+
+static struct platform_device *uio_gpio_device;
+
+static struct device_driver uio_gpio_driver = {
+ .name = uio_gpio,
+ .bus= platform_bus_type,
+ .probe = uio_gpio_probe,
+ .remove = uio_gpio_remove,
+};
+
+
+static int __init uio_gpio_init(void)
+{
+ uio_gpio_device = platform_device_register_simple(uio_gpio, -1,
+ NULL, 0);
+ if (IS_ERR(uio_gpio_device))
+ return PTR_ERR(uio_gpio_device);
+
+ return driver_register(uio_gpio_driver);
+}
+
+static void __exit uio_gpio_exit(void)
+{
+ platform_device_unregister(uio_gpio_device);
+ driver_unregister(uio_gpio_driver);
+}
+
+module_init(uio_gpio_init);
+module_exit(uio_gpio_exit);
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Markus Brunner);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Phy read timeout in ibm_new_emac driver
On Wednesday 16 April 2008, Benjamin Herrenschmidt wrote: Somebody knows off hand what the standard says the timeout should be ? Anyone? I didn't find any documentation on the standard, but I had a look at other drivers. au1000_eth.c waits 20 ms (20 * 1ms) in mdio_read. bfin_mac.c waits 500 * 1us in mdio_poll. In both functions the last delay before the timeout is useless, like in new_emac. Not nice, but timeouts shouldn't occur anyway. new emac probably doesn't wait long enough, but 20ms seems to be a bit too long. Regards Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Get new_emac driver running on 405EP
On Monday 14 April 2008, Benjamin Herrenschmidt wrote: 2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both phys have to be accessed through this one. This affectes the mdio read/write functions. The later can easily be described in the device-tree as it's a fairly common setup. mdio-device does the trick. This feature wasn't used by any other board in the kernel yet. I made another error. I did mix up the order of the MAL irqs, so the irq handlers went mad. This was detected as a soft lock-up. After correcting that both emacs are working on ppc405EP :). Regards Markus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
