linux-kernel - Re: kernel won't boot on a Cyrix MediaGXm (Geode )

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jul 2008 12:51:08 +0200
From:	Juergen Beisert <jbe@...gutronix.de>
To:	linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...e.hu>, Samuel Sieb <samuel@...b.net>,
	"Rafael C. de Almeida" <almeidaraf@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Magnus Damm <magnus@...inux.co.jp>,
	takada <takada@....nifty.com>
Subject: Re: kernel won't boot on a Cyrix MediaGXm (Geode )

On Dienstag, 22. Juli 2008, Ingo Molnar wrote:
> * Samuel Sieb <samuel@...b.net> wrote:
> > Ingo Molnar wrote:
> >> * Rafael C. de Almeida <almeidaraf@...il.com> wrote:
> >>> Samuel Sieb wrote:
> >>>> I have a computer here with a CPU that the BIOS identifies as:
> >>>> Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B
> >>>>
> >>>> I can't boot any kernel later than 2.6.22 on it.  Anything later
> >>>> either hangs or gives random kernel panics while booting.  I tracked
> >>>> down the problem to a specific commit:
> >>>>
> >>>> commit f25f64ed5bd3c2932493681bdfdb483ea707da0a
> >>
> >> does the debug patch below (ontop of v2.6.26 or later kernels) make the
> >> system bootable again? Commit f25f64ed5 changed the meaning of that
> >> line. This patch switches back to the old behavior (which essentially
> >> did nothing, due to macro side-effect bugs).
> >
> > Commenting out this line didn't have any effect that I could see.  I was
> > hoping one way or another it would affect the TSC unstable message I
> > get, but it didn't even change that.
>
> could you try to figure out which particular use of getCx86() or
> setCx86() makes the difference? Here are the suspect nested ones, for
> which the macro->inline change can be material:
>
> $ grep -n 'Cx86.*Cx86' arch/x86/kernel/*/*.c > 1
>
> arch/x86/kernel/cpu/cyrix.c:119:	setCx86(CX86_PCR0, getCx86(CX86_PCR0) &
> ~0x80); arch/x86/kernel/cpu/cyrix.c:130:	setCx86(CX86_CCR2,
> getCx86(CX86_CCR2) & ~0x04);
> arch/x86/kernel/cpu/cyrix.c:134:	setCx86(CX86_CCR2, getCx86(CX86_CCR2) |
> 0x14); arch/x86/kernel/cpu/cyrix.c:147:	setCx86(CX86_PCR1,
> getCx86(CX86_PCR1) | 0x02);
> arch/x86/kernel/cpu/cyrix.c:150:	setCx86(CX86_PCR0, getCx86(CX86_PCR0) |
> 0x04); arch/x86/kernel/cpu/cyrix.c:165:	setCx86(CX86_CCR2,
> getCx86(CX86_CCR2) | 0x88);
> arch/x86/kernel/cpu/cyrix.c:172:	setCx86(CX86_CCR4, getCx86(CX86_CCR4) |
> 0x38); arch/x86/kernel/cpu/cyrix.c:289:			setCx86(CX86_CCR7,
> getCx86(CX86_CCR7) | 1);
> arch/x86/kernel/cpu/cyrix.c:312:			setCx86(CX86_CCR7,
> getCx86(CX86_CCR7)|1);
> arch/x86/kernel/cpu/cyrix.c:427:			setCx86(CX86_CCR4, getCx86(CX86_CCR4) |
> 0x80);  /* enable cpuid  */
>
> i've applied the patch below to tip/master:
>
>    http://people.redhat.com/mingo/tip.git/README
>
> could you check whether it boots your system fine, out of box?

Maybe its something system specific. I'm using several Geode-GX1 systems here 
and they are working fine with all these tweaks (but my processors are 
stepping 2).

~ cat /proc/cpuinfo
processor       : 0
vendor_id       : Geode by NSC
cpu family      : 5
model           : 9
model name      : Geode(TM) Integrated Processor by National Semi
stepping        : 2
cache size      : 16 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu msr cx8 cmov mmx cxmmx
bogomips        : 99.94
clflush size    : 32

The only critical tweak I found is the one that changes the "Performance 
Control Incrementer" because its settings depends on the CPU's core 
frequency.
Maybe this tweak should be removed, because the BIOS (hopefully) set it in a 
way the hardware supports.

Regards,
Juergen

-- 
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
    Handelsregister: Amtsgericht Hildesheim, HRA 2686
         Vertretung Sued/Muenchen, Germany
   Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/