Bug#422077: xserver-xorg: more information
Brice Goglin wrote:
> I was wondering what you were talking about and where the good strace
> output was.
> Actually your previous mail probably got caught by the spam filter
> before being
> delivering to debian-x. Fortunately, it reached the BTS, so I found it.
>
> open("/sys/bus/pci/devices/0000:00:00.0/config", O_RDWR) = 7
> ioctl(7, 0x50434900, 0) = -1 ENOTTY (Inappropriate ioctl for device)
> close(7) = 0
> open("/sys/bus/pci/devices/0000:00:13.0/config", O_RDWR) = 7
> ioctl(7, IIOCNETDIF, 0) = -1 ENOTTY (Inappropriate ioctl for device)
> write(2, "\nFatal server error:\n", 21) = 21
> write(2, "xf86MapPciMem: Could not mmap PC"..., 118) = 118
>
> It's trying to open the root chipset and ATI board, looks ok:
> 00:00.0 Host bridge: Sun Microsystems Computer Corp. Ultra IIe
> 00:13.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
>
> The first ioctl above looks ok too (0x50434900 == PCIIOC_CONTROLLER).
> xf86GetPciDomain() returns 0 at this point, harmless.
>
> The second ioctl looks crap. IIOCNETDIF has nothing to do here.
Let's forget about this, looks like strace does not take the whole
32bits into account. So the ioctl command is probably right here.
It seems that the ioctl fails because the
/sys/bus/pci/devices/0000:00:00.0/config file does not have a ioctl
method in the kernel. From what I see on my machine, Xorg does not use
this code path on x86, which might explain while it works there and
fails on your machine.
One way to check this would to force Xorg to use ioctls on /proc files
instead of /sys as it did in Xorg 7.1. PCI files in /proc support these
ioctl fine, that may explain why Xorg 7.1 worked on your sparc. Booting
with a 2.4 kernel should force Xorg to use /proc. Another way would be
to umount /sys before starting Xorg (umount -l /sys might do the trick
if /sys is busy).
I will have to forward this bug upstream anyway, but please let me know
if it helps.
Brice
Reply to: