I am wondering if any of the developers who do kernel
related work on LinuxPPC have any suggestions for us
on how to deal with this. If I knew how to do the
debugging work and trace the problem to its root I
would.
--- Bernhard Reiter <bernhard@intevation.de> wrote:
On Tue, May 02, 2000 at 01:22:21PM +0200, Albrecht
Dress wrote:
quoted
quoted
my problems with the hard freezes still
continue.
quoted
quoted
I have not come to any idea what is causing it.
Several methods of trying to encircle the
problem area failed.
quoted
Sorry, I am afraid I lost some messages of this
thread. Hope this is not
quoted
too outdated ;-)
You can look it up in the webarchive.
http://lists.linuxppc.org/listarcs/linuxppc-dev/200004/threads.html
quoted
I _have_ a Lombard running without problems. So
just some ideas which
quoted
might give you some more information. Maybe you
should try to work from
quoted
the first virtual (text) console (ctrl-opt-F1).
If the kernel panics
quoted
(which is does very likely) it will emit this
information there, but you
quoted
will NEVER see it if you are in X, and it does not
necessarily go into
quoted
/var/log/messages.
The hard freeze's low temperature prohibits all
output.
Never got any error message.
quoted
Did you check the serial port drivers? I rember
there were some problems
quoted
if you use the serial.c under LinuxPPC. You do
not need it, the right one
quoted
is macserial.c. I could trigger panics on the
Lombard and on my old 7300
quoted
by just typing "cat /dev/ttyS0 > /dev/null".
Yes I check the serial driver, built a kernel
without usb and
serial support at all. But the symptoms are still
there.
I have 192 MB of RAM though and a 10 Gb drive ,
these are the only
differences which I think my machine might have to
other lombards.
Bernhard
--
Professional Service around Free Software
(intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure
(ffii.org)
ATTACHMENT part 2 application/pgp-signature
=====
Gabriel Ricard
g_ricard@yahoo.com
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I am wondering if any of the developers who do kernel
related work on LinuxPPC have any suggestions for us
on how to deal with this. If I knew how to do the
debugging work and trace the problem to its root I
would.
It's a bit tough to debug kernel stuff on a machine like the Lombard if it
has no serial port to attach a console terminal or even a kernel debugger
to. It's even harder to remote debug such a machine over a mailing list
:-)
There's a few things that can be tried though. You can use the modem port
as serial console if you hook it up to another modem, and make the two
modems connect (ata on the one, atd on the other). On the Lombard,
console=ttyS0 in the kernel options at boot plus actually initiating the
connection from a shell with cu or minicom is all it takes for that. Once
the kernel is logging to the modem port, try to force a freeze and check
for messages on the connected system. If I remember right, xmon will
accept input via the serial console port in this situation so you can go
aboout poking around after a panic threw you into xmon. I'm not familiar
with xmon, but the modem-connected serial console helped me track down the
XFree 4.0 Mach64 problems just by looking at the panic logs.
If the kernel just hangs without producing any panic messages, this method
won't work though.
A maybe more sophisticated way to debug in that case would be to use kgdb
instead of xmon, and enter the kernel-side debugger stub when the system
appears frozen. This requires the remote machine to run gdb with support
for the PPC binfmt, as well as working serial interrupts on the machine
being debugged. If the kernel just deadlocked somewhere with interrupts
still enabled, this should work (but so should timeouts, keyboard and the
like). Otherwise, you're out of luck. I should add that I haven't been
forced to resort to kgdb so far ...
I haven't seen the result of one of the suggestions here to stay in the
text consoles instead of X. This experiment should tell about the state of
interrupts when the system freezes. One thing I notices that makes the
Lombard in question different from mine (which hasn't frozen on me in
ages despite extensive number crunching and compiling) is that it's got a
lot more RAM (64M here only) and a bigger disk (6GB here). Both combined
might account for higher power consumption, higher heat dissipation, you
name it. Batmon should tell just how much more power is drawn by that
configuration.
Just a few ideas. From the problem descriptions, I have no idea what part
of kernel or hardware to blame. The kernel needs to get caught in the act
now ...
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Michael Schmitz wrote:
quoted
I am wondering if any of the developers who do kernel
related work on LinuxPPC have any suggestions for us
on how to deal with this. If I knew how to do the
debugging work and trace the problem to its root I
would.
It's a bit tough to debug kernel stuff on a machine like the Lombard if it
has no serial port to attach a console terminal or even a kernel debugger
to. It's even harder to remote debug such a machine over a mailing list
:-)
Indeed ;-)
Here's my setup: Lombard with 6GB HD and 64MB RAM (just like yours
I guess); my probs started with USB support compiled in the kernel:
even if it does not lead to a total freeze so often (would say very
seldom indeed), I still get mouse freeze under X when heavy network
activity is being made (last time 5 mins ago getting a big attachment).
Some other times I get a kernel panic during the boot when initializing
the serial interfaces (no, I have NOT support for standard serial
but only MAC serial compiled into the kernel).
This is why I was thinking about some USB/serial code problem but I
agree we need some debug output to work on.
Using Debian 2.2 and XF86_FBDev with kernel 2.2.15pre20 from Paul's
tree.
Thinking about the debug way you suggest, it comes to my mind another
question not so related to the prob: is there a USB->serial converter
around ? Is there one of this devices supported by Linux ? On PPC ?
Ciao,
--
Mario Scarpa
Mondonet NOC
Phone: +39 06 52.47.37.02
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/