X does not start. vm86old returns ENOSYS??

X does not start. vm86old returns ENOSYS??

[Denis Vlasenko]

Hi Stas, all,

I have put my hard drive, which holds working desktop
Linux system, into another box.
Linux starts w/o problem, but X does not.

Video is an i845. Madrake 9 install on the same box
starts X just fine.

I booted into 'my' Linux again, mounted partition
with working Mandrake, chrooted into it, tried to start X.
The same result, does not work.

I tracked problem down to this:

XFree86.0.log:

(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
(II) I810(0): initializing int10
(II) I810(0): Primary V_BIOS segment is: 0xc000
(EE) I810(0): unknown reason for exception
(II) I810(0): EAX=0x00004f00, EBX=0x00000000, ECX=0x00000000, EDX=0x00000000
(II) I810(0): ESP=0x00000ffa, EBP=0x00000000, ESI=0x00000000, EDI=0x00002000
(II) I810(0): CS=0x0f96, SS=0x0100, DS=0x0040, ES=0x0000, FS=0x0000, GS=0x0000
(II) I810(0): EIP=0x00010000, EFLAGS=0x00033282
(II) stack at 0x00001ffa:
 00 06 00 00 00 32
(II) I810(0): code at 0x0000f960:
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(EE) I810(0): cannot continue

strace.out:

write(0, "Primary V_BIOS segment is: 0xc00"..., 34) = 34
open("/dev/mem", O_RDWR)                = 8
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0x4024a000
close(8)                                = 0
open("/dev/cpu/mtrr", O_WRONLY)         = -1 ENOENT (No such file or directory)
open("/proc/mtrr", O_WRONLY)            = 8
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = 0
ioctl(8, MTRRIOC_GET_ENTRY, 0xbffffb10) = -1 EINVAL (Invalid argument)
munmap(0x4024a000, 4096)                = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
vm86old(0x850e1b0)                      = -1 ENOSYS (Function not implemented)

	ENOSYS ???!

write(0, "(EE) ", 5)                    = 5
write(2, "I810(0): ", 9)                = 9
write(0, "I810(0): ", 9)                = 9
write(2, "unknown reason for exception\n", 29) = 29
write(0, "unknown reason for exception\n", 29) = 29

I wrote a test prog:

#define __NR_vm86old            113
#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
long __res; \
__asm__ volatile ("int $0x80" \
        : "=a" (__res) \
        : "0" (__NR_##name),"b" ((long)(arg1))); \
}
_syscall1(int,vm86old,void*,ptr);
int main() {
    vm86old(0);
    return 0;
}

compiled (with dietlibc) and straced it:

execve("./a.out", ["./a.out"], [/* 16 vars */]) = 0
vm86old(0)                              = -1 EFAULT (Bad address)
_exit(0)                                = ?

How can vm86old from X return ENOSYS??
I have no more ideas how to proceed from here.
--
vda

Re: X does not start. vm86old returns ENOSYS??

[Brian Gerst]

Denis Vlasenko wrote:
> How can vm86old from X return ENOSYS??
> I have no more ideas how to proceed from here.

Are you trying to run a 32-bit X server on a 64-bit kernel?  x86-64 does 
not support vm86 mode.

--
				Brian Gerst

Re: X does not start. vm86old returns ENOSYS??

[Denis Vlasenko]

On Wednesday 20 October 2004 17:14, Brian Gerst wrote:
> Denis Vlasenko wrote:
> > How can vm86old from X return ENOSYS??
> > I have no more ideas how to proceed from here.
> 
> Are you trying to run a 32-bit X server on a 64-bit kernel?  x86-64 does 
> not support vm86 mode.

x86-64 with i845 chipset?! You must be kidding.
--
vda

Re: X does not start. vm86old returns ENOSYS??

[Brian Gerst]

Denis Vlasenko wrote:
> On Wednesday 20 October 2004 17:14, Brian Gerst wrote:
> 
>>Denis Vlasenko wrote:
>>
>>>How can vm86old from X return ENOSYS??
>>>I have no more ideas how to proceed from here.
>>
>>Are you trying to run a 32-bit X server on a 64-bit kernel?  x86-64 does 
>>not support vm86 mode.
> 
> 
> x86-64 with i845 chipset?! You must be kidding.

There are (or will be) Intel x86-64 chips.

--
				Brian Gerst

Re: X does not start. vm86old returns ENOSYS??

[Stas Sergeev]

Hi.

Denis Vlasenko wrote:
> How can vm86old from X return ENOSYS??
I think you can't trust what vm86()/vm86old()
returns, concerning strace. These 2 syscalls
returns different non-zero values on *success*,
which, I think, strace just doesn't get right.
Of course it can also return the reasonable
errors, like EFAULT as in your test program -
its just that copy_from_user() failed when
you specified NULL.
I am not sure where exactly the ENOSYS comes
from. My wild guess is that strace expects
0 on success and the negative value on error,
but any positive value is an indication that
the syscall is not implemented.
At least I've always seen ENOSYS in an strace
logs for vm86() - this is normal.

> I have no more ideas how to proceed from here.
Sorry for not being able to help much.

Re: X does not start. vm86old returns ENOSYS?? -- solved

[Denis Vlasenko]

On Wednesday 20 October 2004 16:53, Denis Vlasenko wrote:
> Hi Stas, all,
>
> I have put my hard drive, which holds working desktop
> Linux system, into another box.
> Linux starts w/o problem, but X does not.
>
> Video is an i845. Madrake 9 install on the same box
> starts X just fine.
>
> I booted into 'my' Linux again, mounted partition
> with working Mandrake, chrooted into it, tried to start X.
> The same result, does not work.

Turned out that Mandrake was working because it was booted
via lilo whereas "my" Linux was booted via DOS-based loader.

When I started "my" Linux via lilo, everything worked just fine.

Heh. Proper solution is probably to teach X to not use int10.
--
vda

Re: X does not start. vm86old returns ENOSYS?? -- solved

[Stas Sergeev]

Hi.

Denis Vlasenko wrote:
> Turned out that Mandrake was working because it was booted
> via lilo whereas "my" Linux was booted via DOS-based loader.
> When I started "my" Linux via lilo, everything worked just fine.
Have you tried the "vga_reset" tool of
svgalib? It is intended to solve exactly
that problem (but it doesn't seem to work
right with some modern video cards like mine).

> Heh. Proper solution is probably to teach X to not use int10.
It also looks like int10 module of XFree
could check whether or not the int vector
is really pointing to the vbios, before
calling it.