From: Frank Neuber <frank.neuber@kernelport.de>
To: Manuel Lauss <mano@roarinelk.homelinux.net>
Cc: Florian Fainelli <florian@openwrt.org>,
Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: AU1550 Kernel bug detected[#1] clockevents_register_device
Date: Wed, 28 Jan 2009 10:19:34 +0100 [thread overview]
Message-ID: <1233134374.28527.524.camel@t60p> (raw)
In-Reply-To: <1233060160.28527.497.camel@t60p>
Am Dienstag, den 27.01.2009, 13:42 +0100 schrieb Frank Neuber:
> Am Dienstag, den 27.01.2009, 13:11 +0100 schrieb Manuel Lauss:
> > > I think somting is wrong with PCI resource management here.
> > > I can't believe that nobody is using the PCI or Cardbus on the AU1550
> > > with the current kernel.
> >
> > I'm no PCI expert, but I'm pretty sure resource assignment is done by
> > generic, not mips-specific, code. Please try the linux-pci and/or
> > linux-kernel lists.
> At the moment I buld a matrix of working kernel versions regarding the
> PCI stuff on the AU1550
>
> For now I can say that the versions
> 2.6.18, 2.6.18-rc1
> is crashing after showing the linux banner
>
I found the problem for this error. It is because we compare 32 and 64
bit numbers in __request_resource.
> 2.6.18-rc2, 2.6.18-rc4, 2.6.19, 2.6.20, 2.6.23 produce this:
> Skipping PCI bus scan due to resource conflict
I changed this:
diff --git a/include/asm-mips/mach-au1x00/au1000.h
b/include/asm-mips/mach-au1x00/au1000.h
index 3bdce91..8616c09 100644
--- a/include/asm-mips/mach-au1x00/au1000.h
+++ b/include/asm-mips/mach-au1x00/au1000.h
@@ -1679,12 +1679,21 @@ enum soc_au1200_ints {
#define Au1500_PCI_MEM_START 0x440000000ULL
#define Au1500_PCI_MEM_END 0x44FFFFFFFULL
+#if 1
+#define PCI_IO_START 0x00001000
+#define PCI_IO_END 0x000FFFFF
+#define PCI_MEM_START 0x40000000
+#define PCI_MEM_END 0x4FFFFFFF
+#define PCI_FIRST_DEVFN (0 << 3)
+#define PCI_LAST_DEVFN (19 << 3)
+#else
#define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
#define PCI_IO_END (Au1500_PCI_IO_END)
#define PCI_MEM_START (Au1500_PCI_MEM_START)
#define PCI_MEM_END (Au1500_PCI_MEM_END)
#define PCI_FIRST_DEVFN (0<<3)
#define PCI_LAST_DEVFN (19<<3)
+#endif
#define IOPORT_RESOURCE_START 0x00001000 /* skip legacy probing */
#define IOPORT_RESOURCE_END 0xffffffff
Now I think a have to look at 64 problems in the resource management of
th PCI subsystem
>
> The version 2.6.24 has the same behavior as the current git head.
>
> I will inform you about more results
>
> Regards,
> Frank
>
next prev parent reply other threads:[~2009-01-28 9:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-27 8:44 AU1550 Kernel bug detected[#1] clockevents_register_device Frank Neuber
2009-01-27 9:11 ` Manuel Lauss
2009-01-27 9:18 ` Florian Fainelli
2009-01-27 9:23 ` Florian Fainelli
2009-01-27 10:13 ` Frank Neuber
2009-01-27 12:11 ` Manuel Lauss
2009-01-27 12:42 ` Frank Neuber
2009-01-28 9:19 ` Frank Neuber [this message]
2009-01-28 9:38 ` Manuel Lauss
2009-01-28 9:45 ` Manuel Lauss
2009-01-28 10:38 ` Frank Neuber
2009-01-28 10:31 ` Frank Neuber
2009-01-29 21:35 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1233134374.28527.524.camel@t60p \
--to=frank.neuber@kernelport.de \
--cc=florian@openwrt.org \
--cc=linux-mips@linux-mips.org \
--cc=mano@roarinelk.homelinux.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox