Hello, I have been trying to make Xorg work with my MGA G450 card. One problem I stumbled upon was the MGA driver trying to map the video memory through libpciaccess, which failed with ENXIO (no such device or address).
Upon inspection it turns out that the libpciaccess x86_pci.c generic code uses mmap() on /dev/mem. While MAKEDEV does create a /dev/mem device with '/hurd/storeio --no-cache mem' as its translator, it seems GNU Mach does not have such a device (antrik suggested on #hurd yesterday that oskit-mach might). On the other hand, using '/hurd/storeio --no-cache iopl' for /dev/mem seems to fix the problem (my X server crashes a little later). I beleive using the iopl device directly as is done for the Xorg server (hw/xfree86/os-support/hurd/hurd_video.c) in libpciaccess could work as well, though my attempt at this apparently did not completely work (one line was missing in the Xorg.log compared to the "/dev/mem = iopl" solution, and my Linux X server logs, regarding detection of the video bios). I'd be glad to create a bug report and/or submit a patch, but I'm a little lost about what should do what: * should MAKEDEV create /dev/mem using the iopl device instead of the non-existing 'mem' ? (and does this really work?) * should it not create it at all? * should libpciaccess have some Mach-specific code similar to the Xorg code? By the way, some other problems I have (I will investigate those further): * Using the VESA driver, the X server crashes with SIGILL. The backtrace shown suggests this happens in the int10 code. * I'm able to use gdb on the X server through the network but when I try to rebuild the xorg-server source package with DEB_BUILD_OPTIONS=debug,nostrip, I get a segfault from libtool. (Could someone confirm they have this problem as well?) Thanks for any advice/suggestion you might have, -- Jérémie Koenig <[email protected]> http://jk.fr.eu.org/
