Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

[Riku Voipio]

Hi,

> Lennert, I have compared 2.6.19-rc4 + 0001-r8169-perform-a-PHY-reset-etc
> with the serie of patches against 2.6.18-rc4 which was reported to work
> on your n2100 (thread on netdev around 05/09/2006). Can you:
> 
> - apply the patch below on top of 2.6.19-rc4 + 0001 and see if it works ?
>   Don't apply 0002, it is not required.

I took 2.6.19-rc5 as there was no changes in this driver relative to -rc4. 
applied Francois's 0001-r8169-perform-a-PHY-reset.. and finally the
patch in this mail. And networking _does_not_ work on Thecus N2100.

mii-tool sees the link being connected and disconnected, but dhcp or ping
with static ip goes nowhere.

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

[Francois Romieu]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

Riku Voipio <riku.voipio@iki.fi> :
[...]
> I took 2.6.19-rc5 as there was no changes in this driver relative to -rc4. 
> applied Francois's 0001-r8169-perform-a-PHY-reset.. and finally the
> patch in this mail. And networking _does_not_ work on Thecus N2100.

It sucks.

Can you try against 2.6.18-rc4 the patch at:

http://www.fr.zoreil.com/people/francois/misc/20061109-2.6.18-rc4-r8169-test.patch

If it does not work, apply on top of 2.6.18-rc4 the serie available at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc4/r8169
plus the attached patch.

-- 
Ueimor

[-- Attachment #2: 0010-r8169-quirk-for-the-8110sb-on-arm-platform.txt --]
[-- Type: text/plain, Size: 1793 bytes --]

>From 20f33886d041e00cde9c6339ff4d724d992c99bc Mon Sep 17 00:00:00 2001
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon, 11 Sep 2006 20:10:58 +0200
Subject: [PATCH] r8169: quirk for the 8110sb on arm platform

Inverting the write ordering of the TxDescAddr{High/Low} registers
suffices to trigger a sabbat of PCI errors which make the device
completely dysfunctional. The issue has not been reported on a
different platform.

Switching from MMIO accesses to I/O ones as done in Realtek's
own driver fixes (papers over ?) the bug as well but I am not
thrilled to see everyone pay the I/O price for an obscure bug.

This is the minimal change to handle the issue.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Reported-by: Lennert Buytenhek <buytenh@wantstofly.org>
---
 drivers/net/r8169.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7ab79db..582b116 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1868,10 +1868,15 @@ rtl8169_hw_start(struct net_device *dev)
 	 */
 	RTL_W16(IntrMitigate, 0x0000);
 
-	RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK));
+	/*
+	 * Magic spell: some iop3xx ARM board needs the TxDescAddrHigh
+	 * register to be written before TxDescAddrLow to work.
+	 * Switching from MMIO to I/O access fixes the issue as well.
+	 */
 	RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32));
-	RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK));
+	RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK));
 	RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32));
+	RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK));
 	RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 
-- 
1.4.2.4

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

[Lennert Buytenhek]

On Thu, Nov 09, 2006 at 11:13:38PM +0100, Francois Romieu wrote:

> > I took 2.6.19-rc5 as there was no changes in this driver relative to -rc4. 
> > applied Francois's 0001-r8169-perform-a-PHY-reset.. and finally the
> > patch in this mail. And networking _does_not_ work on Thecus N2100.
> 
> It sucks.
> 
> Can you try against 2.6.18-rc4 the patch at:
> 
> http://www.fr.zoreil.com/people/francois/misc/20061109-2.6.18-rc4-r8169-test.patch
> 
> If it does not work, apply on top of 2.6.18-rc4 the serie available at:
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.18-rc4/r8169
> plus the attached patch.

Wouldn't it be easier for all of us if we'd arrange a shell account
on an n2100 for you?

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

[Francois Romieu]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> Wouldn't it be easier for all of us if we'd arrange a shell account
> on an n2100 for you?

Ssh keyfile attached.

-- 
Ueimor

[-- Attachment #2: r8169-n2100.pub --]
[-- Type: text/plain, Size: 623 bytes --]

ssh-dss AAAAB3NzaC1kc3MAAACBAIQzLEqjuZ7G6v91JxdZ6S2l465mGzirY3qDfGDp9Qfiw8EhrEYrPGAbSnu0iTrBict5ONiVVwlwEbtTE8pJ/YCBqEpU25Im01AmjR4Usg6m20HV+4a9XSahrYvsMSrRJwLhqdp9oMC6XPtMbrq3Lee8UfWHk3xZLG7ekzXO9dOFAAAAFQCNT5WHpMwIUiQHXejPXLltZWA+6wAAAIBx8cOTbjuij12b25S02HM4sGXow32qxDYLLwNLGr4j/pXOX1RHqlvL5Ex4H6nBnYaWXnB9eRkitO3Ho7EUF0tqPbocug9DBa61gHdLhIKJCCUMXbTibVAwkeBV6bXgYGoWgCny80OGkN6b2XVLCWIeXpZEwS3mGHpIny+3LGTvIAAAAIBT2GApaPoj77NI00Pbs/ijofZuhXp0BF7K8zdAc374LWrdrc+ZIsTY8InK1jNAhl8m5LrTaD4cdDdVp2H4UVKsxs71KETmNlbKukU5zQyDZffICZmrkYhbRonE8aei5oYZ0YWUL4i1AbrQYhzS3810QERGyuw0IpespabiyOU4xg== romieu@electric-eye.fr.zoreil.com

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

[Martin Michlmayr]

* Francois Romieu <romieu@fr.zoreil.com> [2006-11-10 19:59]:
> > Wouldn't it be easier for all of us if we'd arrange a shell account
> > on an n2100 for you?
> Ssh keyfile attached.

Did you have any success?
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)]

[Francois Romieu]

Martin Michlmayr <tbm@cyrius.com> :
[...]
> Did you have any success ?

I was not able to reproduce the results expected from a driver close to
the one which was supposed to work back with 2.6.18-rc4. OTOH, as Lennert
noticed, simply ignoring the PCI data parity errors seems to do the trick.
There are quite a lot of these errors though.

I'll do one or two more tests but the driver will surely be simply added
a big knob to control its behavior when parity errors appear.

-- 
Ueimor

r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Francois Romieu <romieu@fr.zoreil.com> :
[scrouitch]

You can apply the patch below and 'modprobe r8169 ignore_parity_err=1'.

It apparently does the job and it is not much too intrusive.

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 27f90b2..2b8c057 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -225,6 +225,7 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl
 
 static int rx_copybreak = 200;
 static int use_dac;
+static int ignore_parity_err;
 static struct {
 	u32 msg_enable;
 } debug = { -1 };
@@ -469,6 +470,8 @@ module_param(use_dac, int, 0);
 MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
 module_param_named(debug, debug.msg_enable, int, 0);
 MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
+module_param_named(ignore_parity_err, ignore_parity_err, bool, 0);
+MODULE_PARM_DESC(ignore_parity_err, "Ignore PCI parity error as target. Default: false");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(RTL8169_VERSION);
 
