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.
Riku Voipio <[email protected]> :
[...]
> 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
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?
Lennert Buytenhek <[email protected]> :
[...]
> 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
* Francois Romieu <[email protected]> [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/
Martin Michlmayr <[email protected]> :
[...]
> 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
Francois Romieu <[email protected]> :
[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
* Francois Romieu <[email protected]> [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/
Martin Michlmayr <[email protected]> :
[...]
> 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
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..?
Lennert Buytenhek <[email protected]> :
[...]
> 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
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.
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:
Lennert Buytenhek <[email protected]> :
[...]
> 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
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.
Lennert Buytenhek <[email protected]> :
> 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 <[email protected]>
---
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
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;
}
Lennert Buytenhek <[email protected]> :
[...]
> Sounds good. How about something like the patch below plus the
> corresponding r8169 diff?
Go wild.
--
Ueimor
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;
* Lennert Buytenhek <[email protected]> [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/
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.
Lennert Buytenhek <[email protected]> :
[...]
> Francois, if you submit the r8169.c half of that patch, I'll do my half.
Ok, I'll do it now.
--
Ueimor
* Francois Romieu <[email protected]> [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/
> > 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 [email protected]).
<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
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.