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.
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
