Crash in vm86() on SMP boxes with vesa driver?
Quoted 6 lines · Kendall Bennett
8.0 box with the latest 2.4.20 kernel on it (but the problem happened with the stock kernel and kernels lower then .20 as well). Unfortunately I don't have access to the box (it is in Australia), but I have access to the bug report information (and will try to configure a box soon to reproduce it here). Anyway the folowing is the error log produced by XFree86 when the crash occurs:
We told you before that you cannot trust VESA BIOS.
Quoted 3 lines
(II) VESA(0): initializing int10
(WW) VESA(0): BadV_BIOSchecksum
(II) VESA(0): PrimaryV_BIOSsegment is:0xc000
Bad checksum? Sorry, your BIOS is not usable. Either XFree gets checksum wrong, or there is something I would not want in my computer there...
Quoted 14 lines
(II) VESA(0): virtual address =
0x402d7000,physical address = 0xf0000000, size = 33554432(II) VESA(0): VBESetVBEMode failed(EE) VESA(0):
vm86()syscall generated signal 11.
(II) VESA(0): EAX=0x00000150, EBX=0x00000ba0, ECX=0x00000000, EDX=0x00000000
(II) VESA(0): ESP=0x00000fba, EBP=0x00000001, ESI=0x00000bc3, EDI=0x00003ad7
(II) VESA(0): CS=0xc000, SS=0x0100, DS=0x0000, ES=0xc000, FS=0x0000, GS=0x0000 (II) VESA(0): EIP=0x0000800f, EFLAGS=0x00033006 (II) VESA(0): code at0x000c800f:
62 18 91 60 09 fa 03 85 27 11 27 11 9d 0f f4 81
fe 06 d0 1a 68 74 99 a9 c6 39 f9 6d 04 b4 d6 6b
Quoted 5 lines
Also from debugging our own code we have a bit more information about where the problem occurs, and it occurs on the return from the
vm86()system call when the code tries to pop the EBX register from the stack. Which kind of indicates that the kernel screwed up the return stack of the program for some reason:
No. Crash happened inside VM, and it was shown as happening on return from int $0x80. But real problem is that in the VM you are executing code at 0xC000:0x800F. But there is no code there, it is garbage (bound bx,[bx+si]; xchg cx,ax; pusha; or dx,di ???) which generated bounds check interrupt.
Quoted 6 lines
Any ideas? I am not sure how to start debuging this (assuming I can get my SMP machine up and running and reproduce it) in the kernel. Also the machine that the problem occurs on goes to the customer tomorrow, so we won't be able to debug this much ourselves until I can get a new machine to reproduce it. But, it would seem to me that others may well have seen this problem already?
Make sure that videocard properly reports that it uses more than 32kB BIOS. Maybe card reports only 32kB, while it uses 48kB. System is free to do anything it wants with 32-48kB range including mapping another BIOS there, or writting zeroes, or garbage there... Also make sure that you have properly setup VM, that 0xC8000 is mapped to physical address 0xC8000...
Best regards,
Petr Vandrovec [email protected]
Quoted 8 lines · Petr Vandrovec
Quoted 6 lines
8.0 box with the latest 2.4.20 kernel on it (but the problem happened with the stock kernel and kernels lower then .20 as well). Unfortunately I don't have access to the box (it is in Australia), but I have access to the bug report information (and will try to configure a box soon to reproduce it here). Anyway the folowing is the error log produced by XFree86 when the crash occurs:
We told you before that you cannot trust VESA BIOS.
No, I do not agree with that statement at all. At present I would say that there is a problem with the vm86() services, or perhaps something wrong with the way we (and XFree86) are setting up the vm86 state for the BIOS. The reason I say that is because we use the BIOS all the time using vm86() services on OS/2 and we have not had any of these problems.
Essentially what I am saying is that this problem is fixable somewhere (either in the kernel or in our/XFree86's vm86() code).
Quoted 7 lines
Quoted 3 lines
(II) VESA(0): initializing int10
(WW) VESA(0): BadV_BIOSchecksum
(II) VESA(0): PrimaryV_BIOSsegment is:0xc000Bad checksum? Sorry, your BIOS is not usable. Either XFree gets checksum wrong, or there is something I would not want in my computer there...
I wish we stll had access to the machine so I could debug this. It is plausible that the BIOS has a bad checksum, but if it did, the system BIOS would have failed to POST the card. Hence I think there is something else going on here.
Quoted 11 lines
Quoted 5 lines
Also from debugging our own code we have a bit more information about where the problem occurs, and it occurs on the return from the
vm86()system call when the code tries to pop the EBX register from the stack. Which kind of indicates that the kernel screwed up the return stack of the program for some reason:No. Crash happened inside VM, and it was shown as happening on return from int $0x80. But real problem is that in the VM you are executing code at 0xC000:0x800F. But there is no code there, it is garbage (bound bx,[bx+si]; xchg cx,ax; pusha; or dx,di ???) which generated bounds check interrupt.
Ok, that makes sense. From experience with OS/2 and virtual machines, this generally happens when the video BIOS is confused by the state of the hardware, especially of I/O port access to certain registers has been incorrectly virtualised. ATI cards have been notorious for us on OS/2 for these types of problems, but the problem is solveable (most of the OS/2 related problems are all specific to running in a window, where access to the hardware registers has to be restricted and correctly emulated).
Quoted 7 lines
Quoted 6 lines
Any ideas? I am not sure how to start debuging this (assuming I can get my SMP machine up and running and reproduce it) in the kernel. Also the machine that the problem occurs on goes to the customer tomorrow, so we won't be able to debug this much ourselves until I can get a new machine to reproduce it. But, it would seem to me that others may well have seen this problem already?
Quoted 6 lines
Make sure that videocard properly reports that it uses more than 32kB BIOS. Maybe card reports only 32kB, while it uses 48kB. System is free to do anything it wants with 32-48kB range including mapping another BIOS there, or writting zeroes, or garbage there... Also make sure that you have properly setup VM, that
0xC8000is mapped to physical address0xC8000...
I will check into this. I am running into some strange problems on an NVIDIA GeForce4 integrated system right now, yet that same BIOS works perfectly in DOS and OS/2 so there is something up with the way the vm86() services are being handled. I will try to solve the problem I am seeing on this NVIDIA machine, and perhaps that will lead to a solution for both problems (assuming they are actually related of course ;-).
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
Quoted 6 lines · Kendall Bennett
I will check into this. I am running into some strange problems on an NVIDIA GeForce4 integrated system right now, yet that same BIOS works perfectly in DOS and OS/2 so there is something up with the way the
vm86()services are being handled. I will try to solve the problem I am seeing on this NVIDIA machine, and perhaps that will lead to a solution for both problems (assuming they are actually related of course ;-).
Another thing to do is to run it under the emulator x86 stuff in XFree86, see what that shows up differently to vm86 proper. And then there are lots of fun things that confuse video hardware - the fact Linux is a PnP OS, the PCI configuration problems and so on. In paticular nobody right now (including X11 proper) virtualises conf1/conf2 etc properly so you can crash the box easily