@@ -2332,12 +2335,17 @@ static void rtl8169_pcierr_interrupt(str
 	/*
 	 * The recovery sequence below admits a very elaborated explanation:
 	 * - it seems to work;
-	 * - I did not see what else could be done.
+	 * - I did not see what else could be done;
+	 * - it makes iop3xx happy.
 	 *
 	 * Feel free to adjust to your needs.
 	 */
-	pci_write_config_word(pdev, PCI_COMMAND,
-			      pci_cmd | PCI_COMMAND_SERR | PCI_COMMAND_PARITY);
+	if (ignore_parity_err)
+		pci_cmd &= ~PCI_COMMAND_PARITY;
+	else
+		pci_cmd |= PCI_COMMAND_SERR | PCI_COMMAND_PARITY;
+
+	pci_write_config_word(pdev, PCI_COMMAND, pci_cmd);
 
 	pci_write_config_word(pdev, PCI_STATUS,
 		pci_status & (PCI_STATUS_DETECTED_PARITY |
@@ -2351,10 +2359,11 @@ static void rtl8169_pcierr_interrupt(str
 		tp->cp_cmd &= ~PCIDAC;
 		RTL_W16(CPlusCmd, tp->cp_cmd);
 		dev->features &= ~NETIF_F_HIGHDMA;
-		rtl8169_schedule_work(dev, rtl8169_reinit_task);
 	}
 
 	rtl8169_hw_reset(ioaddr);
+
+	rtl8169_schedule_work(dev, rtl8169_reinit_task);
 }
 
 static void

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Martin Michlmayr]

* Francois Romieu <romieu@fr.zoreil.com> [2006-11-23 00:16]:
> It apparently does the job and it is not much too intrusive.

I can confirm that it works.  Do you think there'll be a better fix in
the future?  Do you believe that the boot loader on the N2100 doesn't
initialize Ethernet properly or that this is a generic problem on iop
or with this particular RTL chip?  We have fairly good contacts with
the company producing the N2100 so if it's the former it could
probably be fixed. (Altough I'm not sure this is the case given that
Realtek's driver works).
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Martin Michlmayr <tbm@cyrius.com> :
[...]
> Do you think there'll be a better fix in the future ?

It's the best trade-off that I can figure but there are surely more
knowledgeable people than me. The patch does not completely disable
the reporting of serious PCI errors. If the user knows that it is
otherwise safe, he can disable it: the error will then be reported
only once. I must confess that the history of the 8169 PCI errors is
not crystal clear.

> Do you believe that the boot loader on the N2100 doesn't
> initialize Ethernet properly or that this is a generic problem on iop
> or with this particular RTL chip?  We have fairly good contacts with
> the company producing the N2100 so if it's the former it could
> probably be fixed. (Altough I'm not sure this is the case given that
> Realtek's driver works).

Yes, switching from MM register accesses has been reported to fix/hide
the issue but it's a sledgehammer which does not tell what is going on
(side note: Realtek's driver does not enable the SYSErr irq).

So far I can only tell that 1) the 8169 reports a data parity error on
almost each received packet when it is not silenced 2) the error can
be ignored. If there really is an error and the chipset automatically
retries the transaction, one should expect some loss of efficiency but
it will not necessarily be easy to notice through software.

If I had unlimited resources/time/$$$, I would plug a PCI bus analyzer
and check what is going on. :o)

-- 
Ueimor

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Thu, Nov 23, 2006 at 12:16:56AM +0100, Francois Romieu wrote:

> You can apply the patch below and 'modprobe r8169 ignore_parity_err=1'.

Is there a way we can have this done by default on the n2100?  I guess
that since it's a PCI device, there isn't much hope for that..?

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> Is there a way we can have this done by default on the n2100?  I guess
> that since it's a PCI device, there isn't much hope for that..?

Do you mean an automagically tuned default value based on CONFIG_ARM ?

-- 
Ueimor

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote:

> > Is there a way we can have this done by default on the n2100?  I guess
> > that since it's a PCI device, there isn't much hope for that..?
> 
> Do you mean an automagically tuned default value based on CONFIG_ARM ?

No, that wouldn't make sense, that's like making a workaround depend on
arch == i386.

I'm thinking that we should somehow enable this option on the n2100
built-in r8169 ports by default only.  Since the n2100 also has a mini-PCI
slot, and it is in theory possible to put an r8169 on a mini-PCI card,
the workaround probably shouldn't apply to those, so testing for
CONFIG_MACH_N2100 also isn't the right thing to do.

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Russell King]

On Fri, Dec 15, 2006 at 10:03:29PM +0100, Lennert Buytenhek wrote:
> On Fri, Dec 15, 2006 at 09:15:22PM +0100, Francois Romieu wrote:
> 
> > > Is there a way we can have this done by default on the n2100?  I guess
> > > that since it's a PCI device, there isn't much hope for that..?
> > 
> > Do you mean an automagically tuned default value based on CONFIG_ARM ?
> 
> No, that wouldn't make sense, that's like making a workaround depend on
> arch == i386.
> 
> I'm thinking that we should somehow enable this option on the n2100
> built-in r8169 ports by default only.  Since the n2100 also has a mini-PCI
> slot, and it is in theory possible to put an r8169 on a mini-PCI card,
> the workaround probably shouldn't apply to those, so testing for
> CONFIG_MACH_N2100 also isn't the right thing to do.

