Re[2]: mal_probe crash

2009-01-13 Thread Geert Uytterhoeven
wn broken under recent Linux kernels? > >> I've > >> never used them before... > > > Hrm, something is indeed wrong, hard to say what tho. My canyonlands > > works fine (460EPx) and I can try a Taishan one of these days (440GX > > iirc). What is in sequ

Re: Re[2]: mal_probe crash

2009-01-12 Thread Benjamin Herrenschmidt
ts on the Sequoia known broken under recent Linux kernels? > >> I've > >> never used them before... > > > Hrm, something is indeed wrong, hard to say what tho. My canyonlands > > works fine (460EPx) and I can try a Taish

Re[2]: mal_probe crash

2009-01-12 Thread Yuri Tikhonov
lands > works fine (460EPx) and I can try a Taishan one of these days (440GX > iirc). What is in sequoia ? I think it's a GX no ? Sequoia is equipped with 440EPx. I observe the 'mal_probe' crash on the Katmai board too (based on 440SPe): PPC 4xx OCP EMAC driver, version 3.5

Re: mal_probe crash

2009-01-12 Thread Josh Boyer
On Tue, Jan 13, 2009 at 08:36:32AM +1100, Benjamin Herrenschmidt wrote: >On Mon, 2009-01-12 at 14:37 +0100, Geert Uytterhoeven wrote: >> On Fri, 9 Jan 2009, Roland Dreier wrote: >> > > Can you double check that the e1000 isn't copying the PCI resources into >> > > a unsigned long before ioremap'i

Re: mal_probe crash

2009-01-12 Thread Benjamin Herrenschmidt
On Mon, 2009-01-12 at 14:37 +0100, Geert Uytterhoeven wrote: > On Fri, 9 Jan 2009, Roland Dreier wrote: > > > Can you double check that the e1000 isn't copying the PCI resources into > > > a unsigned long before ioremap'ing the result, thus cropping the top > > > bits ? > > > > as far as I can

Re: mal_probe crash

2009-01-12 Thread Geert Uytterhoeven
On Fri, 9 Jan 2009, Roland Dreier wrote: > > Can you double check that the e1000 isn't copying the PCI resources into > > a unsigned long before ioremap'ing the result, thus cropping the top > > bits ? > > as far as I can see, e1000 is using pci_ioremap_bar(), which should do > the right thing

Re: mal_probe crash

2009-01-09 Thread Benjamin Herrenschmidt
On Sat, 2009-01-10 at 09:34 +1100, Herbert Xu wrote: > On Fri, Jan 09, 2009 at 03:42:25PM +0100, Geert Uytterhoeven wrote: > > On Thu, 8 Jan 2009, Benjamin Herrenschmidt wrote: > > > > > There isn't that I know of. The EMAC code creates a single NAPI instance > > > for all EMACs and I think used to

Re: mal_probe crash

2009-01-09 Thread Herbert Xu
On Fri, Jan 09, 2009 at 03:42:25PM +0100, Geert Uytterhoeven wrote: > On Thu, 8 Jan 2009, Benjamin Herrenschmidt wrote: > > > There isn't that I know of. The EMAC code creates a single NAPI instance > > for all EMACs and I think used to completely disconnect things. The old > > code created a fake

Re: mal_probe crash

2009-01-09 Thread Roland Dreier
> Can you double check that the e1000 isn't copying the PCI resources into > a unsigned long before ioremap'ing the result, thus cropping the top > bits ? as far as I can see, e1000 is using pci_ioremap_bar(), which should do the right thing as long as resource_size_t is the right type (which i

Re: mal_probe crash

2009-01-09 Thread Benjamin Herrenschmidt
On Fri, 2009-01-09 at 16:24 +0100, Geert Uytterhoeven wrote: > On Fri, 9 Jan 2009, Matthias Fuchs wrote: > > Forget my last posting! It's just a dirty work around when having a single > > EMAC. > > It does not work with two EMACs like on sequoia. > > Indeed. It doesn't on my sequoia :-( > > I al

Re: mal_probe crash

2009-01-09 Thread Benjamin Herrenschmidt
> Could it be that simple. Probably not. It works at a first glace on > a 405EP ang GPr board. But it might cause problems when having more than > one EMAC up at the same time. I talked with the network folks and that should be ok. We only need to be a bit careful in case for some reason the EM

Re: mal_probe crash

2009-01-09 Thread Geert Uytterhoeven
On Fri, 9 Jan 2009, Matthias Fuchs wrote: > Forget my last posting! It's just a dirty work around when having a single > EMAC. > It does not work with two EMACs like on sequoia. Indeed. It doesn't on my sequoia :-( I also tried reviving connectivity by adding an Intel PRO/1000 GT network card, b

Re: mal_probe crash

2009-01-09 Thread Matthias Fuchs
Forget my last posting! It's just a dirty work around when having a single EMAC. It does not work with two EMACs like on sequoia. Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: mal_probe crash

2009-01-09 Thread Matthias Fuchs
On Wednesday 07 January 2009 23:50, Benjamin Herrenschmidt wrote: > On Thu, 2009-01-08 at 15:46 -0500, Josh Boyer wrote: > > On Wed, Jan 07, 2009 at 03:44:34PM -0500, Sean MacLennan wrote: > > >With Linus' latest git, mal_probe crashes. It calls netif_napi_add with > > >the first parameter NULL. Th

Re: mal_probe crash

2009-01-09 Thread Geert Uytterhoeven
On Thu, 8 Jan 2009, Benjamin Herrenschmidt wrote: > On Thu, 2009-01-08 at 15:46 -0500, Josh Boyer wrote: > > On Wed, Jan 07, 2009 at 03:44:34PM -0500, Sean MacLennan wrote: > > >With Linus' latest git, mal_probe crashes. It calls netif_napi_add with > > >the first parameter NULL. This was ok since

Re: mal_probe crash

2009-01-07 Thread Benjamin Herrenschmidt
On Thu, 2009-01-08 at 15:46 -0500, Josh Boyer wrote: > On Wed, Jan 07, 2009 at 03:44:34PM -0500, Sean MacLennan wrote: > >With Linus' latest git, mal_probe crashes. It calls netif_napi_add with > >the first parameter NULL. This was ok since the parameter, a net > >device, was only used if CONFIG_NE

Re: mal_probe crash

2009-01-07 Thread Josh Boyer
On Wed, Jan 07, 2009 at 03:44:34PM -0500, Sean MacLennan wrote: >With Linus' latest git, mal_probe crashes. It calls netif_napi_add with >the first parameter NULL. This was ok since the parameter, a net >device, was only used if CONFIG_NETPOLL was set. > >Now it is always de-referenced. A quick che

mal_probe crash

2009-01-07 Thread Sean MacLennan
With Linus' latest git, mal_probe crashes. It calls netif_napi_add with the first parameter NULL. This was ok since the parameter, a net device, was only used if CONFIG_NETPOLL was set. Now it is always de-referenced. A quick check shows that ibm_newemac is the only driver that passed NULL as the