cvs commit: src/sys/dev/pci pci.c

[Yuriy Tsibizov]

>>> jmg         2006-10-20 21:28:11 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>>   sys/dev/pci          pci.c
>>> Log:
>>> fix tab indentation for CP and RV...
>>>
>>> If the length is zero, catch this early, instead of making dflen go
>>> negative
>>> and letting bad things happen...  We also check to see if RV (checksum) is
>>> 0, and handle that has a checksum failure...
>>>
>>> Properly handle checksum failures by not processing read-write VPD data,
>>> and removing all the found read-only data...
>>>
>>> Tested by:      oleg (dflen going negative)
>>

>> patch posted earlier on cvs-src (possibly) caused my Realtek PCIE
>> network card to change it's PCI id (as described in message to -current,
>> under 'RE:ASUS U5F hangs during PCI bus probe' subject).
>>
>> Are there any possibility to check arguments of pci_read_vpd_reg to make
>> shure it will write only in correct PCI configuration register?
>
> The patch is already does that... VPD only writes to the 4 bytes of
> config registers to slide the window for reading...  If you notice,
> pci_write_vpd_reg is ifdef'd out, and pci_read_vpd_reg will always
> write to the correct two bytes necessary to slide the window (unless
> memory gets corrupted which could happen w/o this patch)...
>
> I'm also puzzled by the dmesg's that you posted.. The broken-dmesg
> you posted doesn't have any vpd capable PCI cards in it, and VPD will

It was booted with snapshot ISO that does not contain your latest pci.c 
changes (it was build on Oct 2nd). And it enters pci_read_vpd() with your 
last pci.c changes (I had a printf() at start of code).

I had an idea of safety counter that will exit vpd code after some 
iterations, but unfortunately I was not able to boot it again from PXE, 
because PXE loader seems not to work when PCI IDs are changed.


> not do anything (including write to config space) if the VPD cap pointer
> doesn't exist...  The worse that will happen is when the VPD cap pointer
> exists, but the VPD data is corrupted, and you'll get something like:
> found-> vendor=0x109e, dev=0x036e, revid=0x11
>        bus=1, slot=6, func=0
>        class=04-00-00, hdrtype=0x00, mfdev=1
>        cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords)
>        lattimer=0x20 (960 ns), mingnt=0x10 (4000 ns), maxlat=0x28 (10000 ns)
>        intpin=a, irq=5
>        powerspec 2  supports D0 D3  current D0
>        VPD Ident: (null)
>        map[10]: type 3, range 32, base e9100000, size 12, enabled
>
> At a minimum you'll get the VPD Ident line, and I don't see it...  So,
> I currently can't see how my vpd patch would change the device..  I'm
> also puzzled by the wildly different values for card in your posted
> pciconf listing...

Yes, it was very strange to see 10/100 rl PCI ID with Gbit PCI-E re card. 
I can't imagine what people in ASUS service will think about such 
"downgrade" :-) I think, it was possible to add changed PCI id to re 
driver (and disable rl) and try to boot off CD, but it's too late now.

Is it possible to have a runaway VPD code to write 0x812911ec to PCI 
configuration space? It is possible that vendor ID (0x10ec) can't be 
changed this way, and this will result in 0x812911ec/0x812910ec PCI ID.

Can you try to ask people with desktop PCI-E cards based on Realtek 
8168/8111B card on non-production machine to check, does correct VPD data 
exist on this cards? I can try to do step-by step debug (exiting 
read_vpd() code after 1st, 2nd, .... loop iteration) when I come back from 
vacation.

And - without 'RV' changes it was booted several times without problems 
(it hangs in loop in pci_read_vpd(), but it was harmless to PCI IDs).

Yuriy.