Re: problem with patch 4.7.99.14-4.7.99.15.diff.bz2 in PCI detection

[Marc Aurele La France]

On Wed, 21 May 2008, [EMAIL PROTECTED] wrote:

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.



Okay, I've got the machine back and I've tested your patch with scanpci.
= The problem is corrected, XFree86 doesn't block anymore on this
111d:8018 chip.



I suppose it will be included in the next official patch ?


Yes it will, given I've already committed it.

Thanks for trying it out.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  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.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

Re: problem with patch 4.7.99.14-4.7.99.15.diff.bz2 in PCI detection

[Marc Aurele La France]

On Tue, 13 May 2008, [EMAIL PROTECTED] 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  (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 : 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:  [EMAIL PROTECTED] |
|  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.

Mahe.diff.gz
Description: Binary data

problem with patch 4.7.99.14-4.7.99.15.diff.bz2 in PCI detection

[loic . mahe]

Hello,

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.

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).


00:00.0 Host bridge: Intel Corporation 3200/3210 Chipset DRAM Controller 
(rev 01)
00:06.0 PCI bridge: Intel Corporation 3210 Chipset Host-Secondary PCI 
Express Bridge (rev 01)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 (rev 02)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 5 (rev 02)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 6 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface 
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 
port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
(rev 02)
00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA 
IDE Controller (rev 02)
01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E 
PCI-Express Fusion-MPT SAS (rev 04)
*02:00.0 PCI bridge: Integrated Device Technology, Inc.: Unknown device 
8018 (rev 0e)
03:02.0 PCI bridge: Integrated Device Technology, Inc.: Unknown device 
8018 (rev 0e)
03:04.0 PCI bridge: Integrated Device Technology, Inc.: Unknown device 
8018 (rev 0e)
04:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
04:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
06:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755 
Gigabit Ethernet PCI Express (rev 02)
07:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] 
ServerEngines (SEP1) (rev 02)

During the freeze, I noticed that lspci seems unhappy with what he 
detects, since all
device classes are detected as  (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 : 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.


Here is the end of /var/log/XFree86.0.log during the freeze :

(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x803c, mode1Res1 = 0x8000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,29f0 card 1734,1101 rev 01 class 06,00,00 hdr 
00
(II) PCI: 00:06:0: chip 8086,29f9 card , rev 01 class 06,04,00 hdr 
01
(II) PCI: 00:1a:0: chip 8086,2937 card 1734,10e0 rev 02 class 0c,03,00 hdr 
80
(II) PCI: 00:1a:1: chip 8086,2938 card 1734,10e0 rev 02 class 0c,03,00 hdr 
00
(II) PCI: 00:1a:2: chip 8086,2939 card 1734,10e0 rev 02 class 0c,03,00 hdr 
00
(II) PCI: 00:1a:7: chip 8086,293c card 1734,10e0 rev 02 class 0c,03,20 hdr 
00
(II) PCI: 00:1c:0: chip 8086,2940 card , rev 02 class 06,04,00 hdr 
81
(II) PCI: 00:1c:4: chip 8086,2948 card , rev 02 class 06,04,00 hdr 
81
(II) PCI: 00:1c:5: chip 8086,294a card , rev 02 class 06,04,00 hdr 
81
(II) PCI: 00:1d:0: chip 8086,2934 card 1734,10e0 rev 02 class