Oops,

I have found the problem:)

The board I am testing with at the moment is one of the sis550 boards which
has the RISE core in it (claimed by RISE marketing to be PII compatible) - I
assumed the kernel config file in the Linuxbios kernel-patched directory for
the 2.4.17 kernel for SiS would work - this is set up for a PII processor
and there is obviously an instruction in the PII not implemented in the RISE
core.

I dropped it down to a 486 for starters, and it works fine.

Thanks for the help

Hamish

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Eric W Biederman
> Sent: 18 July 2002 06:15
> To: [EMAIL PROTECTED]
> Cc: Ronald G Minnich; LinuxBIOS
> Subject: Re: mkelfImage
>
>
> "Hamish Guthrie \(Mail Lists\)" <[EMAIL PROTECTED]> writes:
>
> > Eric,
> >
> > I have a printk immediately after the lines of the patch
> >
> > #if 1
> >     console_drivers = &minimal_serial_console;
> > #endif
> >     printk("setup_arch\n");
> >
> > The serial output I get from the kernel is:
> >
> > setup_arch
> > Unknown interrupt
> > Unknown interrupt
> > ....
> >
> > I have looked at the PIC setup - no change - the IDT is the same...
> >
> > I am not sure where to look next
>
> Because it repeats and interrupts are disabled it is an exception, not
> an interrupt so the PIC should not have an effect.
>
> After that the next thing the kernel does is to initialize the e820
> memory map,  which should have printed.  There is some
> debug code you can enable in convert.c (from mkelfImage) that will
> print this before the kernel loads could you have the kernel print
> that out?
>
> With respect to your kernel, do you have any interesting patches applied,
> and are you certain you are compiling for a 486?  On the off chance
> the problem is that an illegal instruction gets executed.
>
> Excecuting an explicit cli ``asm("cli");''  should guarantee that
> it is an exception and not an interrupt happening.
>
> Something else you can do is instrument unknown interrupt to print
> it's return address so you can see where the code is blowing up.
>
> Eric

Reply via email to