[PATCH] Cyrix III boot fix and bug report

[PATCH] Cyrix III boot fix and bug report

[Ingo Oeser]

Hi,

I reported the crash on boot with a Winchip (which was actually
an Cyrix III) since test12-pre8.

I couldn't access the machine and debug the problem until now.


[1.] One line summary of the problem:

   Cyrix III doesn't boot, because of illegal rdmsr to 80000001
   
[2.] Full description of the problem/report:

   In linux-2.4.0/arch/i386/kernel/setup.c:1400 we try to detect
   3DNOW extensions for Cyrix III via rdmsr from 0x80000001. This
   fails with an exception, that is not handled and thus we oops
   on boot.
   
[3.] Keywords (i.e., modules, networking, kernel):
   i386, kernel, cyrix, winchip, msr, 3dnow
   
[4.] Kernel version (from /proc/version):

   Linux version 2.4.0 (root@compiler) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #1 Sat Jan 6 18:58:11 CET 2001
   
[5.] Output of Oops.. message (if applicable) with symbolic information 
     resolved (see Documentation/oops-tracing.txt)

ksymoops 2.3.4 on i586 2.4.0-prerelease.  Options used
     -V (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m boot/System.map-2.4.0 (specified)

CPU: 0
EIP: 0010:[<c020dee6>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010a86
eax: 00000008 ebx: 746e6543 ecx: 80000001 edx: 00000000
esi: 80000000 edi: 80860000 ebp: c01f9680 esp: c020bf94
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c020b000)
Stack: 746e6543 80000000 80860000 c01f9680 00000000 00000000 808030b5 c020e7d6
       c01f9680 00003ff0 0009b800 c0105000 0008e000 c0212a2d c01d982d 80000005
       c020c102 c01f9680 c020c77c 00003ff0 00003ff0 00003ff0 00003ff0 00003ff0
Call Trace: [<c0105000>] [<c0100191>]
Code: 0f 32 89 d6 85 f6 7d 09 b8 3f 00 00 00 0f ab 45 0c 55 e8 6f

>>EIP; c020dee6 <init_centaur+1ce/1f8>   <=====
Trace; c0105000 <empty_bad_page+0/1000>
Trace; c0100191 <L6+0/2>
Code;  c020dee6 <init_centaur+1ce/1f8>
00000000 <_EIP>:
Code;  c020dee6 <init_centaur+1ce/1f8>   <=====
   0:   0f 32                     rdmsr     <=====
Code;  c020dee8 <init_centaur+1d0/1f8>
   2:   89 d6                     mov    %edx,%esi
Code;  c020deea <init_centaur+1d2/1f8>
   4:   85 f6                     test   %esi,%esi
Code;  c020deec <init_centaur+1d4/1f8>
   6:   7d 09                     jge    11 <_EIP+0x11> c020def7 <init_centaur+1df/1f8>
Code;  c020deee <init_centaur+1d6/1f8>
   8:   b8 3f 00 00 00            mov    $0x3f,%eax
Code;  c020def3 <init_centaur+1db/1f8>
   d:   0f ab 45 0c               bts    %eax,0xc(%ebp)
Code;  c020def7 <init_centaur+1df/1f8>
  11:   55                        push   %ebp
Code;  c020def8 <init_centaur+1e0/1f8>
  12:   e8 6f 00 00 00            call   86 <_EIP+0x86> c020df6c <init_transmeta+5c/180>

Kernel panic: Attempted to kill the idle task!

[6.] A small shell script or example program which triggers the
     problem (if possible)

     Not applicable. Just boot it on the right hardware.

[7.] Environment

   A heavily mangled Debian (potato) GNU/Linux with the required
   updates to run this kernel.
   
[7.1.] Software (add the output of the ver_linux script here)

   Not applicable, since this is an embedded system.

[7.2.] Processor information (from /proc/cpuinfo):

   Couldn't get to this stage. But my be this will help:

   CPU: Before vendor init, caps: 008030b5 808030b5 0000000, vendor = 5
   
   This is the last log message seen before the oops.

[7.3.] Module information (from /proc/modules):

   Nothing loaded in this stage.

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
   
   Nothing used at this stage. Even with all pluggable hardware
   removed (except graphics adapter), we still see the problem.

   Chipset: VIA VT82C694XA/596B
   Mainboard: P6VAP-Me from AMR
   
[7.5.] PCI information ('lspci -vvv' as root)

   Not applicable(?). We support this too, if needed.

[7.6.] SCSI information (from /proc/scsi/scsi)

   Not applicable. (only using ide-scsi later)

[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):

   Ask for this.

[X.] Other notes, patches, fixes, workarounds:

The patch that fixed it for me:

--- linux-2.4.0/arch/i386/kernel/setup.c.orig	Sun Dec 31 19:26:18 2000
+++ linux-2.4.0/arch/i386/kernel/setup.c	Sat Jan  6 23:21:43 2001
@@ -1400,10 +1400,11 @@
 					wrmsr (0x1107, lo, hi);
 
 					set_bit(X86_FEATURE_CX8, &c->x86_capability);
+					/* The rdmsr will oops on my machine -ioe
 					rdmsr (0x80000001, lo, hi);
 					if (hi & (1<<31))
 						set_bit(X86_FEATURE_3DNOW, &c->x86_capability);
-
+					*/
 					get_model_name(c);
 					display_cacheinfo(c);
 					break;


But using rdmsr_eio() or sth. else, which catches execptions and
reports them only as errors and just disables the feature instead
of oopsing on boot, might be an better option.

Happy hackin' now

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<       come and join the fun       >>>>>>>>>>>>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Cyrix III boot fix and bug report

[Alan Cox]

>    3DNOW extensions for Cyrix III via rdmsr from 0x80000001. This
>    fails with an exception, that is not handled and thus we oops
>    on boot.

Interesting. Ok.  We can set the bit unconditionally it seems.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Cyrix III boot fix and bug report

[H. Peter Anvin]

Followup to:  <E14FKZL-000367-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> >    3DNOW extensions for Cyrix III via rdmsr from 0x80000001. This
> >    fails with an exception, that is not handled and thus we oops
> >    on boot.
> 
> Interesting. Ok.  We can set the bit unconditionally it seems.
> 

Does it appear in CPUID?  If so, we shouldn't need to mess with this
crap at all.

(Could this code have been written by someone who was confused between
MSR 0x80000001 and CPUID 0x80000001?)

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Cyrix III boot fix and bug report

[Alan Cox]

> (Could this code have been written by someone who was confused between
> MSR 0x80000001 and CPUID 0x80000001?)

It looks like thats what happened. The docs say it has 3dnow and mmx but
I think your diagnosis is correct

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Cyrix III boot fix and bug report

[H. Peter Anvin]

Alan Cox wrote:
> 
> > (Could this code have been written by someone who was confused between
> > MSR 0x80000001 and CPUID 0x80000001?)
> 
> It looks like thats what happened. The docs say it has 3dnow and mmx but
> I think your diagnosis is correct

Especially since it's bit 31 in EDX.  I don't think Cyrixi uses MSRs in
the 0x8000xxxx range.  I bet this should have been CPUID.

I suspect that that whole code should look more like this.  The MSR
access shouldn't have any effect on the extended CPUID flags, so that
shouldn't need to be there at all, unless there are Cyrix III's out there
which fail to report it in CPUID.

	-hpa

	case 6: /* Cyrix III */
		rdmsr (0x1107, lo, hi);
		lo |= (1<<1 | 1<<7);    /* Report CX8 & enable PGE */
                wrmsr (0x1107, lo, hi);

		/* Update the feature flags to include just revealed ones */
		c->x86_capability[0] = cpuid_edx(1);

		get_model_name(c);
		display_cacheinfo(c);
                break;


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/