From owner-freebsd-hardware@FreeBSD.ORG Mon Nov 16 21:31:10 2009 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A48921065670 for ; Mon, 16 Nov 2009 21:31:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 65EBB8FC1A for ; Mon, 16 Nov 2009 21:31:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 03AC046EAE; Mon, 16 Nov 2009 16:31:10 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 05EDC8A020; Mon, 16 Nov 2009 16:31:09 -0500 (EST) From: John Baldwin To: freebsd-hardware@freebsd.org, David Wolfskill Date: Mon, 16 Nov 2009 15:38:26 -0500 User-Agent: KMail/1.9.7 References: <20091114052429.GF1649@albert.catwhisker.org> In-Reply-To: <20091114052429.GF1649@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911161538.26899.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 16 Nov 2009 16:31:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: Msg: no prefetched decode (going from stable/6 -> stable/7) X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:31:10 -0000 On Saturday 14 November 2009 12:24:29 am David Wolfskill wrote: > I admit that I don't know what "no prefetched decode" means in this > context, or what I can or should do about it. > > But the same hardware running stable/6 does not issue that whine, and > the laptop in question does see the additional PCI devices on the > docking station when running stable/6, but issues the above whine, and > fails to "see" the additional PCI devices in the docking station running > any of stable/7, stable/8, or head (9.0-CURRENT). > > And while there are certainly advances in many respects in going to > newer versions of FreeBSD, I'm a little hard-pressed to understand how > this qualifies. :-} > > A bit of background: > > My laptop is parts from 3 Dell laptops -- 2 Inspiron 8200s and 1 > Latitude C840. I use the FreeBSD bootloader, and have 4 distinct > bootable slices on the disk. At this time: > > * slice 1: / and /usr for stable/6 > * slice 2: / and /usr for stable/7 > * slice 4: / and /usr for stable/8 > * slice 4: / and /usr for head (9.0-CURRENT); also swap, as well as a > few other partitions (e.g., /var) that are mounted to the > same place regardless of which slice is booted. > > For last night's BAFUG meeting, Julian had volunteered to demonstrate > vimage. He needed access to a machine running stable/8 or head with > multiple NICs. > > I volunteered the use of my laptop, as it has a couple of NICs in its > chassis, and I recalled that when I had run stable/6, FreeBSD saw the > wired NIC in the docking station. > > So I brought a couple of PCI NICs to stick in the dockinig station, > figuring that would give us 5 NICs (not counting Firewire -- or > anything I could shove in a PCCard slot), which should be adequate. > > But as I was building stable/8 (running stable/7 at teh time), I noticed > that "ifconfig" output didn't show the additional 3 NICs. > > So this evening, I booted each of the slices in turn to single user > mode, then (in each case) entered: > > * fsck -p && mount -a > * csh > * uname -a >/var/tmp/pciconf.N > * pciconf -lv >>!$ > * dmesg >/vat/tmp/dmesg.N > > (where "N" was one of "6", "7", "8", or "9", according to the version of > FreeBSD being run at the time). > > I've attached the resulting files. > > Here's the tail end of diff -u pciconf.{6,7}: > > ... > -iwi0@pci2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 > +iwi0@pci0:2:3:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > - device = 'MPCI3B driverIntel PRO/Wireless 2200BG' > + device = 'driverIntel PRO/Wireless 2200BG (MPCI3B)' > class = network > -pcib3@pci2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 rev=0x04 hdr=0x01 > +pcib3@pci0:2:12:0: class=0x060400 card=0x00000000 chip=0x00221011 rev=0x04 hdr=0x01 > vendor = 'Digital Equipment Corporation' > - device = '21150-AA PCI to PCI Bridge' > + device = 'PCI-PCI Bridge (DC21150-AA)' > class = bridge > subclass = PCI-PCI > -xl1@pci3:1:0: class=0x020000 card=0x905510b7 chip=0x905510b7 rev=0x30 hdr=0x00 > - vendor = '3COM Corp, Networking Division' > - device = '3C905-TX Fast Etherlink 10/100 PCI TX NIC' > - class = network > - subclass = ethernet > -dc0@pci3:2:0: class=0x020000 card=0xf0041385 chip=0x000211ad rev=0x20 hdr=0x00 > - vendor = 'Lite-On Communications Inc' > - device = 'KNE110TX Kingston EtheRx KNE110TX PCI Fast Ethernet Adapter' > - class = network > - subclass = ethernet > -atapci0@pci3:5:0: class=0x01018f card=0x06461095 chip=0x06461095 rev=0x07 hdr=0x00 > - vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' > - device = 'PCI-0646 EIDE Adapter (Single FIFO)' > - class = mass storage > - subclass = ATA > -ahc0@pci3:7:0: class=0x010000 card=0x78809004 chip=0x80789004 rev=0x01 hdr=0x00 > - vendor = 'Adaptec Inc' > - device = 'AIC-7880P Ultra/Ultra Wide SCSI Chipset' > - class = mass storage > - subclass = SCSI > -xl2@pci3:8:0: class=0x020000 card=0x00a81028 chip=0x920010b7 rev=0x6c hdr=0x00 > - vendor = '3COM Corp, Networking Division' > - device = '3C905 CX-TX-M Fast EtherLink for PC Management NIC' > - class = network > - subclass = ethernet > > And here's the part of the output from "diff -u dmesg.{6,7}" that > inspired the Subject: > > ... > @@ -381,172 +412,34 @@ > iwi0: bpf attached > iwi0: bpf attached > iwi0: [MPSAFE] > +iwi0: [ITHREAD] > iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > pcib3: at device 12.0 on pci2 > +pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xf000-0xffff > pcib3: memory decode 0xfa000000-0xfbffffff > -pcib3: prefetched decode 0xfff00000-0xfffff > -ACPI: Found matching pin for 3.5.INTA at func 0: 11 > -ACPI: Found matching pin for 3.1.INTA at func 0: 11 > -ACPI: Found matching pin for 3.2.INTA at func 0: 11 > -ACPI: Found matching pin for 3.7.INTA at func 0: 11 > -ACPI: Found matching pin for 3.8.INTA at func 0: 11 > +pcib3: no prefetched decode In this case, newer message is just more correct. Notice that in the old printf the ending address is less than the starting address for the prefetch range. 7 is just smart enough to print this out more correctly. I do wonder if 7 does better if you disable ACPI? I'm curious if ACPI somehow thinks that the PCI device is not enabled. Presumably it would not have made it this far though if that were the case. Can you do something like 'pciconf -r pci0:3:1:0 0x0:0x40' under a working (6) and broken (7+) kernel with the docking station attached? -- John Baldwin