From: Mark S. Mathews <hidden> Date: 2004-08-25 20:22:00
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/
From: Dan Malek <hidden> Date: 2004-08-26 03:29:00
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/
From: Stefan Stürke <hidden> Date: 2004-08-26 06:40:57
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/
From: Mark S. Mathews <hidden> Date: 2004-08-26 12:28:40
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:
quoted
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
From: Mark S. Mathews <hidden> Date: 2004-08-26 12:42:33
On Wed, 25 Aug 2004, Dan Malek wrote:
On Aug 25, 2004, at 4:22 PM, Mark S. Mathews wrote:
quoted
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......
quoted
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.
quoted
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/
From: Gary Thomas <hidden> Date: 2004-08-26 12:57:41
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:
quoted
Mark S. Mathews wrote:
quoted
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 [off-list ref]
MLB Associates
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2004-08-26 14:23:54
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/
From: Mark S. Mathews <hidden> Date: 2004-08-26 15:34:56
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:
quoted
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 :-)
quoted
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.
quoted
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/