On Thu, Sep 27, 2007 at 12:33:42PM +0200, Josip Rodin wrote:
In any case, I let it run some more, and then when it went more or less
dead, I tried to press the said key combination on the keyboard - to no
avail. Break+p would be Ctrl+Pause+p? Didn't work, and Alt+Pause+p also
didn't work. What
BREAK is an RS-232 signal that you'd send over the serial console.
Right, but sending a break via serial console to a sparc is the same as
pressing stop+a - it'll return you to the OBP's prompt. Walking to the
keyboard to press alt+stop+p is is a bit annoying if the machine is not
next to you.
On Sun, Sep 30, 2007 at 03:03:07PM +0200, Bernd Zeimetz wrote:
Right, but sending a break via serial console to a sparc is the same as
pressing stop+a - it'll return you to the OBP's prompt. Walking to the
keyboard to press alt+stop+p is is a bit annoying if the machine is not
next to you.
If
On Mon, Sep 24, 2007 at 09:57:23PM +0200, Josip Rodin wrote:
kernel which works well - at least on out US III machine. We've applied
179c85ea53bef807621f335767e41e23f86f01df to make sure that the system
doesn't create unkillable processes anymore if you use the libc6 from
_lenny_.
didn't work. What was even more annoying was the fact that Stop+a got me
the PROM shell, but I wasn't able to type anything in it (including 'go'),
so that effectively freezes the machine.
Same thing here, if I managed to get the ok prompt at all, I was not
able to enter anything.
:(
--
On Wed, Sep 19, 2007 at 12:10:26AM +0200, Josip Rodin wrote:
kernel which works well - at least on out US III machine. We've applied
179c85ea53bef807621f335767e41e23f86f01df to make sure that the system
doesn't create unkillable processes anymore if you use the libc6 from
_lenny_.
BTW,
Josip Rodin wrote:
On Wed, Sep 19, 2007 at 12:10:26AM +0200, Josip Rodin wrote:
kernel which works well - at least on out US III machine. We've applied
179c85ea53bef807621f335767e41e23f86f01df to make sure that the system
doesn't create unkillable processes anymore if you use the libc6 from
On Mon, Sep 24, 2007 at 09:53:44PM +0200, Bernd Zeimetz wrote:
kernel which works well - at least on out US III machine. We've applied
179c85ea53bef807621f335767e41e23f86f01df to make sure that the system
doesn't create unkillable processes anymore if you use the libc6 from
_lenny_.
BTW,
I'm not sure if those problems are related :) The register dumps would
be needed if the kernel fails to initialize the CPU
Fabio told me that break+p output might be useful in this case too,
I'm just repeating :)
Does Fabio probably know how to send that via a serial connection? :)
--
Bernd Zeimetz a écrit :
I'm not sure if those problems are related :) The register dumps would
be needed if the kernel fails to initialize the CPU
Fabio told me that break+p output might be useful in this case too,
I'm just repeating :)
Does Fabio probably know how to send that via a serial
BTW, lebrun.d.o, also an USIII, running 2.6.23-rc6 plus the aforementioned
patch still created unkillable dpkg-query processes.
I've given 2.6.23-rc6-git7 a try now, which includes
6553daeafb4fa15cd07088f543352fa3779e86e1 - but no luck. This time ssh
processes keep stuck while logging out.
:(
On Tue, Sep 18, 2007 at 11:40:19PM +0200, Bernd Zeimetz wrote:
kernel which works well - at least on out US III machine. We've applied
179c85ea53bef807621f335767e41e23f86f01df to make sure that the system
doesn't create unkillable processes anymore if you use the libc6 from
_lenny_. Please
BTW, lebrun.d.o, also an USIII, running 2.6.23-rc6 plus the aforementioned
patch still created unkillable dpkg-query processes.
Thanks for the hint, saves me the work to give it a try. Building seems
to work on US II CPUs, though, and aptitude doesn't crash as described
below:
Outside of the
13 matches
Mail list logo
