Parsing ELF ... Done <REBOOT> (lenny 2.6.26-1-486)
in [UK Linux]
|
From: Mark Hobley on 24 Nov 2008 08:08 Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote: > I don't know specifically where the problem lies, but I believe that the > problem is due to invalid instructions appearing in the compiled kernel. I am guessing that there might be a cpuid instruction or a p6_nop5 sequence causing this. For a 486 build arch neither of these should be used. Mark. -- Mark Hobley Linux User: #370818 http://markhobley.yi.org/
From: Robert Harris on 24 Nov 2008 11:00 Mark Hobley wrote: > Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote: > >> I don't know specifically where the problem lies, but I believe that the >> problem is due to invalid instructions appearing in the compiled kernel. > > I am guessing that there might be a cpuid instruction or a p6_nop5 sequence > causing this. For a 486 build arch neither of these should be used. > > Mark. > I doubt if there really is anything like that wrong with the stock 486 kernel; the problem is more likely to be either faulty RAM or esoteric boot disk hardware which doesn't locate the disk. It is also possible that the boot disk has migrated from, say, hda to sda through using different drivers, in which case appending "root=/dev/sda1" to the boot options may help. Robert
From: Tim Woodall on 24 Nov 2008 16:40 On Mon, 24 Nov 2008 16:00:25 +0000, Robert Harris <robert.f.harris(a)blueyonder.co.uk> wrote: > Mark Hobley wrote: >> Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote: >> >>> I don't know specifically where the problem lies, but I believe that the >>> problem is due to invalid instructions appearing in the compiled kernel. >> >> I am guessing that there might be a cpuid instruction or a p6_nop5 sequence >> causing this. For a 486 build arch neither of these should be used. >> >> Mark. >> > I doubt if there really is anything like that wrong with the stock 486 > kernel; the problem is more likely to be either faulty RAM or esoteric > boot disk hardware which doesn't locate the disk. It is also possible > that the boot disk has migrated from, say, hda to sda through using > different drivers, in which case appending "root=/dev/sda1" to the boot > options may help. > One of the bug reports I found suggested it was related to a change to the code detecting one of the clocks (that doesn't exist on the 486). Tim. -- God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t," and there was light. http://www.woodall.me.uk/
From: Nix on 25 Nov 2008 18:55
On 24 Nov 2008, Robert Harris verbalised: > Mark Hobley wrote: >> Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote: >> >>> I don't know specifically where the problem lies, but I believe that the problem is due to invalid instructions appearing in the >>> compiled kernel. >> I am guessing that there might be a cpuid instruction or a p6_nop5 sequence >> causing this. For a 486 build arch neither of these should be used. >> Mark. >> > I doubt if there really is anything like that wrong with the stock 486 > kernel There have been exactly such bugs (relating to p6 nop sequences and the alternatives system) in the past, so I'd not be surprised if this was one of those come again. -- `Not even vi uses vi key bindings for its command line.' --- PdS |