Messages in this thread Patches in this message | | | From | jmaurer@cck ... | Subject | bzImage boot trouble on Toshiba laptop | Date | Sun, 14 Jul 1996 00:29:29 +0200 (MET DST) |
| |
Hi!
I'm having problems booting bzImage type kernel images on a Toshiba Tecra 710CDT laptop. The computer resets itself right at the beginning of the boot sequence between displaying the final "Loading..." dot and the "Uncompressing..." message. If not interrupted, this leads to an endless booting loop. This error does not occur when using zImage type kernels or loadlin.
I can repeat this behaviour easily by
/usr/src/linux> make zdisk Alt-Ctrl-Delete (works flawlessly)
/usr/src/linux> make bzdisk Alt-Ctrl-Delete (resets as described above)
To determine where the reset happens, I experimented with the code in arch/i386/boot/setup.S and instrumented it finally as follows:
--- setup.S Sat Mar 30 19:58:57 1996 +++ /users1/jmaurer/setup.S Sat Jul 13 23:04:53 1996 @@ -446,6 +446,10 @@ ! now we are at the right place end_move_self: +!debugging beep -- JM + call beep + mov es,[video_segment] + lidt idt_48 ! load idt with 0,0 lgdt gdt_48 ! load gdt with whatever appropriate @@ -503,6 +507,9 @@ mov al,#0xFB ! mask all irq's but irq2 which out #0x21,al ! is cascaded + mov es,[video_segment] + seg es + mov 0x0,#0x3030 ! Well, that certainly wasn't fun :-(. Hopefully it works, and we don't ! need no steenking BIOS anyway (except for the initial loading :-). ! The BIOS-routine wants lots of unnecessary data, and it's less
This gives me a beep before initializing the protected mode stuff and outputs some colorful character in the upper left corner of the screen just before setting the protected mode bit in the machine status register (i.e. switching the processor into protected mode). I have been unable to call the beep routine after the lidt (load interrupt descriptor table) instruction, so I am writing some random garbage to video memory to give me feedback.
After the switch to protected mode, I think the flow of control passes to arch/i386/boot/compressed/head.S, where the kernel is uncompressed. I have instrumented this code as follows:
--- head.S Sat Mar 9 12:31:42 1996 +++ /users1/jmaurer/head.S Sat Jul 13 23:58:41 1996 @@ -42,6 +42,7 @@ mov %ax,%es mov %ax,%fs mov %ax,%gs + movw $0x3030,0xb8004 #ifdef __SMP__ orw %bx,%bx # What state are we in BX=1 for SMP # 0 for boot When booting the bzImage, I get only the character written from setup.S and nothing from compressed/head.S before the reset, so the problem must lie somewhere in between. Booting a zImage gives all expected colorful characters and runs successfully.
My current theory on this is that the BIOS's INT15 handling code does something strange with the processor's protected mode. The bzImage code uses the INT15 stuff to move loaded kernel parts to memory >1MB. When we switch to protected mode (in setup.S) or when we initialize the segment registers with the KERNEL_DS selector (in compressed/head.S), a CPU protection violation hits (how can that happen? We put a sane value into the gdt register). The protection violation wants to get handled by an exception handler in the idt, which fails, because the idt is of zero length (see setup.S:idt_48). Then, the CPU tries to invoke the double-fault handler, which fails due to the idt being of zero length once more, Finally, this results in a triple fault, resetting the CPU. (See http://www.x86.org/Productivity/TripleFault.html for further info on triple-faulting.)
Is there anything else I can do to get that problem fixed? It's not that this is vital, because zImage type kernels can be booted, but it's frightening that the BIOS might mess with protected mode when it shouldn't. And I think a call to the Toshiba support people will only be successful if I have hard info what they are doing the wrong way, because we're not running some Microsoft kind of OS. Or probably the Linux code does something the wrong way?
Does the bzImage code work flawlessly for everybody except me? [Yes, it does even work for me on all desktop PCs I've seen so far.]
Software: Linux kernel 2.0.0 (note that the setup code did not change it the last revisions, so this kernel version should be as fine as the most recent one) gcc 2.7.2 kernel configuration should not matter, because it is not relevant at this stage of booting
Hardware: If you want to have a closer look at the hardware specs, the official Toshiba WWW page is at http://www.toshiba.com/tais/csd/support/products/tig/pc/710720.htm and my own page at http://www.cck.uni-kl.de/misc/tecra710/ (includes specific Linux info).
Thanks for any help you might be able to provide me with.
Jens Maurer.
--- -- - Jens Maurer Email: jmaurer@cck.uni-kl.de
| |