I have a computer here with a CPU that the BIOS identifies as:
Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B
kernel 2.6.14 identifies it as:
vendor_id : Geode by NSC
cpu family : 5
model : 9
model name : Geode(TM) Integrated Processor by National Semi
stepping : 1
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
Author: Juergen Beisert <[email protected]>
Date: Sun Jul 22 11:12:38 2007 +0200
x86: Replace NSC/Cyrix specific chipset access macros by inlined
functions.
Reversing the patch (compensating for kernel changes) let me boot a
2.6.25 kernel. I realize the patch is supposed to fix something that
didn't work right, but I didn't have a problem before and I do now. :-)
Samuel,
On Montag, 21. Juli 2008, Samuel Sieb wrote:
> I have a computer here with a CPU that the BIOS identifies as:
> Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B
>
> kernel 2.6.14 identifies it as:
> vendor_id : Geode by NSC
> cpu family : 5
> model : 9
> model name : Geode(TM) Integrated Processor by National Semi
> stepping : 1
>
> 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
> Author: Juergen Beisert <[email protected]>
> Date: Sun Jul 22 11:12:38 2007 +0200
>
> x86: Replace NSC/Cyrix specific chipset access macros by inlined
> functions.
>
> Reversing the patch (compensating for kernel changes) let me boot a
> 2.6.25 kernel. I realize the patch is supposed to fix something that
> didn't work right, but I didn't have a problem before and I do now. :-)
Yes. My patch makes some chipset tweaks working as expected. Or at least it
makes them work. It seems nobody ever tested them before. Remove the
following line (or change it to meet your CPU clock frequency):
linux-2.6.25/arch/x86/kernel/cyrix.c, line 151. Disable this line or change
the value 0x04 according to the speed of your CPU. This tweak helps others
with random hangs of their system.
For this CX86_PCR0 register here some info from the datasheet:
/*
* Setup the chipset specific Performance Control Incrementer
*
* The Performance Control Incrementer seems to be a delay line to control
* data setup time for DRAM access or it controls its jitter. Its setting
* depends on CPU and DRAM clock (CPU and DRAM clock are coupled through a
* simple clock divider. For a 300 MHz CPU the divider is 3.0 to get a DRAM
* clock of 100MHz)
* There is an application note how to setup it:
* "AMD Geode GX1 Processor Memory Timings for Maximum Performance."
* Values for various CPUs:
* 1-0 for processor speed 200...266MHz
* 1-1 for processor speed 300 and 333MHz
*
* Note: If your system runs unstable after setting new values here,
* try with other values or leave the value as the BIOS setup it.
* The setting depends also on physical layout!
*/
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
Samuel Sieb wrote:
> I have a computer here with a CPU that the BIOS identifies as:
> Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B
>
> kernel 2.6.14 identifies it as:
> vendor_id : Geode by NSC
> cpu family : 5
> model : 9
> model name : Geode(TM) Integrated Processor by National Semi
> stepping : 1
>
> 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
> Author: Juergen Beisert <[email protected]>
> Date: Sun Jul 22 11:12:38 2007 +0200
>
> x86: Replace NSC/Cyrix specific chipset access macros by inlined
> functions.
>
> Reversing the patch (compensating for kernel changes) let me boot a
> 2.6.25 kernel. I realize the patch is supposed to fix something that
> didn't work right, but I didn't have a problem before and I do now. :-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I couldn't figure out what the problem was, but shouldn't ccr3 be
declared as u8 in the following file? After all, that's what setCx86
expects. I realise that it being u32 will do no harm here, but I thought
I should point it out.
diff --git a/arch/x86/kernel/cpu/mtrr/cyrix.c
b/arch/x86/kernel/cpu/mtrr/cyrix.c
index ff14c32..e7d9f7e 100644
--- a/arch/x86/kernel/cpu/mtrr/cyrix.c
+++ b/arch/x86/kernel/cpu/mtrr/cyrix.c
@@ -123,7 +123,7 @@ cyrix_get_free_region(unsigned long base, unsigned
long size, int replace_reg)
}
static u32 cr4 = 0;
-static u32 ccr3;
+static u8 ccr3;
static void prepare_set(void)
{
* Rafael C. de Almeida <[email protected]> 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
> >
> > kernel 2.6.14 identifies it as:
> > vendor_id : Geode by NSC
> > cpu family : 5
> > model : 9
> > model name : Geode(TM) Integrated Processor by National Semi
> > stepping : 1
> >
> > 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
> > Author: Juergen Beisert <[email protected]>
> > Date: Sun Jul 22 11:12:38 2007 +0200
> >
> > x86: Replace NSC/Cyrix specific chipset access macros by inlined
> > functions.
> >
> > Reversing the patch (compensating for kernel changes) let me boot a
> > 2.6.25 kernel. I realize the patch is supposed to fix something that
> > didn't work right, but I didn't have a problem before and I do now. :-)
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).
(if this makes a difference we can figure out a proper way for a DMI or
CPU ID based quirk or something like that.)
Ingo
------------------>
commit d92d27891c37c58830e58e3277f1918465ceaee9
Author: Ingo Molnar <[email protected]>
Date: Mon Jul 21 13:45:19 2008 +0200
debug patch
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/cpu/cyrix.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 3fd7a67..85700c3 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -162,7 +162,7 @@ static void __cpuinit geode_configure(void)
local_irq_save(flags);
/* Suspend on halt power saving and enable #SUSP pin */
- setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
+ /* setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88); */
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
Ingo Molnar wrote:
> * Rafael C. de Almeida <[email protected]> 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.
Juergen Beisert wrote:
> Samuel,
>
> On Montag, 21. Juli 2008, 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
> Yes. My patch makes some chipset tweaks working as expected. Or at least it
> makes them work. It seems nobody ever tested them before. Remove the
> following line (or change it to meet your CPU clock frequency):
>
This system is kind of an embedded one and it's been working fine, so I
haven't bothered upgrading the OS for a long time. Once I get this
working I will be keeping it more up to date.
> linux-2.6.25/arch/x86/kernel/cyrix.c, line 151. Disable this line or change
> the value 0x04 according to the speed of your CPU. This tweak helps others
> with random hangs of their system.
>
I tried various values and various combinations of commenting out lines
and the only one that worked for me was to comment out the PCR1 line
just above it. With that line commented out (or both of them), it
boots. I do get a message about the TSC clocksource being unstable,
which is a new feature as well. I can only say that in 2.6.14 it was
fine. I could do similar tests if you want to know when that started
happening.
Samuel,
On Dienstag, 22. Juli 2008, Samuel Sieb wrote:
> Juergen Beisert wrote:
> > On Montag, 21. Juli 2008, 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
> >
> > Yes. My patch makes some chipset tweaks working as expected. Or at least
> > it makes them work. It seems nobody ever tested them before. Remove the
> > following line (or change it to meet your CPU clock frequency):
>
> This system is kind of an embedded one and it's been working fine, so I
> haven't bothered upgrading the OS for a long time. Once I get this
> working I will be keeping it more up to date.
>
> > linux-2.6.25/arch/x86/kernel/cyrix.c, line 151. Disable this line or
> > change the value 0x04 according to the speed of your CPU. This tweak
> > helps others with random hangs of their system.
>
> I tried various values and various combinations of commenting out lines
> and the only one that worked for me was to comment out the PCR1 line
> just above it. With that line commented out (or both of them), it
> boots.
Hmm, then your BIOS does know more about your hardware than the kernel. ;-)
The PCR1 line enables the incrementor. If disabled the value in PCR0 doesn't
matter.
> I do get a message about the TSC clocksource being unstable,
> which is a new feature as well.
Its the "stop the clock if the CPU runs into a halt instruction" feature.
Saves power and keeps your CPU cold. Side effect: It also stops the TSC, while
the CPU is idle.
You can disable this feature by commenting out the line Ingo mentioned. In the
case one of these bits was set by your BIOS, your can also revert it:
setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x88);
This will prevent your CPU from stopping its clock and the TSC should be
stable. But: It will also disable the clockfrequency driver from work.
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
* Samuel Sieb <[email protected]> wrote:
> Ingo Molnar wrote:
>> * Rafael C. de Almeida <[email protected]> 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?
If yes then could you try to figure out which of the 11 places above
make the difference? If it's a single line that makes a difference then
you'd need about 4 reboots to figure it out, by 'bisecting' the lines.
(changing half of them to setCx86, etc.)
Ingo
------------------->
commit 6072555e0b697b5bc968bf1b397f0a710d75657e
Author: Ingo Molnar <[email protected]>
Date: Tue Jul 22 11:58:14 2008 +0200
x86, cyrix: debug
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/cpu/cyrix.c | 20 ++++++++++----------
include/asm-x86/processor-cyrix.h | 8 ++++++++
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 3fd7a67..db5868c 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -116,7 +116,7 @@ static void __cpuinit set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* Load/Store Serialize to mem access disable (=reorder it) */
- setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
+ setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -127,11 +127,11 @@ static void __cpuinit set_cx86_memwb(void)
printk(KERN_INFO "Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
/* CCR2 bit 2: unlock NW bit */
- setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
+ setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
- setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
+ setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
}
static void __cpuinit set_cx86_inc(void)
@@ -144,10 +144,10 @@ static void __cpuinit set_cx86_inc(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* PCR1 -- Performance Control */
/* Incrementor on, whatever that is */
- setCx86(CX86_PCR1, getCx86(CX86_PCR1) | 0x02);
+ setCx86_old(CX86_PCR1, getCx86_old(CX86_PCR1) | 0x02);
/* PCR0 -- Performance Control */
/* Incrementor Margin 10 */
- setCx86(CX86_PCR0, getCx86(CX86_PCR0) | 0x04);
+ setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) | 0x04);
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
}
@@ -162,14 +162,14 @@ static void __cpuinit geode_configure(void)
local_irq_save(flags);
/* Suspend on halt power saving and enable #SUSP pin */
- setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
+ setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
/* FPU fast, DTE cache, Mem bypass */
- setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
+ setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
set_cx86_memwb();
@@ -286,7 +286,7 @@ static void __cpuinit init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
- setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
+ setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
/*
* GXm : 0x30 ... 0x5f GXm datasheet 51
@@ -309,7 +309,7 @@ static void __cpuinit init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++; /* M II */
/* Enable MMX extensions (App note 108) */
- setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
+ setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
} else {
c->coma_bug = 1; /* 6x86MX, it has the bug. */
}
@@ -424,7 +424,7 @@ static void __cpuinit cyrix_identify(struct cpuinfo_x86 *c)
local_irq_save(flags);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
- setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80); /* enable cpuid */
+ setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80); /* enable cpuid */
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
local_irq_restore(flags);
}
diff --git a/include/asm-x86/processor-cyrix.h b/include/asm-x86/processor-cyrix.h
index 97568ad..1198f2a 100644
--- a/include/asm-x86/processor-cyrix.h
+++ b/include/asm-x86/processor-cyrix.h
@@ -28,3 +28,11 @@ static inline void setCx86(u8 reg, u8 data)
outb(reg, 0x22);
outb(data, 0x23);
}
+
+#define getCx86_old(reg) ({ outb((reg), 0x22); inb(0x23); })
+
+#define setCx86_old(reg, data) do { \
+ outb((reg), 0x22); \
+ outb((data), 0x23); \
+} while (0)
+
On Dienstag, 22. Juli 2008, Ingo Molnar wrote:
> * Samuel Sieb <[email protected]> wrote:
> > Ingo Molnar wrote:
> >> * Rafael C. de Almeida <[email protected]> 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
Juergen Beisert wrote:
> On Dienstag, 22. Juli 2008, Samuel Sieb wrote:
>> Juergen Beisert wrote:
>>> linux-2.6.25/arch/x86/kernel/cyrix.c, line 151. Disable this line or
>>> change the value 0x04 according to the speed of your CPU. This tweak
>>> helps others with random hangs of their system.
>> I tried various values and various combinations of commenting out lines
>> and the only one that worked for me was to comment out the PCR1 line
>> just above it. With that line commented out (or both of them), it
>> boots.
>
> Hmm, then your BIOS does know more about your hardware than the kernel. ;-)
> The PCR1 line enables the incrementor. If disabled the value in PCR0 doesn't
> matter.
>
I did some more testing and the end result is that you can't enable the
incrementor on this cpu. I tried values from 0 to 7 for the PCR0 and it
always crashed or hung (0 also gave noise all over the screen). The
values set by the BIOS are PCR1: 1 and PCR0: 0.
Juergen Beisert wrote:
> On Dienstag, 22. Juli 2008, Ingo Molnar wrote:
>> 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
>>
>> 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?
It doesn't.
> 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.
>
This was the only line that was a problem. See the other branch of this
thread with Juergen Beisert.
* Samuel Sieb <[email protected]> wrote:
>> 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.
>
> This was the only line that was a problem. See the other branch of
> this thread with Juergen Beisert.
any patch we should pick up to make your box boot?
Ingo
Ingo Molnar wrote:
> * Samuel Sieb <[email protected]> wrote:
>
>>> 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.
>> This was the only line that was a problem. See the other branch of
>> this thread with Juergen Beisert.
>
> any patch we should pick up to make your box boot?
>
Are you suggesting I should make the patch or you're just asking which
lines? What I did to make a kernel that boots was to comment out the
line that calls the incrementor setup function. It sounds like the
stepping 2 version doesn't have the problem, so if possible could you
call the function based on it not being a stepping 1 CPU?
On Montag, 28. Juli 2008, Ingo Molnar wrote:
> * Samuel Sieb <[email protected]> wrote:
> >> 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.
> >
> > This was the only line that was a problem. See the other branch of
> > this thread with Juergen Beisert.
>
> any patch we should pick up to make your box boot?
We could simply delete the lines that change the incrementor setup (in the
hope the BIOS did it in a correct way).
Or we need access to the stepping number of the CPU (my old Media GX datasheet
tells me, you can enable or disable a "Performance Control Incrementer" in
this device, but there are no bits to set different increment values) and the
core CPU clock speed (on Geode GX CPUs you can enable and disable
the "Performance Control Incrementer" and - when enabled - you also must
setup a correct increment value according to the core CPU clock).
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
* Samuel Sieb <[email protected]> wrote:
> Ingo Molnar wrote:
>> * Samuel Sieb <[email protected]> wrote:
>>
>>>> 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.
>>> This was the only line that was a problem. See the other branch of
>>> this thread with Juergen Beisert.
>>
>> any patch we should pick up to make your box boot?
>
> Are you suggesting I should make the patch or you're just asking which
> lines? What I did to make a kernel that boots was to comment out the
> line that calls the incrementor setup function. It sounds like the
> stepping 2 version doesn't have the problem, so if possible could you
> call the function based on it not being a stepping 1 CPU?
yes, please send a patch we can apply. You did all the hard work
tracking down this bug, you should get the credit as well :)
Ingo
Ingo Molnar wrote:
> any patch we should pick up to make your box boot?
>
I've looked through various datasheets and found that the GXm and GXLV
Geode processors don't have an incrementor. I attached two patches.
One only calls the incrementor setup for GX1 or better. The other one
removes the incrementor setup entirely. As the incrementor value
differs according to clock speed and we would hope that the BIOS
configures it correctly, it is probably the better one to choose. But I
will leave that choice up to you. Either one works for me. :-)
* Samuel Sieb <[email protected]> wrote:
> Ingo Molnar wrote:
>> any patch we should pick up to make your box boot?
>>
> I've looked through various datasheets and found that the GXm and GXLV
> Geode processors don't have an incrementor. I attached two patches. One
> only calls the incrementor setup for GX1 or better. The other one
> removes the incrementor setup entirely. As the incrementor value
> differs according to clock speed and we would hope that the BIOS
> configures it correctly, it is probably the better one to choose. But I
> will leave that choice up to you. Either one works for me. :-)
i went for the commit below and queued it up in tip/x86/urgent - thanks
Samuel.
what happens if the incrementor is not set up correctly by the BIOS - do
timer IRQs come incorrectly? Or dont they come at all?
Ingo
--------------->
>From c6744955d0ec0cb485c28c51eeb7185e260f6172 Mon Sep 17 00:00:00 2001
From: Samuel Sieb <[email protected]>
Date: Wed, 6 Aug 2008 22:06:29 -0700
Subject: [PATCH] x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)"
Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped
booting starting at v2.6.22.
The reason is this commit:
> commit f25f64ed5bd3c2932493681bdfdb483ea707da0a
> Author: Juergen Beisert <[email protected]>
> Date: Sun Jul 22 11:12:38 2007 +0200
>
> x86: Replace NSC/Cyrix specific chipset access macros by inlined functions.
this commit activated a macro which was dormant before due to (buggy)
macro side-effects.
I've looked through various datasheets and found that the GXm and GXLV
Geode processors don't have an incrementor.
Remove the incrementor setup entirely. As the incrementor value
differs according to clock speed and we would hope that the BIOS
configures it correctly, it is probably the right solution.
Cc: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/cpu/cyrix.c | 18 ------------------
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 3fd7a67..e710a21 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -134,23 +134,6 @@ static void __cpuinit set_cx86_memwb(void)
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
}
-static void __cpuinit set_cx86_inc(void)
-{
- unsigned char ccr3;
-
- printk(KERN_INFO "Enable Incrementor on Cyrix/NSC processor.\n");
-
- ccr3 = getCx86(CX86_CCR3);
- setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
- /* PCR1 -- Performance Control */
- /* Incrementor on, whatever that is */
- setCx86(CX86_PCR1, getCx86(CX86_PCR1) | 0x02);
- /* PCR0 -- Performance Control */
- /* Incrementor Margin 10 */
- setCx86(CX86_PCR0, getCx86(CX86_PCR0) | 0x04);
- setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
-}
-
/*
* Configure later MediaGX and/or Geode processor.
*/
@@ -174,7 +157,6 @@ static void __cpuinit geode_configure(void)
set_cx86_memwb();
set_cx86_reorder();
- set_cx86_inc();
local_irq_restore(flags);
}
On Mittwoch, 20. August 2008, Ingo Molnar wrote:
> * Samuel Sieb <[email protected]> wrote:
> > Ingo Molnar wrote:
> >> any patch we should pick up to make your box boot?
> >
> > I've looked through various datasheets and found that the GXm and GXLV
> > Geode processors don't have an incrementor. I attached two patches. One
> > only calls the incrementor setup for GX1 or better. The other one
> > removes the incrementor setup entirely. As the incrementor value
> > differs according to clock speed and we would hope that the BIOS
> > configures it correctly, it is probably the better one to choose. But I
> > will leave that choice up to you. Either one works for me. :-)
>
> i went for the commit below and queued it up in tip/x86/urgent - thanks
> Samuel.
>
> what happens if the incrementor is not set up correctly by the BIOS
The system can freeze. The clock the incrementor modifies is used for the
external SDRAM (something like a delay line or jitter reduction). Thats why
its setting depends on the core clock speed.
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
* Juergen Beisert <[email protected]> wrote:
> On Mittwoch, 20. August 2008, Ingo Molnar wrote:
> > * Samuel Sieb <[email protected]> wrote:
> > > Ingo Molnar wrote:
> > >> any patch we should pick up to make your box boot?
> > >
> > > I've looked through various datasheets and found that the GXm and GXLV
> > > Geode processors don't have an incrementor. I attached two patches. One
> > > only calls the incrementor setup for GX1 or better. The other one
> > > removes the incrementor setup entirely. As the incrementor value
> > > differs according to clock speed and we would hope that the BIOS
> > > configures it correctly, it is probably the better one to choose. But I
> > > will leave that choice up to you. Either one works for me. :-)
> >
> > i went for the commit below and queued it up in tip/x86/urgent - thanks
> > Samuel.
> >
> > what happens if the incrementor is not set up correctly by the BIOS
>
> The system can freeze. The clock the incrementor modifies is used for
> the external SDRAM (something like a delay line or jitter reduction).
> Thats why its setting depends on the core clock speed.
so, what's the recommendation - is the patch fine? (which removes
incrementor setting, leaving it to the BIOS)
Ingo
On Mittwoch, 20. August 2008, Ingo Molnar wrote:
> * Juergen Beisert <[email protected]> wrote:
> > On Mittwoch, 20. August 2008, Ingo Molnar wrote:
> > > * Samuel Sieb <[email protected]> wrote:
> > > > Ingo Molnar wrote:
> > > >> any patch we should pick up to make your box boot?
> > > >
> > > > I've looked through various datasheets and found that the GXm and
> > > > GXLV Geode processors don't have an incrementor. I attached two
> > > > patches. One only calls the incrementor setup for GX1 or better. The
> > > > other one removes the incrementor setup entirely. As the incrementor
> > > > value differs according to clock speed and we would hope that the
> > > > BIOS configures it correctly, it is probably the better one to
> > > > choose. But I will leave that choice up to you. Either one works
> > > > for me. :-)
> > >
> > > i went for the commit below and queued it up in tip/x86/urgent - thanks
> > > Samuel.
> > >
> > > what happens if the incrementor is not set up correctly by the BIOS
> >
> > The system can freeze. The clock the incrementor modifies is used for
> > the external SDRAM (something like a delay line or jitter reduction).
> > Thats why its setting depends on the core clock speed.
>
> so, what's the recommendation - is the patch fine? (which removes
> incrementor setting, leaving it to the BIOS)
In my environment I need the incrementor setting in accordance to the CPU core
frequency, as my BIOS sets a wrong value. Removing it is no solution for me.
But: There where a few bug reports in the last weeks, and all had problems
when the incrementor setting is changed inside the kernel. Seems only my BIOS
is broken.
So I vote for removing the incrementor setting. I can life with a local patch
for my kernels.
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
* Juergen Beisert <[email protected]> wrote:
> On Mittwoch, 20. August 2008, Ingo Molnar wrote:
> > * Juergen Beisert <[email protected]> wrote:
> > > On Mittwoch, 20. August 2008, Ingo Molnar wrote:
> > > > * Samuel Sieb <[email protected]> wrote:
> > > > > Ingo Molnar wrote:
> > > > >> any patch we should pick up to make your box boot?
> > > > >
> > > > > I've looked through various datasheets and found that the GXm and
> > > > > GXLV Geode processors don't have an incrementor. I attached two
> > > > > patches. One only calls the incrementor setup for GX1 or better. The
> > > > > other one removes the incrementor setup entirely. As the incrementor
> > > > > value differs according to clock speed and we would hope that the
> > > > > BIOS configures it correctly, it is probably the better one to
> > > > > choose. But I will leave that choice up to you. Either one works
> > > > > for me. :-)
> > > >
> > > > i went for the commit below and queued it up in tip/x86/urgent - thanks
> > > > Samuel.
> > > >
> > > > what happens if the incrementor is not set up correctly by the BIOS
> > >
> > > The system can freeze. The clock the incrementor modifies is used for
> > > the external SDRAM (something like a delay line or jitter reduction).
> > > Thats why its setting depends on the core clock speed.
> >
> > so, what's the recommendation - is the patch fine? (which removes
> > incrementor setting, leaving it to the BIOS)
>
> In my environment I need the incrementor setting in accordance to the
> CPU core frequency, as my BIOS sets a wrong value. Removing it is no
> solution for me.
>
> But: There where a few bug reports in the last weeks, and all had
> problems when the incrementor setting is changed inside the kernel.
> Seems only my BIOS is broken.
>
> So I vote for removing the incrementor setting. I can life with a
> local patch for my kernels.
is there any way to specifically identify your board/bios combo, like a
DMI string? I have absolutely no problem with adding a quirk for your
box. In fact i'd much prefer that solution than you having to carry a
local patch - quirks are local only in the rarest of circumstances.
Mind doing a quirk patch ontop of the patch below, for us to apply for
v2.6.27?
Ingo
----------------->
>From c6744955d0ec0cb485c28c51eeb7185e260f6172 Mon Sep 17 00:00:00 2001
From: Samuel Sieb <[email protected]>
Date: Wed, 6 Aug 2008 22:06:29 -0700
Subject: [PATCH] x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)"
Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped
booting starting at v2.6.22.
The reason is this commit:
> commit f25f64ed5bd3c2932493681bdfdb483ea707da0a
> Author: Juergen Beisert <[email protected]>
> Date: Sun Jul 22 11:12:38 2007 +0200
>
> x86: Replace NSC/Cyrix specific chipset access macros by inlined functions.
this commit activated a macro which was dormant before due to (buggy)
macro side-effects.
I've looked through various datasheets and found that the GXm and GXLV
Geode processors don't have an incrementor.
Remove the incrementor setup entirely. As the incrementor value
differs according to clock speed and we would hope that the BIOS
configures it correctly, it is probably the right solution.
Cc: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/cpu/cyrix.c | 18 ------------------
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 3fd7a67..e710a21 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -134,23 +134,6 @@ static void __cpuinit set_cx86_memwb(void)
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
}
-static void __cpuinit set_cx86_inc(void)
-{
- unsigned char ccr3;
-
- printk(KERN_INFO "Enable Incrementor on Cyrix/NSC processor.\n");
-
- ccr3 = getCx86(CX86_CCR3);
- setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
- /* PCR1 -- Performance Control */
- /* Incrementor on, whatever that is */
- setCx86(CX86_PCR1, getCx86(CX86_PCR1) | 0x02);
- /* PCR0 -- Performance Control */
- /* Incrementor Margin 10 */
- setCx86(CX86_PCR0, getCx86(CX86_PCR0) | 0x04);
- setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
-}
-
/*
* Configure later MediaGX and/or Geode processor.
*/
@@ -174,7 +157,6 @@ static void __cpuinit geode_configure(void)
set_cx86_memwb();
set_cx86_reorder();
- set_cx86_inc();
local_irq_restore(flags);
}