Both Xorg 7.0 and Xorg 7.1 seem to go into an infinite loop when it tries to int10 boot my PCI ATI AIW (Mach64) on a AMD64 system. My primary video card is an AGP Radeon 9600. DRI or no-DRI makes no difference. Xorg 6.9 works OK. For Xorg 7.0, all I needed to do was take an Xorg 6.9 version of libint10.so to make it work. But Xorg 7.1 has a different ABI. After a little debugging, it seems X86EMU_exec is the culprit. I tried reverting the "minimal" changes in the int10 module from Xorg 7.1 to Xorg 6.9, but it made no difference. Workaround: If I limit the iterations of the "for"-loop to 4541000 iterations in X86EMU_exec, then I can get X to start. I got the number "4541000" from counting the iterations from the Xorg 6.9 boot and rounding up. I can supply debug logs and conf's if necessary for both versions.
Something alike here. After starting X I got 99 persent of system resources occupied by X and that is looks like somekind of loop. My log file stops at (II) Loading /usr/X11/lib64/modules/libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 7.1.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (II) TDFX(0): Softbooting the board (through the int10 interface). Fred, you are saing you finally start X. How?
(In reply to comment #1) > Something alike here. After starting X I got 99 persent of system resources > occupied by X and that is looks like somekind of loop. My log file stops at > (II) Loading /usr/X11/lib64/modules/libint10.so > (II) Module int10: vendor="X.Org Foundation" > compiled for 7.1.0, module version = 1.0.0 > ABI class: X.Org Video Driver, version 1.0 > (II) TDFX(0): Softbooting the board (through the int10 interface). > Fred, you are saing you finally start X. How? No TDFX line, of course, and sometimes it was a hard lock-up. I worked around it with the following patch in the xorg-server-X11R7.1-1.1.0/hw/xfree86/x86emu/decode.c file: --- old/xorg-server-X11R7.1-1.1.0/hw/xfree86/x86emu/decode.c 2006-02-10 14:00:27.000000000 -0800 +++ xorg-server-X11R7.1-1.1.0/hw/xfree86/x86emu/decode.c 2006-12-21 19:10:40.000000000 -0800 @@ -91,11 +91,12 @@ void X86EMU_exec(void) { u8 op1; + int cnt; M.x86.intr = 0; DB(x86emu_end_instr();) - for (;;) { + for (cnt=0;cnt<4541000;cnt++) { DB( if (CHECK_IP_FETCH()) x86emu_check_ip_access();) /* If debugging, save the IP and CS values. */ It is a hack definitely. The magic number 4541000 may not work for you. When I leave X to return to the console, the display on the softboot-ed adapter is messed up. It used to say something like, "ATI MACH64 P/N BIOS". Now, it's garbage. But at least I can get into X.
> I worked around it with the following patch in the > xorg-server-X11R7.1-1.1.0/hw/xfree86/x86emu/decode.c file: > > + for (cnt=0;cnt<4541000;cnt++) { Ye a i got it form your first message. And already made it. I didn't get the root of the evil. Why it hangs in the loop? Any way I suppose the bug is not take place in my configuration. I've made a mistake I did compile the X server with 2.6.19 kernel source and that is wrong. What I did: I modified loop same way you are talking about and added printk in the end of loop like: if (cnt>=4541000) {printk("loop finished at cnt = %i",cnt); And there was no messages appasred in log after X starts. So I remove patched string and came back to the original source and recompile xserver with 2.4.28 kernel headers. No I can assume that the infinite loop take no place for me. Sorry for disturb. Let as know if thing will change.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/138.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.