Bugzilla – Bug 197190
IA64: Xserver shutdown freezes machine w/ R420 + flat panels
Last modified: 2007-03-15 18:58:14 UTC
See log files.
Created attachment 95237 [details] Xorg.0.log
Created attachment 95238 [details] strace X
# ll /sys/bus/pci/devices/ total 0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:00:01.0 -> ../../../devices/pci0001:00/0001:00:01.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:00:02.0 -> ../../../devices/pci0001:00/0001:00:02.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:00:03.0 -> ../../../devices/pci0001:00/0001:00:03.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:00:04.0 -> ../../../devices/pci0001:00/0001:00:04.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:01:02.0 -> ../../../devices/pci0001:00/0001:00:02.0/0001:01:02.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:01:02.1 -> ../../../devices/pci0001:00/0001:00:02.0/0001:01:02.1 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0001:01:02.2 -> ../../../devices/pci0001:00/0001:00:02.0/0001:01:02.2 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0002:00:01.0 -> ../../../devices/pci0002:00/0002:00:01.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0003:00:01.0 -> ../../../devices/pci0003:00/0003:00:01.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0003:00:01.1 -> ../../../devices/pci0003:00/0003:00:01.1 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0005:00:00.0 -> ../../../devices/pci0005:00/0005:00:00.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0005:00:00.1 -> ../../../devices/pci0005:00/0005:00:00.1 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0006:00:00.0 -> ../../../devices/pci0006:00/0006:00:00.0 lrwxrwxrwx 1 root root 0 Aug 4 17:20 0006:00:00.1 -> ../../../devices/pci0006:00/0006:00:00.1
> (II) Addressable bus resource ranges are > (II) OS-reported resource ranges: > (II) OS-reported resource ranges after removing overlaps with PCI: > (II) All system resource ranges: I think we're still missing some IA64 specific patches here. This is on my TODO list. Thanks for the reminder. :-)
I wonder if it is this one? Not sure if brouwer is such a system. ------------------------------------------------------------------- Fri Mar 24 16:48:46 CET 2006 - sndirsch@suse.de - p_pci-ce-x.diff: * fixes PCI bus scanning on CE systems (pci-pci bridges) (Bug #147261) /work/SAVE/oldpackages/stable/xorg-x11/xorg-x11-20060801/p_pci-ce-x.diff Needs to be applied to xorg-x11-server package. Otherwise you need to wait until I adjusted about 70 patches to the new X.Org packages. This will need some time ...
I think I was wrong. Isn't it the domain suport, which was still missing? Andreas, I've added you to Cc of Bug #197572, so you're up-to-date to PCI/IA64 patches we're currently preparing. The PCI domain patch is still completely untested and not applied to our xorg-x11-server package yet.
This PCI scan issue is resolved by now (by the PCI domain patch of Bug #197572) - I tried the new RPMs, but now we run into a different problem - at least on machine 'brouwer'. (gdb) run Starting program: /usr/bin/Xorg X Window System Version 7.1.0 Release Date: Fri Aug 25 08:50:06 UTC 2006 X Protocol Version 11, Revision 0, Release 7.1 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux brouwer 2.6.18-rc4-2-default #1 SMP Tue Aug 8 09 :58:49 UTC 2006 ia64 Build Date: 25 August 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug 25 11:22:17 2006 (==) Using config file: "/etc/X11/xorg.conf" [tcsetpgrp failed in terminal_inferior: Operation not permitted] (EE) Failed to load module "rfbkeyb" (module does not exist, 0) (EE) Failed to load module "rfbmouse" (module does not exist, 0) (WW) RADEON: No matching Device section for instance (BusID PCI:1536:0:1) found (WW) RADEON: No matching Device section for instance (BusID PCI:1280:0:1) found (**) RADEON(0): RADEONPreInit Program received signal SIGILL, Illegal instruction. 0x20000000005cfb80 in _inb (port=<value optimized out>) at ../sysdeps/unix/sysv/linux/ia64/ioperm.c:156 156 ret = *addr; (gdb) bt #0 0x20000000005cfb80 in _inb (port=<value optimized out>) at ../sysdeps/unix/sysv/linux/ia64/ioperm.c:156 #1 0x40000000000dbab0 in inb (port=972) at ./../shared/ia64Pci.c:134 #2 0x2000000004e164f0 in stdReadMiscOut (hwp=<value optimized out>) at vgaHW.c:262 #3 0x2000000004e166b0 in vgaHWGetIOBase (hwp=0x6000000000182f10) at vgaHW.c:1810 #4 0x2000000000cf43c0 in RADEONPreInit () from /usr/lib/xorg/modules/drivers//radeon_drv.so #5 0x40000000000b5910 in InitOutput (pScreenInfo=0x600000000014b0a8, argc=1, argv=0x607ffffffec3ed98) at xf86Init.c:596 #6 0x4000000000039ba0 in main (argc=1, argv=0x607ffffffec3ed98, envp=0x607ffffffec3eda8) at main.c:369 (gdb) quit
hw/xfree86/os-support/shared/ia64Pci.c: * We use special in/out routines here since Altix platforms require the * use of the sysfs legacy_io interface. The legacy_io file maps to the I/O * space of a given PCI domain; reads and writes are used to do port I/O. * The file descriptor for the file is stored in the upper bits of the * value passed in by the caller, and is created and populated by * xf86MapDomainIO. hw/xfree86/os-support/bus/linuxPci.c: * xf86MapDomainIO - map I/O space in this domain * * Each domain has a legacy ISA I/O space. This routine will try to * map it using the Linux sysfs legacy_io interface. If that fails, * it'll fall back to using /proc/bus/pci. Breakpoint 1, xf86MapDomainIO (ScreenNum=0xffffffff, Flags=0x2, Tag=0x5000000, Base=0x0, Size=0x1) at linuxPci.c:723 723 int domain = xf86GetPciDomain(Tag); (gdb) c Continuing. Breakpoint 3, linuxOpenLegacy (Tag=0x5000000, name=0x4000000000330a48 "legacy_io") at linuxPci.c:636 636 if (!path) (gdb) u 647 linuxOpenLegacy (Tag=<value optimized out>, name=0x4000000000330a48 "legacy_io") at linuxPci.c:647 647 fd = open(path, O_RDWR); (gdb) p path $6 = 0x60000000001779e0 "/sys/class/pci_bus/0000:00/legacy_io" ^^^^^^^ # ll /sys/class/pci_bus/ total 0 drwxr-xr-x 2 root root 0 Sep 1 11:40 0001:00 drwxr-xr-x 2 root root 0 Aug 31 14:02 0001:01 drwxr-xr-x 2 root root 0 Aug 31 14:02 0002:00 drwxr-xr-x 2 root root 0 Aug 31 14:02 0003:00 drwxr-xr-x 2 root root 0 Aug 31 14:02 0004:00 drwxr-xr-x 2 root root 0 Aug 31 14:02 0005:00 drwxr-xr-x 2 root root 0 Aug 31 14:02 0006:00
Obviously domain is wrong. Probably the domain support in linuxOpenLegacy() needs to be changed: [...] domain = xf86GetPciDomain(Tag); bus = PCI_BUS_NO_DOMAIN(PCI_BUS_FROM_TAG(Tag)); Other functions use domain = PCI_DOM_FROM_TAG(tag); bus = PCI_BUS_NO_DOMAIN(PCI_BUS_FROM_TAG(tag)); instead. Would be worth a try ...
Andreas, how is comment #8 related to comment #7?
How about reading the comment? "Altix platforms require the use of the sysfs legacy_io interface".
Are you sure you debug the issue in comment #7?
Of course I am.
Ok. I'm asking since it looks completely different to me. It looks more like the initial issue to me and not the SIGILL.
They are obviously the same issue. Just read the comments in the cited files.
You're right. After setting domain to "1" in linuxOpenLegacy() via gdb the X Server succesfully freezed the machine in RADEONPreInit instead of terminating with SIGILL ...
Entered OS MCA handler. PSP=20000000fff211a0 cpu=0 monarch=1 cpu 0, MCA inconsistent r12 and r13, original stack not modified OS MCA slave did not rendezvous on cpu 1 1 out of 2 cpus in kdb, waiting for the rest, timeout in 10 second(s) ...1 cpu is not in kdb, its state is unknown Entering kdb (current=0xe000003007138000, pid 0) on processor 0 due to KDB_ENTER()
Ok. I tried my patch in comment #9. Result is, that it didn't change anything. Additionally it crashed the machine again. I should better stop debugging for today. :-)
Reassigning to our current PCI domain specialist. :-)
Have been testing IA64 support on chandrasekhar: Ok, according to a first test at least the PCI domain support does work now. The cards are correctly detected. However, the machine crashes deep down in RADEONPreInit() if I let xf86GetPciDomain return the apparently correct domain number. All of the domain patches have originally been created by SGI, right? Egbert is definitvely more fluently in this area...
FWIW xf86GetPciDomain() seems to be supposed to return the domain of the host bridge - as in contrast to Stefans opinion I'm not a PCI specialist at all, I might need some help from Egbert to understand what xf86GetPciDomain() is *exactly* supposed to return. (In reply to comment #8) > (gdb) u 647 > linuxOpenLegacy (Tag=<value optimized out>, > name=0x4000000000330a48 "legacy_io") at linuxPci.c:647 > 647 fd = open(path, O_RDWR); > (gdb) p path > $6 = 0x60000000001779e0 "/sys/class/pci_bus/0000:00/legacy_io" > ^^^^^^^ This is probably to pciBusInfo_t not correctly filled out. I need more meta information for that. Egbert? Of course, this is only the first part of this issue. The machine freeze is yet to be debugged.
The machine finally freezes in xf86InitInt10(), if xf86GetPciDomain() is instructed to return the domain of the Gfx hardware. Of which I'm still not convinced it is correct. I think this basically happens because the special bridge scaning code for Altrix isn't called, because the chipset is not detected any longer. Why? The scaning code explicitely asks for some device on bus 0, and invokes a pciReadLong() - which explicitely does nothing if bus == 0. As this function hasn't been changed since 2003, I wonder how this could ever work... I guess this is a long standing bug. Even if you skip that check it won't work, as the device is tried to be opened in domain 0 - which does not exist. Ok, if you fix this check, it still segfaults due to not using legacy_io. If you fix an (probably) obvious bug in xf86GetPciDomain(), the machine freezes again in xf86InitInt10(). Only this time the PCI maps look much better...
Update: Machine freezes in xf86ReadBIOS(). So this is not an x86 emulator issue (yet).
Int vector is mapped with mmap (0, 0x4000, PROT_READ, MAP_SHARED, "/dev/mem", 0) The machine freezes on the memcopy operation (void)memcpy(Buf, (void *)(ptr + Offset), Len); directly after the mmap. Buf = some memory location, ptr=return from mmap(), Offset = 0, Len=0x600. This is probably something for sgi to investigate, as it seems to involve either kernel space or some wrong pci initialization. BTW - is mapping /dev/mem the right way on a domain based machine? Stefan, are the patched xorg packages already available in stable? Have to test them first...
(In reply to comment #25) > Stefan, are the patched xorg packages already available in stable? Have to > test them first... Yes.
Ok, just verified that all patches are included. Xorg from SLES10 works in a chroot environment, so it is not the kernel at fault.
Created attachment 101924 [details] Fix INT10 compiler options. Another patch needed for IA64 support. Upto now the INT10 module was compiled with -D_PC for *all* architectures (not only ix86 and x86_64).
The servers works fine now, if the dri and glx modules are not loaded. Strangely enough Xorg 7.2 loads dri and glx even if no 'Load "dri"' is given in the config file, but this is a different bug. The server still crashes the machine on shutdown, though. Will investigate this after PPC (bug #202133).
Matthias, what hw were you seeing the crash on shutdown on? What is the prom version (cat /proc/sgi_prominfo/node*/version)? I've been running xorg-x11-server-7.2-4 (factory) + the patch from comment #28 on my prism deskside box without any problems for a couple days now. Great work! It'd be nice to get this stuff upstream, so we don't have to continually struggle with this. Sorry our guys dropped the ball on that one. We have an (old) xorg bug with the previous pci domain patches at: Bug 5000 Domain support does not work for SGI Altix machines https://bugs.freedesktop.org/show_bug.cgi?id=5000 Should we use this bug, and obsolete the old patches? You did all the work on this, so it's your call how you'd like to handle it.
I have recently upgraded the prom to 4.61 (was 4.56 before).
Andreas, good - that's the latest and recommended one. I was testing with 4.61 as well.
Yet it still crashes the system.
Created attachment 102483 [details] salinfo oem rpm (decodes firmware blob in mca records) Andreas, is it getting an MCA? If so, can you install this rpm, which will decode the oem-specific MCA information in the MCA record.
Created attachment 102484 [details] xorg.conf for dual-X2 prism Here's the xorg.conf I'm using (successfully). I've got two X2 cards in my prism. I think you have two X3?
Created attachment 102536 [details] MCA dump
Greg, I will push the changes upstream of course, as soon as it is clear that we do not have any (read: any known) regressions with the patches. So far I'm quite confident. I'd like to find out where the Xserver crashes on shutdown on our machine - though this will probably not affect the patches so far. Regarding the dri module: If the module section is empty, the Xserver loads a default set, which includes dri. This change has only been introduced recently.
Matthias/Andreas, the MCA is because of a PIO timeout to address prb address state to rp DID LEN BE R 31 0x0040230003c8 0x2 1 0 0x0c0 0 0x01 0 | `timeout which, on a prism deskside is a register on the ATI card in 0005:00:00.0. If this is like the last time we saw something like this (see bug #140420), the card wedges, which causes a timeout on the bus, and an MCA is raised. If I'm interpreting it correctly, that would make the register offset 0x03c8 which in radeon_reg.h looks like RADEON_FP_V2_SYNC_STRT_WID? The MCA record shows an iip of 0xa000000100077a40. What function is this in your System.map? This may tell us if timed out on a read or write to this location. I think we can also tell it from info in the MCA record, but I'll need to go find someone who knows where to look for this.
System.map-2.6.18.1-7-default a000000100077900 t rebalance_tick a0000001000782c0 T scheduler_tick
I found out prbs are reads, wrbs are writes, so this is a read timeout.
Ok, so it appears I got wrong info previously. One of our platform guys told me the following: -------- PRB 31 shows: prb address state to rp DID LEN BE R 31 0x0040230003c8 0x2 1 0 0x0c0 0 0x01 0 ..which means it was a write (R=0). The MCA was due to a BERR, which is used by sw to trigger an MCA. If the time-out was due to a read, the MCA would have triggered due to a bus check due to a hard fail (on shub1). --------- So, if I got the register right, the only write to RADEON_FP_V2_SYNC_STRT_WID is in RADEONRestoreCrtc2Registers(), and looks to only happen for a kind of flat planel, which would make sense why I don't see it (with 2 CRTs).
Andreas/Matthias, did you figure out if that's where we were running into problems in the radeon driver?
Current server is just hanging after (**) RADEON(0): Map Changed ! Applying ...
When I wait long enough it crashes the system.
Created attachment 104308 [details] MCA dump
Timeout on a write to the same register as before. From mca: prb address state to rp DID LEN BE R 31 0x0040230003c8 0x2 1 0 0x0c0 0 0x01 0 What version of the xorg-x11-server package is this from? factory is showing xorg-x11-server-7.2-13 as the latest (which I'm running with success). Andreas, are you running something newer?
We already have -17 internally, which contains an update to current CVS. Will probably appear on factory soon.
Ok, thanks Andreas. I'll take a look once that shows up on the external mirrors.
Stefan, looks like Matthias' off by one fix got dropped by accident: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=1b94c117e0f294ef2f89bf24d45ba7a8e45efe35 With this patch added back in, xorg-x11-server-7.2-23 works for me on an SGI Prism.
I've readded this patch for STABLE/Factory/Buildservice. Unfortunately to late for RC1.
The MCA at shutdown remains anyway.
Thanks for confirming, Andreas. Have you been able to run it under a debugger and see if RADEONRestoreCrtc2Registers() is where you hit it?
The last time I tried RADEONRestoreCrtc2Registers wasn't hit.
I scrounged up some hardware today and can reproduce this now. It only occurs on the combination of X3 cards (R420) plus flat panels. It doesn't occur on X2 cards (R350) and flat panels, nor X3 cards and CRTs. I'll dig into it more tomorrow.
This is where we're dying in shutdown. The same thing happens if you try to switch to one of the text consoles (ctrl-alt-f1) when the xserver is up. hw/xfree86/os-support/linux/lnx_init.c:xf86CloseConsole() 327 /* Back to text mode ... */ 328 if (ioctl(xf86Info.consoleFd, KDSETMODE, KD_TEXT) < 0) <--
So this is an issue in the kernel module? Seems to be for me...
Yeah, looks like it. That's what I'm looking at now.
Great. Thanks for looking into this, Greg! I'll set this bug to needinfo on you for now.
We die in drivers/video/console/vgacon.c:vga_set_palette() vga_w(state.vgabase, VGA_PEL_MSK, 0xff); for (i = j = 0; i < 16; i++) { vga_w(state.vgabase, VGA_PEL_IW, table[i]); <--- when we do the first write to VGA_PEL_IW (0x3c8) with a value of 0. Since the write times out, I suspect it causes the card to wedge. We go through vga_set_palette twice before successfully, once on bootup and once on X startup. We know this hardware combination works fine in SLES10, so to narrow it down, I tried it with a sles10 kernel (required a change to valid_mmap_phys_addr_range() so the /dev/mem mmap didn't fail) and the radeon driver at tag XORG-7_0 (which I believe is SLES10?). This failed the same way, so it's back looking like an xorg issue. I'll probably need a kick in the right direction at where to start looking next.
>We know this hardware combination works fine in SLES10, so to narrow it down, >I tried it with a sles10 kernel (required a change to >valid_mmap_phys_addr_range() so the /dev/mem mmap didn't fail) and the radeon >driver at tag XORG-7_0 (which I believe is SLES10?). Not at all. We had tons of patches on top of X.Org 6.9's radeon driver --> see xorg-x11-driver-video package of SLES10.
(In reply to comment #59) > We die in drivers/video/console/vgacon.c:vga_set_palette() > > vga_w(state.vgabase, VGA_PEL_MSK, 0xff); > for (i = j = 0; i < 16; i++) { > vga_w(state.vgabase, VGA_PEL_IW, table[i]); <--- > > when we do the first write to VGA_PEL_IW (0x3c8) with a value of 0. Since the > write times out, I suspect it causes the card to wedge. We go through > vga_set_palette twice before successfully, once on bootup and once on X > startup. In that case I guess the *previous* access to some register is bogus. Do you have the possibility to catch a backtrace of the call, so one can estimate what has been happening before?
To answer Stefan's previous question, I just compiled the radeon10b driver from SLES10 (ati-1_0_branch) and this meets with the same demise, but works fine under SLES10. Matthias, the call chain in the kernel to vga_set_palette() is vt_ioctl do_unblank_screen redraw_screen set_palette vgacon_set_palette vga_set_palette
Created attachment 109281 [details] bogus int10 patch By accident, I broke the loading of the int10 module with this bogus patch, but the machine didn't MCA on xserver shutdown! Go figure. I'll start looking here. Matthias, any idea why this would happen?
(In reply to comment #49) > Stefan, looks like Matthias' off by one fix got dropped by accident: > http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=1b94c117e0f294ef2f89bf24d45ba7a8e45efe35 > > With this patch added back in, xorg-x11-server-7.2-23 works for me on an > SGI Prism. Andreas made a different patch to address issues in Bug #229278. I'll attach it.
Created attachment 110177 [details] p_pci-off-by-one.diff ------------------------------------------------------------------- Mon Dec 18 17:08:00 CET 2006 - schwab@suse.de - Fix off-by-one in pci multi-domain support [#229278].
*** Bug 229278 has been marked as a duplicate of this bug. ***
Do not apply; Domain 0 is really considered special, not only in this piece of sh^H^Hcode but also in other parts of the Xserver. I've already tested exactly this approach, it failed.
Ok. I've reverted this change.
See Bug #197572, patch p_pci-domain.diff, compare comments 22 + 27. I'm sorry, I don't remember the exact circumstances.
So what's the status of this bug? Greg, do you have any success in finding out why disabling the int10 module removed the crash? Is the int10 module needed at all for this machine?
I had to give back my loaned hardware around Christmas time, so I don't have the equipment to reproduce this anymore, and hadn't been able to look at it much beyond my last comments. It sure doesn't appear we need the int10 module at all, though. I just removed it entirely on my system, and X comes up fine. Mike or Jonathan, do you know if we rely on the int10 module for setting anything up?
Ping?
Greg hasn't had the time or hardware to look at this more, so I've moved the needinfo to Jonathan Lim, who should be able to start looking at this.
Regarding the following trace obtained when Xorg exits: ddxGiveUp, xf86Init.c xf86CloseConsole, lnx_init.c ioctl(xf86Info.consoleFd, KDSETMODE, KD_TEXT) vt_ioctl, vt_ioctl.c do_unblank_screen, vt.c update_screen(x) -> redraw_screen(x, 0) set_palette, vt.c vgacon_set_palette vga_set_palette I wasn't able to confirm that do_unblank_screen was called because the machine hung as soon as it went into vt_ioctl. There are two other instances where vga_set_palette is called: 1. During Xorg startup: console_callback, vt.c change_console complete_change_console, vt_ioctl.c switch_screen(x) -> redraw_screen(x, 1) set_palette vgacon_set_palette vga_set_palette 2. When the blanked console comes back on following an input event: console_callback, vt.c poke_blanked_console, vt.c do_unblank_screen, vt.c vgacon_blank vga_set_palette What version of openSUSE and Xorg worked with this hardware combination before? Also, if I replace radeon with vga in xorg.conf, the machine panics when Xorg starts up. The last thing written in Xorg.0.log is (II) VGA(0): initializing int10.
Greg, I think this is one last question to you ;-) Do you remember the configuration that worked for you?
I believe it worked up until openSUSE switched over to the modular xorg code base (and rebased on current bits). From the xorg-x11-server changelog, this looks like the end of June 2006. SLES10 works fine, so that is probably your best stable point.
I've found the fix for this bug: --- xorg-server-1.2.0/hw/xfree86/int10/Makefile.am.O 2007-01-22 21:39:16.000000000 -0800 +++ xorg-server-1.2.0/hw/xfree86/int10/Makefile.am 2007-03-13 04:13:54.000000000 -0700 @@ -29,6 +29,9 @@ endif if INT10_X86EMU AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_X86EMU -DNO_SYS_HEADERS \ $(XORG_CFLAGS) $(EXTRA_CFLAGS) +if LINUX_IA64 +AM_CFLAGS += -DNO_LONG_LONG +endif INCLUDES = $(XORG_INCS) -I$(srcdir)/../x86emu libint10_la_SOURCES = \ $(COMMON_SOURCES) \ --- xorg-server-1.2.0/hw/xfree86/int10/Makefile.in.O 2007-03-13 04:10:14.000000000 -0700 +++ xorg-server-1.2.0/hw/xfree86/int10/Makefile.in 2007-03-13 04:14:38.000000000 -0700 @@ -571,6 +571,7 @@ COMMON_SOURCES = \ @INT10_VM86_TRUE@AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_VM86_LINUX $(XORG_CFLAGS) $(EXTRA_CFLAGS) @INT10_X86EMU_TRUE@AM_CFLAGS = $(I386_VIDEO_CFLAGS) -D_X86EMU -DNO_SYS_HEADERS \ @INT10_X86EMU_TRUE@ $(XORG_CFLAGS) $(EXTRA_CFLAGS) +@LINUX_IA64_TRUE@AM_CFLAGS += -DNO_LONG_LONG @INT10_VM86_TRUE@INCLUDES = $(XORG_INCS) @INT10_X86EMU_TRUE@INCLUDES = $(XORG_INCS) -I$(srcdir)/../x86emu Can someone please verify? Thanks.
OMFG. That looks like (again) something was lost in the autoconfigifying process... Thanks a lot, Jonathan. The implementations in hw/xfree86/x86emu/prim_ops.c for w/ and w/o long long types are vastly different. I don't see at once why the long long version should fail, but that code *could* have a endianess bug. Stefan, please apply this patch, it certainly doesn't do any harm. We can test as soon as the package is built.
fixed for STABLE/Factory. xorg-x11-server.changes: [...] ------------------------------------------------------------------- Wed Mar 14 15:43:46 CET 2007 - sndirsch@suse.de - bug197190-ia64.diff: * missing -DNO_LONG_LONG for IA64 (Bug #197190)
> The implementations in hw/xfree86/x86emu/prim_ops.c for w/ and w/o long long > types are vastly different. I don't see at once why the long long version > should fail, but that code *could* have a endianess bug. In .../x86emu/types.h, right before __HAS_LONG_LONG__ is defined, there's a comment indicating "Currently only for Linux/32bit".
The why is x86-64 not defining it?
This can definitely not be the real bug.
Hmm ... in X.Org 6.9 "-DNO_LONG_LONG" is even set for *all* architectures, so __HAS_LONG_LONG__ is never set. extras/x86emu/include/x86emu/types.h: [...] /* Currently only for Linux/32bit */ #undef __HAS_LONG_LONG__ #if defined(__GNUC__) && !defined(NO_LONG_LONG) #define __HAS_LONG_LONG__ #endif programs/Xserver/hw/xfree86/int10/Imakefile: [...] X86EMUDEFINES = -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG ... programs/Xserver/hw/xfree86/os-support/linux/int10/x86emu/Imakefile: [...] X86EMUDEFINES = -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG ...
Created attachment 124590 [details] x86emu.diff
So this obsoletes the patch mentioned in comment #77?
I definitely hope so.
So could you give it a try?
(In reply to comment #83) > Hmm ... in X.Org 6.9 "-DNO_LONG_LONG" is even set for *all* architectures, so > __HAS_LONG_LONG__ is never set. And on i386 the emulator isn't used at all... Andreas' patch looks very reasonable, so I will probably push it upstream. I'm unsure, though, whether __HAS_LONG_LONG__ will work after that patch, because the code path is very different, and I assume it hasn't been tested for a *long* time. Did you test this, Andreas? Stefan, maybe it's a good idea to disable Jonathan's patch and use Andreas' for the next round of testing. The long long code path is certainly much faster than the other one.
This also fixes bug 248195. NO_LONG_LONG should definitely be removed.
Patch applied. Fixed for STABLE/Factory.
Committed upstream.
Started and stopped Xorg without problems on my machine using the new fix.