m8xx hang in reboot

m8xx hang in reboot

[Mark S. Mathews]

Hey Folks,

I've got an mpc850 based setup running 2.4.27 that, under certain
circumstances, hangs in the the m8xx_restart() function (instead of
rebooting) when I issue the usermode reboot cmd.

I've traced all through the path and confirmed that yes, it is hanging in
this function.  ;-)

I'm still looking over the databook and what this code does.  Just figured
I'd ask around and see if anyone else has seen this behavior.

Thanks,
-Mark

--

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
721-D North Drive          e-mail: mark@linux-wlan.com
Melbourne, FL 32934        Phone:  321.259.0737
USA                        Fax:    321.259.0286

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: m8xx hang in reboot

[Dan Malek]

On Aug 25, 2004, at 4:22 PM, Mark S. Mathews wrote:

> I've got an mpc850 based setup running 2.4.27 that, under certain
> circumstances, hangs in the the m8xx_restart() function (instead of
> rebooting) when I issue the usermode reboot cmd.

Hmmmm......

> I've traced all through the path and confirmed that yes, it is hanging
> in
> this function.  ;-)

Does it get as far at the printk that indicates the checkstop failed?

> I'm still looking over the databook and what this code does.  Just
> figured
> I'd ask around and see if anyone else has seen this behavior.

It's supposed to enable a "checkstop" reset, such that on a bad
bus cycle that times out the processor will be reset.  Then, it
forces a bad bus cycle.  Since it works in most cases, I suspect
the problem is outside of the processor.

This type of reset will cause the processor reset, but it will
not reset the rest of the hardware on the board.  It seems there is
something external on the board that must be in a state that
prevents the bus from operating properly.  The processor
resets, but can't fetch code properly.

This reset function is generic to all 8xx processors, in that it
will reset the processor.  Done properly, a system design will
have some external control register that can be written to
reset the entire board, just like a power up or pressing a
reset switch.  Without such complete system reset, this
is the best we can do, but it certainly is not the same as
a full reset.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: m8xx hang in reboot

[Stefan Stürke]

Mark S. Mathews wrote:
>
> Hey Folks,
>
> I've got an mpc850 based setup running 2.4.27 that, under certain
> circumstances, hangs in the the m8xx_restart() function (instead of
> rebooting) when I issue the usermode reboot cmd.
>
> I've traced all through the path and confirmed that yes, it is hanging in
> this function.  ;-)

Maybe you can have a look at your boot flash when you enter the
m8xx_restart() function. I had a similar problem and found that
my boot flash was in read status state in that moment, so it was
impossible to fetch the correct programm code after reset.

HTH,
Stefan

--
PANDATEL AG
Bayernstrasse 33
30855 Langenhagen
Germany

Tel.: +49 (0)511 978199-15
Fax.: +49 (0)511 978199-77
mailto:sst-news2003@pandatel.com
www.pandatel.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[SPAM] Re: m8xx hang in reboot

[Mark S. Mathews]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1678 bytes --]


This is interesting, thanks Stefan.

One item of info that I had left out of the original post (because I
hadn't verified 100% that this was truly part of the issue):
   The "certain circumstances" prior to the reboot failure are:
     1) we've just completed an unlock/erase/write on one of our flash
        partitions.
     2) the wlan device that's attached to the pcmcia interface was
        previously in use.

If the wlan device was not in use or if we don't do the flash
unlock/erase/write, then the reboot works just fine.  Strange combination
of factors.

Thanks Stefan,
-M


On Thu, 26 Aug 2004, Stefan Stürke wrote:

>
> Mark S. Mathews wrote:
>>
>> Hey Folks,
>>
>> I've got an mpc850 based setup running 2.4.27 that, under certain
>> circumstances, hangs in the the m8xx_restart() function (instead of
>> rebooting) when I issue the usermode reboot cmd.
>>
>> I've traced all through the path and confirmed that yes, it is hanging in
>> this function.  ;-)
>
> Maybe you can have a look at your boot flash when you enter the
> m8xx_restart() function. I had a similar problem and found that
> my boot flash was in read status state in that moment, so it was
> impossible to fetch the correct programm code after reset.
>
> HTH,
> Stefan
>
> --
> PANDATEL AG
> Bayernstrasse 33
> 30855 Langenhagen
> Germany
>
> Tel.: +49 (0)511 978199-15
> Fax.: +49 (0)511 978199-77
> mailto:sst-news2003@pandatel.com
> www.pandatel.com
>
>
>
>