There is dev->broken_parity_status ... although exactly what the sematics
of that flag actually are seems to be rather vague - there's code which
sets it for the Mellanox Tavor device, but it seems to only be exposed
via sysfs - no code in drivers/pci seems to take any action based upon
this flag being set.

That rather raises the question about the usefulness of that quirk.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Fri, Dec 15, 2006 at 09:14:35PM +0000, Russell King wrote:

> > > > Is there a way we can have this done by default on the n2100?  I guess
> > > > that since it's a PCI device, there isn't much hope for that..?
> > > 
> > > Do you mean an automagically tuned default value based on CONFIG_ARM ?
> > 
> > No, that wouldn't make sense, that's like making a workaround depend on
> > arch == i386.
> > 
> > I'm thinking that we should somehow enable this option on the n2100
> > built-in r8169 ports by default only.  Since the n2100 also has a mini-PCI
> > slot, and it is in theory possible to put an r8169 on a mini-PCI card,
> > the workaround probably shouldn't apply to those, so testing for
> > CONFIG_MACH_N2100 also isn't the right thing to do.
> 
> There is dev->broken_parity_status ... although exactly what the sematics
> of that flag actually are seems to be rather vague - there's code which
> sets it for the Mellanox Tavor device, but it seems to only be exposed
> via sysfs - no code in drivers/pci seems to take any action based upon
> this flag being set.

Sounds good.  How about something like the patch below plus the
corresponding r8169 diff?


Index: linux-2.6.19/arch/arm/mach-iop32x/n2100.c
===================================================================
--- linux-2.6.19.orig/arch/arm/mach-iop32x/n2100.c
+++ linux-2.6.19/arch/arm/mach-iop32x/n2100.c
@@ -123,9 +123,13 @@ static struct hw_pci n2100_pci __initdat
 
 static int __init n2100_pci_init(void)
 {
-	if (machine_is_n2100())
+	if (machine_is_n2100()) {
 		pci_common_init(&n2100_pci);
 
+		pci_get_bus_and_slot(0, 0x08)->broken_parity_status = 1;
+		pci_get_bus_and_slot(0, 0x10)->broken_parity_status = 1;
+	}
+
 	return 0;
 }

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> Sounds good.  How about something like the patch below plus the
> corresponding r8169 diff?

Go wild.

-- 
Ueimor

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Sun, Dec 17, 2006 at 12:31:34AM +0100, Francois Romieu wrote:

> > Sounds good.  How about something like the patch below plus the
> > corresponding r8169 diff?
> 
> Go wild.

Martin/Riku, I'm pretty busy with other stuff at the moment, can you
give this (on top of 2.6.20-rc1) a spin?  


Index: linux-2.6.19/arch/arm/mach-iop32x/n2100.c
===================================================================
--- linux-2.6.19.orig/arch/arm/mach-iop32x/n2100.c
+++ linux-2.6.19/arch/arm/mach-iop32x/n2100.c
@@ -123,9 +123,13 @@ static struct hw_pci n2100_pci __initdat
 
 static int __init n2100_pci_init(void)
 {
-	if (machine_is_n2100())
+	if (machine_is_n2100()) {
 		pci_common_init(&n2100_pci);
 
+		pci_get_bus_and_slot(0, 0x08)->broken_parity_status = 1;
+		pci_get_bus_and_slot(0, 0x10)->broken_parity_status = 1;
+	}
+
 	return 0;
 }
 
Index: linux-2.6.19/drivers/net/r8169.c
===================================================================
--- linux-2.6.19.orig/drivers/net/r8169.c
+++ linux-2.6.19/drivers/net/r8169.c
@@ -225,7 +225,6 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl
 
 static int rx_copybreak = 200;
 static int use_dac;
-static int ignore_parity_err;
 static struct {
 	u32 msg_enable;
 } debug = { -1 };
