Messages in this thread Patch in this message |  | | Date | Sun, 7 Jan 2001 20:19:52 +0100 | From | Ingo Oeser <> | Subject | [PATCH] Cyrix III boot fix and bug report |
| |
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/
|  |