Hi all,
I have a strange problem with a Geode/GX1 200Mhz based system. My
kernel is compiled with 586 as processor type but the system stops just
after the 'Uncompressing Linux...Ok, booting the kernel' message. It's
strange as GX1 is claimed to work fine with 2.4.18. The same system
works fine with 2.2.18 kernel.
Is there any new patch to test? Any idea?
Thx a lot by advance.
--
Pierre FICHEUX -/- CTO OpenWide, France -\- [email protected]
http://www.ficheux.com
http://www.emulateur-xtel.org
More fun, more freedom, less Micro$oft
> I have a strange problem with a Geode/GX1 200Mhz based system. My
> kernel is compiled with 586 as processor type but the system stops just
> after the 'Uncompressing Linux...Ok, booting the kernel' message. It's
> strange as GX1 is claimed to work fine with 2.4.18. The same system
> works fine with 2.2.18 kernel.
With 586 and no TSC set it should work fine yes. You might want to plug a
serial port in and compile with serial console enabled, see if it gives any
clues
Alan Cox wrote:
>
> > I have a strange problem with a Geode/GX1 200Mhz based system. My
> > kernel is compiled with 586 as processor type but the system stops just
> > after the 'Uncompressing Linux...Ok, booting the kernel' message. It's
> > strange as GX1 is claimed to work fine with 2.4.18. The same system
> > works fine with 2.2.18 kernel.
>
> With 586 and no TSC set it should work fine yes. You might want to plug a
> serial port in and compile with serial console enabled, see if it gives any
> clues
I want to translate this to:
Processor -> 586/K5/5x86/6x86/6x86MX
right?
On Mon, 8 Apr 2002, Peter W?chtler wrote:
> I want to translate this to:
>
> Processor -> 586/K5/5x86/6x86/6x86MX
>
> right?
Or you can boot with kernel parameter notsc which should have the effect.
Zwane
--
http://function.linuxpower.ca
Peter W?chtler wrote:
> I want to translate this to:
>
> Processor -> 586/K5/5x86/6x86/6x86MX
>
> right?
That's right, have tried with 486 too but I got the same problem.
--
Pierre FICHEUX -/- CTO OpenWide, France -\- [email protected]
http://www.ficheux.com
http://www.emulateur-xtel.org
More fun, more freedom, less Micro$oft
On Mon, 8 Apr 2002, Zwane Mwaikambo wrote:
>Or you can boot with kernel parameter notsc which should have the effect.
One might think that, but it isn't true. That'll just stop the kernel from
halting immediately when it doesn't find any tsc capability. The system
still locks up -- maybe some other parts of the kernel tries to use tsc?
I never looked into it as compiling the kernel correctly (sans tsc) works
just fine.
On a side note, has anyone seen dd scrolling behavior with video chipse
using shared memory? On the geode board I'm playing with, the screen
never scrolls correctly. It's probablly something stupid in the 5530's
setup that's at fault. (I have ever intention of turning the VGA port
off entirely.)
--Ricky
> On a side note, has anyone seen dd scrolling behavior with video chipse
> using shared memory? On the geode board I'm playing with, the screen
> never scrolls correctly. It's probablly something stupid in the 5530's
> setup that's at fault. (I have ever intention of turning the VGA port
> off entirely.)
My 5530 works fine in VESA mode
Ricky Beam <[email protected]> wrote:
> On a side note, has anyone seen dd scrolling behavior with video chipse
> using shared memory? On the geode board I'm playing with, the screen
> never scrolls correctly. It's probablly something stupid in the 5530's
> setup that's at fault. (I have ever intention of turning the VGA port
> off entirely.)
The VSA CGA/EGA/VGA text emulation seems to be rather awful and has
lots of bugs. Compile in the VESA framebuffer support in your Linux
kernel and add vga=785 (see linux/Documentation/fb/vesafb.txt) to
your kernel command line. It's a choice of:
Linux kernel frobs the text console -> buggy VSA emulation -> framebuffer
or
Linux kernel frobs the framebuffer directly
Guess which works better? *grin*
/Christer
--
"Just how much can I get away with and still go to heaven?"