@@ -471,8 +470,6 @@ module_param(use_dac, int, 0);
 MODULE_PARM_DESC(use_dac, "Enable PCI DAC. Unsafe on 32 bit PCI slot.");
 module_param_named(debug, debug.msg_enable, int, 0);
 MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
-module_param_named(ignore_parity_err, ignore_parity_err, bool, 0);
-MODULE_PARM_DESC(ignore_parity_err, "Ignore PCI parity error as target. Default: false");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(RTL8169_VERSION);
 
@@ -2388,7 +2385,7 @@ static void rtl8169_pcierr_interrupt(str
 	 *
 	 * Feel free to adjust to your needs.
 	 */
-	if (ignore_parity_err)
+	if (pdev->broken_parity_status)
 		pci_cmd &= ~PCI_COMMAND_PARITY;
 	else
 		pci_cmd |= PCI_COMMAND_SERR | PCI_COMMAND_PARITY;

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Martin Michlmayr]

* Lennert Buytenhek <buytenh@wantstofly.org> [2006-12-17 00:52]:
> Martin/Riku, I'm pretty busy with other stuff at the moment, can you
> give this (on top of 2.6.20-rc1) a spin?

I'm currently travelling but I'll try in a few days.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Riku Voipio]

> > bah. 2.6.20-git shows nothing (with or without Lennert's patch) after
> > the following:
 
> > Uncompressing Linux..........................................................................................done, booting the kernel.
> 
> Try the printascii()-in-printk() hack in my svn tree.

Thanks, that was priceless advice. I reverted 
da2c12a279ae225f3d4696f76cb3b32a5bec5bfb "[ARM] Clean up ioremap code"
and n2100 booted fine. I can now confirm Lennerts patch makes 
r8169 work without any module parameter work on Thecus n2100.

With ioremap cleanup code and printascii, the kernel boot looks
like following:

Uncompressing Linux............................................................................
<5>Linux version 2.6.20-rc1n2100 (nchip@watergate-2) (gcc version 4.1.0) #8 Sun Dec 17 22:09:06
CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=0000397f
Machine: Thecus N2100
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 65536
<7>  DMA zone: 512 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 65024 pages, LIFO batch:15
<7>  Normal zone: 0 pages used for memmap
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists.  Total pages: 65024
<5>Kernel command line: console=ttyS0,115200 root=/dev/sda1 mem=256M@0xa0000000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Memory: 256MB = 256MB total
<5>Memory: 256896KB available (2568K code, 185K data, 104K init)
<7>Calibrating delay loop... 593.10 BogoMIPS (lpj=2965504)
Mount-cache hash table entries: 512
<6>CPU: Testing write buffer coherency: ok
<6>NET: Registered protocol family 16
<6>PCI: bus0: Fast back to back transfers disabled
<5>SCSI subsystem initialized
<7>libata version 2.00 loaded.
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP: Hash tables configured (established 8192 bind 4096)
<6>TCP reno registered
<4>NetWinder Floating Point Emulator V0.97 (extended precision)
<6>Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
<6>JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
<6>io scheduler noop registered
<6>io scheduler anticipatory registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<2>remap_area_pte: page already exists
<2>kernel BUG at arch/arm/mm/ioremap.c:61!
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
<1>pgd = c0004000
<1>[00000000] *pgd=00000000
Internal error: Oops: 8f5 [#1]
Modules linked in:
CPU: 0
PC is at __bug+0x20/0x2c
LR is at 0x1
pc : [<c0026988>]    lr : [<00000001>]    Not tainted
sp : c0531ee0  ip : 60000093  fp : c0531eec
r10: d0850000  r9 : d0850000  r8 : 80250000
r7 : d0a00000  r6 : c0521000  r5 : d0850c00  r4 : d0850c00
r3 : 00000000  r2 : 00000000  r1 : 000008ac  r0 : 0000002b
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: 397F
Table: A0004000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc0530250)
Stack: (0xc0531ee0 to 0xc0532000)
1ee0: c0531f38 c0531ef0 c0029ee8 c0026974 d0850c00 00000400 c0007420 000000a3
1f00: c0007420 d0850000 800a0000 800a0000 00000000 c0546400 c0291478 00000000
1f20: 00000000 00000000 00000000 c0531f4c c0531f3c c0029fe0 c0029bf4 c0291470
1f40: c0531f7c c0531f50 c01984dc c0029f8c c0157b54 c0291470 c0546400 c0291478
1f60: 00000000 00000000 00000000 00000000 c0531f98 c0531f80 c01361d0 c0198334
1f80: c0546400 c001e6f8 c0530000 c0531fac c0531f9c c0134f4c c0136140 c001ec84
1fa0: c0531ff4 c0531fb0 c00220c0 c0134f3c 00000000 00000000 c002202c c003f14c
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 c0531ff8 c003f14c c0022038 00000000 00000000
Backtrace:
[<c0026968>] (__bug+0x0/0x2c) from [<c0029ee8>] (__ioremap_pfn+0x300/0x398)
[<c0029be8>] (__ioremap_pfn+0x0/0x398) from [<c0029fe0>] (__ioremap+0x60/0x6c)
[<c0029f80>] (__ioremap+0x0/0x6c) from [<c01984dc>] (quirk_usb_early_handoff+0x1b4/0x380)
 r4 = C0291470
[<c0198328>] (quirk_usb_early_handoff+0x0/0x380) from [<c01361d0>] (pci_fixup_device+0x9c/0xd4)
[<c0136134>] (pci_fixup_device+0x0/0xd4) from [<c0134f4c>] (pci_init+0x1c/0x3c)
 r6 = C0530000  r5 = C001E6F8  r4 = C0546400
[<c0134f30>] (pci_init+0x0/0x3c) from [<c00220c0>] (init+0x94/0x27c)
 r4 = C001EC84
[<c002202c>] (init+0x0/0x27c) from [<c003f14c>] (do_exit+0x0/0x7e4)
 r7 = 00000000  r6 = 00000000  r5 = 00000000  r4 = 00000000
Code: e1a01000 e59f000c eb00596d e3a03000 (e5833000)
 <0>Kernel panic - not syncing: Attempted to kill init!

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=da2c12a279ae225f3d4696f76cb3b32a5bec5bfb

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Sun, Dec 17, 2006 at 11:02:10PM +0200, Riku Voipio wrote:

> > > bah. 2.6.20-git shows nothing (with or without Lennert's patch) after
> > > the following:
>  
> > > Uncompressing Linux..........................................................................................done, booting the kernel.
> > 
> > Try the printascii()-in-printk() hack in my svn tree.
> 
> Thanks, that was priceless advice. I reverted 
> da2c12a279ae225f3d4696f76cb3b32a5bec5bfb "[ARM] Clean up ioremap code"
> and n2100 booted fine.

Can you try with da2c12a279ae225f3d4696f76cb3b32a5bec5bfb with the
following patch applied?

	http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4030/1


> I can now confirm Lennerts patch makes r8169 work without any module
> parameter work on Thecus n2100.

Yay.  Aunt Tillie will be so happy.

Francois, if you submit the r8169.c half of that patch, I'll do my half.

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Riku Voipio]

On Sun, Dec 17, 2006 at 10:13:13PM +0100, Lennert Buytenhek wrote:
> On Sun, Dec 17, 2006 at 11:02:10PM +0200, Riku Voipio wrote:
> 
> > > > bah. 2.6.20-git shows nothing (with or without Lennert's patch) after
> > > > the following:
> >  
> > > > Uncompressing Linux..........................................................................................done, booting the kernel.
> > > 
> > > Try the printascii()-in-printk() hack in my svn tree.
> > 
> > Thanks, that was priceless advice. I reverted 
> > da2c12a279ae225f3d4696f76cb3b32a5bec5bfb "[ARM] Clean up ioremap code"
> > and n2100 booted fine.
 
> Can you try with da2c12a279ae225f3d4696f76cb3b32a5bec5bfb with the
> following patch applied?
 
> 	http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4030/1

Boots fine. 

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> Francois, if you submit the r8169.c half of that patch, I'll do my half.

Ok, I'll do it now.

-- 
Ueimor

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Martin Michlmayr]

* Francois Romieu <romieu@fr.zoreil.com> [2006-12-17 22:48]:
> > Francois, if you submit the r8169.c half of that patch, I'll do my half.
> Ok, I'll do it now.

Thanks to everyone who was involved in coming up with this elegant
solution!
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <buytenh@wantstofly.org> :
[...]
> No, that wouldn't make sense, that's like making a workaround depend on
> arch == i386.
> 
> I'm thinking that we should somehow enable this option on the n2100
> built-in r8169 ports by default only.  Since the n2100 also has a mini-PCI
> slot, and it is in theory possible to put an r8169 on a mini-PCI card,
> the workaround probably shouldn't apply to those, so testing for
> CONFIG_MACH_N2100 also isn't the right thing to do.

Ok, I thought it was a useability thing.

Let aside a few configurations, the sensible default value for this
option is not clear. I have no objection against a patch but it seems
a bit academic as long as nobody complains (you can call me lazy too).

-- 
Ueimor

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Lennert Buytenhek]

On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote:

> > No, that wouldn't make sense, that's like making a workaround depend on
> > arch == i386.
> > 
> > I'm thinking that we should somehow enable this option on the n2100
> > built-in r8169 ports by default only.  Since the n2100 also has a mini-PCI
> > slot, and it is in theory possible to put an r8169 on a mini-PCI card,
> > the workaround probably shouldn't apply to those, so testing for
> > CONFIG_MACH_N2100 also isn't the right thing to do.
> 
> Ok, I thought it was a useability thing.

It is.


> Let aside a few configurations, the sensible default value for this
> option is not clear. I have no objection against a patch but it seems
> a bit academic as long as nobody complains (you can call me lazy too).

I'm thinking that the entire option is just wrong.  It sucks for
distributors to have to make the choice between having it always on
and having it always off.  It sucks for end users compiling their
own kernels, because their ethernet won't work out of the box, and
they will have no idea what's wrong and what to do.

Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))

[Francois Romieu]

Lennert Buytenhek <buytenh@wantstofly.org> :
> On Sat, Dec 16, 2006 at 01:54:39AM +0100, Francois Romieu wrote:
[...]
> I'm thinking that the entire option is just wrong.  It sucks for
> distributors to have to make the choice between having it always on
> and having it always off.  It sucks for end users compiling their
> own kernels, because their ethernet won't work out of the box, and
> they will have no idea what's wrong and what to do.

I would have hoped that it was distributors's job to figure the details
of the configuration at run time from userspace when their package manager
updates the kernel. From there they can set whatever runtime option is
necessary in the configuration file of the modutils package.

However you are right that users may get screwed when they compile their
own kernel though. What about something like the patch below:

Date: Sat, 16 Dec 2006 22:36:06 +0100
Subject: [PATCH] r8169: Aunt Tillie got a Thecus N2100 for Xmas

She compiles kernel again. If only she had been offered an Internet
connexion and an introductory guide to Google too...

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
 drivers/net/Kconfig |   11 +++++++++++
 drivers/net/r8169.c |    4 ++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9de0eed..57432d9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2085,6 +2085,17 @@ config R8169_VLAN
 	  
 	  If in doubt, say Y.
 
+config R8169_SYSERR_DISABLE
+	bool "Disable reporting of the PCI SysErr"
+	depends on R8169 && ARCH_IOP32X
+	---help---
+	  Without this option, the driver reports a lot of PCI SysErr and
+	  is completely unusable with the Thecus N2100. As an alternate
+	  solution, you can use the 'ignore_parity_err' parameter of the
+	  r8169 module to cure the problem at runtime.
+
+	  If in doubt, say N.
+
 config SIS190
 	tristate "SiS190/SiS191 gigabit ethernet support"
 	depends on PCI
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index f83b41d..5e4149e 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -225,7 +225,11 @@ MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl
 
 static int rx_copybreak = 200;
 static int use_dac;
+#ifdef CONFIG_R8169_SYSERR_DISABLE
+static int ignore_parity_err = 1;
+#else
 static int ignore_parity_err;
+#endif
 static struct {
 	u32 msg_enable;
 } debug = { -1 };
-- 
1.4.4.1