Date: Sat, 21 Oct 2006 10:49:34 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru> Cc: cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/pci pci.c Message-ID: <20061021174934.GU23971@funkthat.com> In-Reply-To: <20061021142416.G1198@free.home.local> References: <200610202128.k9KLSBgo059305@repoman.freebsd.org> <20061021142416.G1198@free.home.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Yuriy Tsibizov wrote this message on Sat, Oct 21, 2006 at 14:24 +0400:
> >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)
>
> what 'bad things' will not happen? I see that commited patch differs from
Running off the end of allocated memory...
> one you posted earlier on cvs-src which (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 capabile PCI cards in it, and VPD will
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...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061021174934.GU23971>