From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 12:54:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BAD916A4CE for ; Wed, 31 Mar 2004 12:54:59 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0609643D31 for ; Wed, 31 Mar 2004 12:54:59 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 15769 invoked from network); 31 Mar 2004 20:54:55 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 31 Mar 2004 20:54:55 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i2VKsMDF048661; Wed, 31 Mar 2004 15:54:24 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 29 Mar 2004 16:09:44 -0500 User-Agent: KMail/1.6 References: <200403241430.29558.jhb@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403291609.44559.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: othermark Subject: Re: puc(4) device not attaching issue in -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 20:54:59 -0000 On Monday 29 March 2004 10:39 am, othermark wrote: > John Baldwin wrote: > > On Tuesday 23 March 2004 05:58 pm, othermark wrote: > >> Doug White wrote: > >> > On Tue, 23 Mar 2004, othermark wrote: > >> >> none0@pci0:6:1: class=0x070002 card=0x00000000 chip=0x01811407 > >> >> rev=0x00 hdr=0x00 > >> >> vendor = 'Lava Computer Manufacturing Inc' > >> >> device = 'Lava Octopus PCI Ports 5-8' > >> >> class = simple comms > >> >> subclass = UART > >> >> > >> >> device 6.1 has chip 0x018111407=and pucdata.c has only has an entry > >> >> for 0x0180, so I'm not sure how it was picking up 0x0181 in earlier > >> >> releases, or that it still does and something else is blocking it > >> >> from happening... > >> > > >> > What happens if you add that PCI ID to the driver? > >> > >> If I add a duplicate the entry in pucdata.c so it looks like this: > >> > >> > >> /* Lava Computers Octopus-550 serial ports */ > >> { "Lava Computers Octopus-550 8-port serial part B", > >> NULL, > >> { 0x1407, 0x0181, 0, 0 }, > >> { 0xffff, 0xfffc, 0, 0 }, > > > > The 0xfffc is a mask meaning that this matches 0x0180, 0x0181, 0x0182, > > and 0x0183 by the way, so you don't need an extra entry. Can you do a > > boot -v? I'm curious if the second device has its BAR's setup. > > I've attached a verbose boot to this message. How do you tell if the BAR > is setup or not? The map lines for the dump of PCI config registers. Here is your working device: $PIR: 0:5 INTA routed to irq 5 found-> vendor=0x1407, dev=0x0180, revid=0x00 bus=0, slot=5, func=0 class=07-00-02, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type 4, range 32, base 0000f888, size 3, enabled map[14]: type 4, range 32, base 0000f890, size 3, enabled map[18]: type 4, range 32, base 0000f898, size 3, enabled map[1c]: type 4, range 32, base 0000f8a0, size 3, enabled And below it is the one that isn't working: $PIR: 0:5 INTA routed to irq 5 found-> vendor=0x1407, dev=0x0181, revid=0x00 bus=0, slot=5, func=1 class=07-00-02, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x0480, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type 1, range 32, base feaff000, size 12, enabled map[14]: type 4, range 32, base 0000fc40, size 6, enabled map[18]: type 1, range 32, base fe700000, size 20, enabled Note that the working one has 4 BARs (10, 14, 18, and 1c) that are all I/O ports (type 4) and 8 bytes long (2 ^ size). The second one only has 3 bars (10, 14, and 18), of which only the second is an I/O port (the other two are memory) and which have very different sizes. There must be some other way to talk to the other 4 ports or perhaps the board needs to be configured somehow in order to work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org