linux-mips
[Top] [All Lists]

Re: AU1550 Kernel bug detected[#1] clockevents_register_device

To: Frank Neuber <frank.neuber@kernelport.de>
Subject: Re: AU1550 Kernel bug detected[#1] clockevents_register_device
From: Manuel Lauss <mano@roarinelk.homelinux.net>
Date: Wed, 28 Jan 2009 10:38:46 +0100
Cc: Florian Fainelli <florian@openwrt.org>, Linux-MIPS <linux-mips@linux-mips.org>
In-reply-to: <1233134374.28527.524.camel@t60p>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1233045842.28527.459.camel@t60p> <20090127091107.GA15890@roarinelk.homelinux.net> <1233051181.28527.485.camel@t60p> <20090127121123.GA17132@roarinelk.homelinux.net> <1233060160.28527.497.camel@t60p> <1233134374.28527.524.camel@t60p>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.16 (2007-06-09)
On Wed, Jan 28, 2009 at 10:19:34AM +0100, Frank Neuber wrote:
> 
> 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


Do hou have CONFIG_64BIT_PHYS_ADDR=y set in your .config?  If I remember
correctly, __fixup_bigphys_addr() in alchemy/common/setup.c should take care
of this 36bit problem (in the same way you did, btw).

Best regards,
        Manuel Lauss

<Prev in Thread] Current Thread [Next in Thread>