Re: port-i386/41267: 5.0 RC4 does not detect second CPU in VIA VT-310DP motherboard

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-i386/41267; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: port-i386-maintainer%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost, 
        netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Subject: Re: port-i386/41267: 5.0 RC4 does not detect second CPU in VIA
 VT-310DP motherboard
Date: Mon, 30 Apr 2012 02:43:10 +0300

 Yes, I thought about the same thing but I didn't knew how to write it.
 Patch almost worked but ECX8 bit needs to be written actually.
 
 I added these lines to the end of your code before break:
 
 msr =3D rdmsr(0x00001107);
 wrmsr(0x00001107, msr | 0x00000001);
 
 0x00001107  (Feature control register) and the first bit is ECX8 bit
 (at least on Eden-N CPU).
 
 That solved the problem and system booted with both CPU enabled.
 
 On Mon, Apr 30, 2012 at 1:28 AM, Christos Zoulas 
<christos%zoulas.com@localhost> wrot=
 e:
 > On Apr 29, 11:27pm, vezhlys%gmail.com@localhost (Andrius V) wrote:
 > -- Subject: Re: port-i386/41267: 5.0 RC4 does not detect second CPU in VI=
 A VT
 >
 > | I found the main problem for this bug. It is related to the patch made =
 for
 > | PR40213. Changes itself were not bad but for some reason (cpu_feature[0=
 ] &
 > | CPUID_CX8) !=3D 0 (x86_patch function in patch.c) returns false for thi=
 s
 > | system (VIA Eden-N actually supports cmpxchg8b instruction). Because of
 > | this it uses i486 version of atomic_cas_64 function (atomic.S) and this=
  is
 > | the place where it doesn't work. That code worked too until popf, pushf
 > | were added and that change broke the support (it was made for "Fix the =
 i486
 > | atomic_cas_64() to not unconditionally enable interrupts.", if I am not
 > | wrong), because of this atomic_swap_64 goes into infinitive loop too (l=
 ook
 > | at my earlier posts). The main question remains why pentium routine is =
 not
 > | used how to solve that? Currently I commented this if clause (so the
 > | "patch" applied anyway) and system just booted fine with both CPUs. Any
 > | thoughts and suggestions? Thanks.
 >
 > Can you try this patch? If it does not work, can you send me the cpuid ou=
 tput
 > for your processors (or add printf's and see why it does not)?
 >
 > christos
 >
 > Index: identcpu.c
 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 > RCS file: /cvsroot/src/sys/arch/x86/x86/identcpu.c,v
 > retrieving revision 1.30
 > diff -u -p -u -r1.30 identcpu.c
 > --- identcpu.c =C2=A023 Feb 2012 14:45:55 -0000 =C2=A0 =C2=A0 =C2=A01.30
 > +++ identcpu.c =C2=A029 Apr 2012 22:26:32 -0000
 > @@ -380,13 +380,30 @@ static void
 > =C2=A0cpu_probe_winchip(struct cpu_info *ci)
 > =C2=A0{
 >
 > - =C2=A0 =C2=A0 =C2=A0 if (cpu_vendor !=3D CPUVENDOR_IDT ||
 > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CPUID2FAMILY(ci->ci_signature) !=3D =
 5)
 > + =C2=A0 =C2=A0 =C2=A0 if (cpu_vendor !=3D CPUVENDOR_IDT)
 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return;
 >
 > - =C2=A0 =C2=A0 =C2=A0 if (CPUID2MODEL(ci->ci_signature) =3D=3D 4) {
 > + =C2=A0 =C2=A0 =C2=A0 switch (CPUID2FAMILY(ci->ci_signature)) {
 > + =C2=A0 =C2=A0 =C2=A0 case 5:
 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* WinChip C6 */
 > - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ci->ci_feat_val[0] &=
 =3D ~CPUID_TSC;
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (CPUID2MODEL(ci->ci=
 _signature) =3D=3D 4)
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
 =C2=A0 ci->ci_feat_val[0] &=3D ~CPUID_TSC;
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
 > + =C2=A0 =C2=A0 =C2=A0 case 6:
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* VIA Eden ESP
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Quoting from p=
 age 3-4 of: "VIA Eden ESP Processor Datasheet"
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* http://www.via=
 .com.tw/download/mainboards/6/14/Eden20v115.pdf
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* 1. The CMPXCHG=
 8B instruction is provided and always enabled,
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0h=
 owever, it appears disabled in the corresponding CPUID
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0f=
 unction bit 0 to avoid a bug in an early version of
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0W=
 indows NT. However, this default can be changed via a
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0 =C2=A0b=
 it in the FCR MSR.
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ci->ci_feat_val[0] |=
 =3D CPUID_CX8;
 > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
 > =C2=A0 =C2=A0 =C2=A0 =C2=A0}
 > =C2=A0}
 >