mpc83xx_restart() buggy

mpc83xx_restart() buggy

[Tjernlund]

mpc83xx_restart() uses ioremap(), which doesn't like
beeing called while in IRQ context. 

Calling mpc83xx_restart() in IRQ context yields OOPS
which calls mpc83xx_restart() again and the loop never
termintes.

 Jocke 

Re: mpc83xx_restart() buggy

[Kumar Gala]

On Dec 27, 2006, at 6:45 PM, Tjernlund wrote:

> mpc83xx_restart() uses ioremap(), which doesn't like
> beeing called while in IRQ context.
>
> Calling mpc83xx_restart() in IRQ context yields OOPS
> which calls mpc83xx_restart() again and the loop never
> termintes.

This is interesting, I know I've seen restart work properly w/o an  
oops.  How are you causing the restart?

- k

Re: mpc83xx_restart() buggy

[Scott Wood]

Kumar Gala wrote:
> On Dec 27, 2006, at 6:45 PM, Tjernlund wrote:
>>mpc83xx_restart() uses ioremap(), which doesn't like
>>beeing called while in IRQ context.
>>
>>Calling mpc83xx_restart() in IRQ context yields OOPS
>>which calls mpc83xx_restart() again and the loop never
>>termintes.
> 
> This is interesting, I know I've seen restart work properly w/o an  
> oops.  How are you causing the restart?

sysrq-b triggers it, as probably does crashing from an interrupt handler 
with panic_timeout nonzero.  You'll need CONFIG_DEBUG_SPINLOCK_SLEEP 
turned on, of course.

-Scott

RE: mpc83xx_restart() buggy

[Joakim Tjernlund]

> -----Original Message-----
> From: 
> linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org 
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> abs.org] On Behalf Of Scott Wood
> Sent: den 30 december 2006 00:04
> To: Kumar Gala
> Cc: Tjernlund; 'linuxppc-dev'
> Subject: Re: mpc83xx_restart() buggy
> 
> Kumar Gala wrote:
> > On Dec 27, 2006, at 6:45 PM, Tjernlund wrote:
> >>mpc83xx_restart() uses ioremap(), which doesn't like
> >>beeing called while in IRQ context.
> >>
> >>Calling mpc83xx_restart() in IRQ context yields OOPS
> >>which calls mpc83xx_restart() again and the loop never
> >>termintes.
> > 
> > This is interesting, I know I've seen restart work properly w/o an  
> > oops.  How are you causing the restart?
> 
> sysrq-b triggers it, as probably does crashing from an 
> interrupt handler 
> with panic_timeout nonzero.  You'll need CONFIG_DEBUG_SPINLOCK_SLEEP 
> turned on, of course.

For me it was http://ozlabs.org/pipermail/linuxppc-dev/2006-December/029414.html

ucc_geth_timeout() is buggy and so is ucc_geth_start_xmit(), needs to 
return NETDEV_TX_BUSY or NETDEV_TX_OK.

 Jocke

RE: mpc83xx_restart() buggy

[Joakim Tjernlund]

> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@ozl
> abs.org] On Behalf Of Scott Wood
> Sent: 30 December 2006 00:04
> To: Kumar Gala
> Cc: Tjernlund; 'linuxppc-dev'
> Subject: Re: mpc83xx_restart() buggy
>=20
> Kumar Gala wrote:
> > On Dec 27, 2006, at 6:45 PM, Tjernlund wrote:
> >>mpc83xx_restart() uses ioremap(), which doesn't like
> >>beeing called while in IRQ context.
> >>
> >>Calling mpc83xx_restart() in IRQ context yields OOPS
> >>which calls mpc83xx_restart() again and the loop never
> >>termintes.
> >=20
> > This is interesting, I know I've seen restart work properly w/o an =20
> > oops.  How are you causing the restart?
>=20
> sysrq-b triggers it, as probably does crashing from an=20
> interrupt handler=20
> with panic_timeout nonzero.  You'll need CONFIG_DEBUG_SPINLOCK_SLEEP=20
> turned on, of course.
>=20
> -Scott

Any chance for a fix soon?

 Jocke