On Tue, 13 May 2008, loic.mahe@xxxxxxxxxxxxxx wrote: > I'am testing some Fujitsu-Siemens workstations which have the same video > chip : > 102b:0522 Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) > FSC TX150-S6 > FSC TX200-S4 > FSC RX100-S5 > The 3 computers have the same /etc/X11/XF86Config-4 file. > I've noticed a problem with the TX150-S6 when XFree86 starts : the process > gets stuck in the > PCI detection sequence on the first of 3 identical PCI chips (111d:8018). > After several minutes (between 5 and 10 minutes, I've not measured > exactly), XFree finished the start > sequence and works well after that. Well, the code no longer assumes multifunction devices have a zero function, which means the PCI scan now looks at all combinations of device and function numbers. So I would expect it to take slightly longer. But not by _that_ much. > These chips (111d:8018) are found only on the TX150-S6. > On the 2 other computers, XFree86 starts without problem. > Here is the lspci output for the TX150-S6. The chip which blocks the > XFree86 startup is prefixed > by an asterisk. Attached is a detailled output of lspci (-vv). [elided] > During the "freeze", I noticed that lspci seems unhappy with what he > detects, since all > device classes are detected as ffff (and chip revisions as ff). For > example, the video chip > which normally is : > 07:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] > ServerEngines (SEP1) (rev 02) > becomes : > 07:00.0 Class ffff: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines > (SEP1) (rev ff) > So the XFree86 PCI detection code seems to have a side effect on the > system. It is not a good idea to run two PCI scans simultaneously. And I can think of no way to prevent them. > Please note that XFree86 and the Linux kernel show no warning or error > messages at > all, the only problem is the very long start time for XFree. > I tested a previous build of XFree86, including patches up to > 4.7.99.5-4.7.99.6.diff.bz2. > This version doesn't show the problem. So I digged a little bit in the > patches released > after this one and I found that some modifications were done at the PCI > level. I finally > found that the problem is located in 4.7.99.14-4.7.99.15.diff.bz2, more > precisely in the > xc/programs/Xserver/hw/xfree86/os-support/bus/Pci.c file (which includes > the PCI detection > loop). > I suppressed the modifications on Pci.c from the > 4.7.99.14-4.7.99.15.diff.bz2 patch, rebuilded > XFree86 and the problem doesn't occur now. > So it is related to the recent modifications on the PCI code. > But I don't know where the problem exactly occurs in this file. I don't > have the time to track > line by line and I had to give the computer to someone else for a couple > of weeks. I suspect this is happening because these systems are capable of PCI Express. Please try the attached patch when you get the system back. It would be sufficient to check if the slowdown still occurs with the resulting scanpci binary. Thanks. Marc. +----------------------------------+----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: tsi@xxxxxxxxxxx | | 352 General Services Building +----------------------------------+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +----------------------------------+----------------------------------+ XFree86 developer and VP. ATI driver and X server internals.
Attachment:
Mahe.diff.gz
Description: Binary data
