libpciaccess ROM read is thrice broken (was: X Hangs at "Initializing int10") try 2

[Alex Villací­s Lasso]

Resending as previous attempt complains attachments are too big.

All of the following applies to the stock linux 2.6 kernel from a fresh
installation of Fedora 10.

I have been looking into the int10 hang when initializing the BIOS of a 
secondary card. This is what I found:
- The function responsible for reading the ROM of the PCI video card is 
pci_device_linux_sysfs_read_rom() for the Fedora 10 case.
- This function pci_device_linux_sysfs_read_rom() is *not* exercised at 
all when using the primary display, even when an option such as UseBIOS 
is in effect. So this function might as well be broken and nobody with a 
single display would notice.
- pci_device_linux_sysfs_read_rom() is exercised when initializing a 
secondary display (using "vesa" in my case)

I introduced a bit of logging in the patch 
libpciaccess-partial-fix-with-debug.patch that outputs messages to a 
file in /tmp . The basic problem is that, despite all the sysfs dance to 
enable the ROM, the kernel terminates the read with 0 bytes when trying 
to read the ROM:

Reading ROM from /sys/bus/pci/devices/0000:00:09.0/rom into address 
0xb7f4a008
ROM size for /sys/bus/pci/devices/0000:00:09.0/rom is 32768 using 32768
Reading ROM from /sys/bus/pci/devices/0000:00:09.0/rom reached 0-sized 
read (EOF?) at offset 0
Dump of ROM from /sys/bus/pci/devices/0000:00:09.0/rom (0 bytes):
Reading ROM failed with short read, using /dev/mem to read from 0xdffe0000

I introduced an attempt at a fallback that calls 
pci_device_linux_devmem_read_rom() when the total amount read is less 
than the expected ROM size. In current git for libpciaccess, the buffer 
remains uninitialized and hangs the machine. I hoped that the fallback 
would be enough to read the ROM and fix this problem. However, I ran 
into another problem. The attempted fallback ends up using pread() on 
/dev/mem at the offset matching the one reported for the ROM. However, 
this failed with EINVAL (Invalid argument). By using strace on the stock 
X server and the modified libpciaccess library, I saw that the pread 
implementation calls into pread64() with an very big offset of 
18446744073172549632 (0xffffffffdffe0000), which is the required offset, 
sign-extended into 64 bits instead of zero-extended as required. This 
might point to a bug in glibc headers or code, but I worked around this 
by replacing the call with a pread64() call, as seen in 
libpciaccess-partial-fix-without-debug.patch

Now, here comes the third problem: the passed address makes pread64() 
return EFAULT (Invalid address). I did not have time to find out whether 
this address is intended or not. However 
libpciaccess-partial-fix-without-debug.patch is enough to replace the 
hang with a graceful exit that allows the user to sort-of regain control 
of the machine. Final strace is attached, search for EFAULT in the text.

Please comment on this. Details already posted at bug #18160

-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug-read-rom.log
Type: text/x-log
Size: 387 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081205/348c254e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpciaccess-partial-fix-with-debug.patch
Type: text/x-patch
Size: 3765 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081205/348c254e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpciaccess-partial-fix-without-debug.patch
Type: text/x-patch
Size: 1049 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081205/348c254e/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: salida-strace-x.txt.bz2
Type: application/x-bzip2
Size: 15157 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081205/348c254e/attachment-0003.bin>