--

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
721-D North Drive          e-mail: mark@linux-wlan.com
Melbourne, FL 32934        Phone:  321.259.0737
USA                        Fax:    321.259.0286

Re: m8xx hang in reboot

[Mark S. Mathews]

On Wed, 25 Aug 2004, Dan Malek wrote:

>
> On Aug 25, 2004, at 4:22 PM, Mark S. Mathews wrote:
>
>> I've got an mpc850 based setup running 2.4.27 that, under certain
>> circumstances, hangs in the the m8xx_restart() function (instead of
>> rebooting) when I issue the usermode reboot cmd.
>
> Hmmmm......
>
>> I've traced all through the path and confirmed that yes, it is hanging in
>> this function.  ;-)
>
> Does it get as far at the printk that indicates the checkstop failed?

No it doesn't.  I know that printk would generate output (if we
reached it) because I've added other printks to the function to narrow
down the failure point.   To actually get the output has required that I
temporarily disable the cli() and I have to add delays after each printk
to allow the serial output to complete.  Just stupid debug stuff.


>> I'm still looking over the databook and what this code does.  Just figured
>> I'd ask around and see if anyone else has seen this behavior.
>
> It's supposed to enable a "checkstop" reset, such that on a bad
> bus cycle that times out the processor will be reset.  Then, it
> forces a bad bus cycle.  Since it works in most cases, I suspect
> the problem is outside of the processor.

That code has worked perfectly up til now (this is by no means a new
design).

> This type of reset will cause the processor reset, but it will
> not reset the rest of the hardware on the board.  It seems there is
> something external on the board that must be in a state that
> prevents the bus from operating properly.  The processor
> resets, but can't fetch code properly.

I think you're right.  Your observation and Stefan's post have me thinking
we may have a flash access problem.

> This reset function is generic to all 8xx processors, in that it
> will reset the processor.  Done properly, a system design will
> have some external control register that can be written to
> reset the entire board, just like a power up or pressing a
> reset switch.  Without such complete system reset, this
> is the best we can do, but it certainly is not the same as
> a full reset.

I'll check with the board builder and see if there may be a software
accessible reset chip on the board.

Thanks,
-M

--

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
721-D North Drive          e-mail: mark@linux-wlan.com
Melbourne, FL 32934        Phone:  321.259.0737
USA                        Fax:    321.259.0286

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [SPAM] Re: m8xx hang in reboot

[Gary Thomas]

On Thu, 2004-08-26 at 06:28, Mark S. Mathews wrote:
> This is interesting, thanks Stefan.
>
> One item of info that I had left out of the original post (because I
> hadn't verified 100% that this was truly part of the issue):
>    The "certain circumstances" prior to the reboot failure are:
>      1) we've just completed an unlock/erase/write on one of our flash
>         partitions.
>      2) the wlan device that's attached to the pcmcia interface was
>         previously in use.
>
> If the wlan device was not in use or if we don't do the flash
> unlock/erase/write, then the reboot works just fine.  Strange combination
> of factors.

Do either of those use 'printk()'?  I've seen this failure if the
caches currently hold everything in the printk path - it's actually
the call to printk that causes the bad bus cycles.  Try flushing or
even disabling the caches just before the printk in the reset routine.

Note: I would think that if the problem were the FLASH being in the
wrong mode (suggested by Mark), then the whole thing would freeze,
rather than sitting in the while() loop...

>
> Thanks Stefan,
> -M
>
>
> On Thu, 26 Aug 2004, Stefan Stürke wrote:
>
> >
> > Mark S. Mathews wrote:
> >>
> >> Hey Folks,
> >>
> >> I've got an mpc850 based setup running 2.4.27 that, under certain
> >> circumstances, hangs in the the m8xx_restart() function (instead of
> >> rebooting) when I issue the usermode reboot cmd.
> >>
> >> I've traced all through the path and confirmed that yes, it is hanging in
> >> this function.  ;-)
> >
> > Maybe you can have a look at your boot flash when you enter the
> > m8xx_restart() function. I had a similar problem and found that
> > my boot flash was in read status state in that moment, so it was
> > impossible to fetch the correct programm code after reset.
> >
> > HTH,
> > Stefan
> >
> > --
> > PANDATEL AG
> > Bayernstrasse 33
> > 30855 Langenhagen
> > Germany
> >
> > Tel.: +49 (0)511 978199-15
> > Fax.: +49 (0)511 978199-77
> > mailto:sst-news2003@pandatel.com
> > www.pandatel.com
> >
> >
> >
> >
>
> --
>
> Mark S. Mathews
>
> AbsoluteValue Systems      Web:    http://www.linux-wlan.com
> 721-D North Drive          e-mail: mark@linux-wlan.com
> Melbourne, FL 32934        Phone:  321.259.0737
> USA                        Fax:    321.259.0286
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [SPAM] Re: m8xx hang in reboot

[Dan Malek]

On Aug 26, 2004, at 8:28 AM, Mark S. Mathews wrote:

> One item of info that I had left out of the original post (because I
> hadn't verified 100% that this was truly part of the issue):
>   The "certain circumstances" prior to the reboot failure are:
>     1) we've just completed an unlock/erase/write on one of our flash
>        partitions.

Oh Geeze.....yeah, that could be a problem :-)

>     2) the wlan device that's attached to the pcmcia interface was
>        previously in use.

Can you test these independently to see which is causing the
trouble?  I'm also guessing it's number 1.

> If the wlan device was not in use or if we don't do the flash
> unlock/erase/write, then the reboot works just fine.  Strange
> combination
> of factors.

Both of these make sense.  After you are done writing the flash,
do something to read  it, so it returns to that state.  You may
need to shut down the wlan before rebooting if that is causing
the trouble.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: [SPAM] Re: m8xx hang in reboot

[Mark S. Mathews]

Dan, Stefan, all...

Yup, doing a read via the mtd device after the write to the mtd device
appears to take care of the problem.  Hmmm, is this an mtd bug?  or
perhaps a board specific thing.

Oh well, don't have time to debug the mtd stuff right now so I'll just do
the read-after-write workaround and move on.

My thanks to all for the suggestions and for making me think,
-Mark

BTW Dan: The wlan device does get shutdown (and driver is unloaded) before
          the reboot call.  The wierd thing is that I set up the system in
          a mode where the wlan device is never brought up at all, did the
          flash unlock/erase/write (no read), and issued the reboot...
          it worked just fine.  The reboot failure seems to require that
          the wlan device be operational.  Seems to imply that this problem
          is somehow tied to one or more of: pcmcia hw, wlan device hw,
          pcmcia sw, or wlan sw.  'Tis a quandry.  Perhaps we'll never
          know, I've got other fish to fry now...



On Thu, 26 Aug 2004, Dan Malek wrote:

>
> On Aug 26, 2004, at 8:28 AM, Mark S. Mathews wrote:
>
>> One item of info that I had left out of the original post (because I
>> hadn't verified 100% that this was truly part of the issue):
>>   The "certain circumstances" prior to the reboot failure are:
>>     1) we've just completed an unlock/erase/write on one of our flash
>>        partitions.
>
> Oh Geeze.....yeah, that could be a problem :-)
>
>>     2) the wlan device that's attached to the pcmcia interface was
>>        previously in use.
>
> Can you test these independently to see which is causing the
> trouble?  I'm also guessing it's number 1.
>
>> If the wlan device was not in use or if we don't do the flash
>> unlock/erase/write, then the reboot works just fine.  Strange
>> combination
>> of factors.
>
> Both of these make sense.  After you are done writing the flash,
> do something to read  it, so it returns to that state.  You may
> need to shut down the wlan before rebooting if that is causing
> the trouble.
>
>
> 	-- Dan
>
>
>
>

--

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
721-D North Drive          e-mail: mark@linux-wlan.com
Melbourne, FL 32934        Phone:  321.259.0737
USA                        Fax:    321.259.0286

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/