From owner-cvs-all@FreeBSD.ORG Sat Oct 21 19:08:45 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27F1416A415; Sat, 21 Oct 2006 19:08:45 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1730D43D49; Sat, 21 Oct 2006 19:08:43 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.0.5) with ESMTP id md50000580115.msg; Sat, 21 Oct 2006 23:08:23 +0400 Received: from dialup-chibis.gfk.ru ([10.0.6.45]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Oct 2006 23:08:14 +0400 Date: Sat, 21 Oct 2006 23:09:37 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@free.home.local To: John-Mark Gurney In-Reply-To: <20061021174934.GU23971@funkthat.com> Message-ID: <20061021222955.B549@free.home.local> References: <200610202128.k9KLSBgo059305@repoman.freebsd.org> <20061021142416.G1198@free.home.local> <20061021174934.GU23971@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Oct 2006 19:08:15.0032 (UTC) FILETIME=[42959B80:01C6F544] X-Spam-Processed: mx.gfk.ru, Sat, 21 Oct 2006 23:08:23 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDAV-Processed: mx.gfk.ru, Sat, 21 Oct 2006 23:08:25 +0400 Cc: cvs-src@FreeBSD.org, Yuriy Tsibizov , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/pci pci.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 19:08:45 -0000 >>> 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.