.
Signed-off-by: Markus Brunner
---
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 CR: 2482 XER: 2000
DAR: 00a0, DSISR: 2000
TASK = c02ce578[0
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" r
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 un
: 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.
o_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
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
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