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/