Bug#390172: Bug still exists in 1.1.1-17
Update: I inserted a log statement before hw/xfree86/x86emu/decode.c:122 to just print on the stderr that it was emulating an instruction at a certain address. The result of running that was that I got a 500MB log file in seconds, with it executing instructions all over the BIOS. I had 12 million log statements, executing 4214 unique addresses. The most popular addresses were executed half a million times each. I thought these BIOSes were meant to just display a quick status message on the monitor and then poke a few values here and there into memory. Sounds like something is running away big time. I can confirm that the graphics card works fine in dual-head with a 32-bit processor, so I don't think it is the BIOS itself that is stuffing it up. Any further ideas? Matthew -- "To err is human; to really louse things up requires root privileges." -- Alexander Pope, slightly paraphrased -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390172: Bug still exists in 1.1.1-17
Matthew Wakeling wrote: > On Tue, 20 Feb 2007, Brice Goglin wrote: >> Once the X server is stuck using 99% of CPU, could you try attaching a >> GDB with something like: >>*gdb* -p $(*pidof* *X*) >> (as root). I should help us have an idea what's going on. > > I have gdb connected now. I'm afraid my experience with gdb is rather > limited. In any case, I have a backtrace, unfortunately without any > line numbers: You will have to use a server recompiled with debugging symbols to get line numbers. You can do that by looking at http://wiki.debian.org/HowToGetABacktrace. Replace 'hello' with 'xserver-xorg-core'. Once it is built and installed, restart X, and reattach gdb as previously. You should get more details in the backtrace. > (gdb) backtrace > #0 0x2b9f1ab62fcd in X86EMU_exec () from > /usr/lib/xorg/modules/libint10.so > #1 0x2b9f1ab527f5 in xf86ExecX86int10 () from > /usr/lib/xorg/modules/libint10.so > #2 0x2b9f1ab5355c in xf86ExtendedInitInt10 () from > /usr/lib/xorg/modules/libint10.so > #3 0x2b9f1aa2e213 in ATIPreInit () from > /usr/lib/xorg/modules/drivers/atimisc_drv.so > #4 0x0045f72c in InitOutput () > #5 0x00430d8f in main () If you do 'c' for continue, wait a little bit, hit ctrl-c and look at the backtrace again, do you get the same backtrace? Try this a couple times. It might help us know which function is looping endlessly. This is already interesting anyway. There have been some problems with x86emu recently. We'll see what you get with debugging enabled. Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390172: Bug still exists in 1.1.1-17
On Tue, 20 Feb 2007, Brice Goglin wrote: Once the X server is stuck using 99% of CPU, could you try attaching a GDB with something like: *gdb* -p $(*pidof* *X*) (as root). I should help us have an idea what's going on. I have gdb connected now. I'm afraid my experience with gdb is rather limited. In any case, I have a backtrace, unfortunately without any line numbers: (gdb) backtrace #0 0x2b9f1ab62fcd in X86EMU_exec () from /usr/lib/xorg/modules/libint10.so #1 0x2b9f1ab527f5 in xf86ExecX86int10 () from /usr/lib/xorg/modules/libint10.so #2 0x2b9f1ab5355c in xf86ExtendedInitInt10 () from /usr/lib/xorg/modules/libint10.so #3 0x2b9f1aa2e213 in ATIPreInit () from /usr/lib/xorg/modules/drivers/atimisc_drv.so #4 0x0045f72c in InitOutput () #5 0x00430d8f in main () Which is considerably shorter than I expected. I'm not sure if that's any help. Let me know if you want me to type more commands into gdb. I'll leave it connected for the moment, as I'm sitting at a different computer at the moment and sshing in. Matthew -- Software suppliers are trying to make their software packages more 'user-friendly' Their best approach, so far, has been to take all the old brochures, and stamp the words, 'user-friendly' on the cover. -- Bill Gates -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390172: Bug still exists in 1.1.1-17
Matthew Wakeling wrote: > When it fails, the X process is busy-looping, using 99% of CPU. > Killing it fails, but kill -9 succeeds. Trying to run X again crashes > the whole system, so I need to reboot after each attempt in order to > get my working X back. Once the X server is stuck using 99% of CPU, could you try attaching a GDB with something like: *gdb* -p $(*pidof* *X*) (as root). I should help us have an idea what's going on. Thanks for taking time to debug this. And sorry for making you reboot too often. thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390172: Bug still exists in 1.1.1-17
On Tue, 20 Feb 2007, Brice Goglin wrote: You will have to use a server recompiled with debugging symbols to get line numbers. Well, all the interesting stuff is in libint10, so I'll probably limit myself to recompiling that. If you do 'c' for continue, wait a little bit, hit ctrl-c and look at the backtrace again, do you get the same backtrace? Try this a couple times. It might help us know which function is looping endlessly. About half the time I get the same, and the other half I get #0 0x2b9f1ab52c32 in write_w () from /usr/lib/xorg/modules/libint10.so #1 0x2b9f1ab50c70 in run_bios_int () from /usr/lib/xorg/modules/libint10.so #2 0x2b9f1ab52154 in int_handler () from /usr/lib/xorg/modules/libint10.so #3 0x2b9f1ab52789 in x86emu_do_int () from /usr/lib/xorg/modules/libint10.so #4 0x2b9f1ab62fc6 in X86EMU_exec () from /usr/lib/xorg/modules/libint10.so #5 0x2b9f1ab527f5 in xf86ExecX86int10 () from /usr/lib/xorg/modules/libint10.so #6 0x2b9f1ab5355c in xf86ExtendedInitInt10 () from /usr/lib/xorg/modules/libint10.so #7 0x2b9f1aa2e213 in ATIPreInit () from /usr/lib/xorg/modules/drivers/atimisc_drv.so #8 0x0045f72c in InitOutput () #9 0x00430d8f in main () I'll just go and recompile... Matthew -- And why do I do it that way? Because I wish to remain sane. Um, actually, maybe I should just say I don't want to be any worse than I already am. - Computer Science Lecturer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390172: Bug still exists in 1.1.1-17
On Tue, 20 Feb 2007, Matthew Wakeling wrote: Well, all the interesting stuff is in libint10, so I'll probably limit myself to recompiling that. Okay, done. Most of the time, I get: #0 0x2b0911cbffcd in X86EMU_exec () at ../../../../hw/xfree86/int10/../x86emu/decode.c:121 #1 0x2b0911caf7f5 in xf86ExecX86int10 (pInt=0x773200) at ../../../../hw/xfree86/int10/xf86x86emu.c:41 #2 0x2b0911cb055c in xf86ExtendedInitInt10 (entityIndex=, Flags=0) at ../../../../hw/xfree86/int10/generic.c:271 #3 0x2b0911b8b213 in ATIPreInit () from /usr/lib/xorg/modules/drivers/atimisc_drv.so #4 0x0045f72c in InitOutput () #5 0x00430d8f in main () but sometimes I get: #0 write_w (pInt=0x773200, addr=846412, val=0) at ../../../../hw/xfree86/int10/generic.c:542 #1 0x2b0911cadc70 in run_bios_int (num=, pInt=0x773200) at ../../../../hw/xfree86/int10/helper_exec.c:141 #2 0x2b0911caf154 in int_handler (pInt=0x773200) at ../../../../hw/xfree86/int10/xf86int10.c:56 #3 0x2b0911caf789 in x86emu_do_int (num=) at ../../../../hw/xfree86/int10/xf86x86emu.c:27 #4 0x2b0911cbffc6 in X86EMU_exec () at ../../../../hw/xfree86/int10/../x86emu/decode.c:56 #5 0x2b0911caf7f5 in xf86ExecX86int10 (pInt=0x773200) at ../../../../hw/xfree86/int10/xf86x86emu.c:41 #6 0x2b0911cb055c in xf86ExtendedInitInt10 (entityIndex=, Flags=0) at ../../../../hw/xfree86/int10/generic.c:271 #7 0x2b0911b8b213 in ATIPreInit () from /usr/lib/xorg/modules/drivers/atimisc_drv.so #8 0x0045f72c in InitOutput () #9 0x00430d8f in main () or: #0 0x2b0911cbffaf in X86EMU_exec () at ../../../../hw/xfree86/int10/../x86emu/decode.c:53 #1 0x2b0911caf7f5 in xf86ExecX86int10 (pInt=0x773200) at ../../../../hw/xfree86/int10/xf86x86emu.c:41 #2 0x2b0911cb055c in xf86ExtendedInitInt10 (entityIndex=, Flags=0) at ../../../../hw/xfree86/int10/generic.c:271 #3 0x2b0911b8b213 in ATIPreInit () from /usr/lib/xorg/modules/drivers/atimisc_drv.so #4 0x0045f72c in InitOutput () #5 0x00430d8f in main () Hope that helps. Matthew -- sed -e '/^[when][coders]/!d;/^...[discover].$/d;/^..[real].[code]$/!d ' <`locate dict/words` -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390172: Bug still exists in 1.1.1-17
Matthew Wakeling wrote: > Hi all. Julien asked me to check if the bug still exhibits if I use > the open-source nvidia drivers instead of the closed-source drivers. > The answer is yes, it does. Exactly the same thing happens. I have > attached my config and log files. Seeing this failure while loading int10 reminds me of other problems that we were able to diagnose by looking at stderr of X (symbol linking problems). Could you try to reproduce after redirecting both the stdout and stderr of X to files and send us these files ? Thank you Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
