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.
> 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 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. W
> 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 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
>
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 co
>> 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? :)
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
> >>>
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 libc
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, 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.
:
> 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 th
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
13 matches
Mail list logo
