From owner-freebsd-current@FreeBSD.ORG Mon Apr 12 09:06:32 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 E4B7D16A4CF for ; Mon, 12 Apr 2004 09:06:31 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id F33D743D48 for ; Mon, 12 Apr 2004 09:06:30 -0700 (PDT) (envelope-from freebsd-current@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BD3x7-0005Sy-00 for ; Mon, 12 Apr 2004 18:06:29 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Apr 2004 18:06:29 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Apr 2004 18:06:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Mon, 12 Apr 2004 09:06:27 -0700 Lines: 83 Message-ID: References: <200403241430.29558.jhb@FreeBSD.org> <200403291609.44559.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.7.6 Sender: news Subject: Re: puc(4) device not attaching issue in -current: WORKING 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: Mon, 12 Apr 2004 16:06:32 -0000 (saved for context, see comments below). John Baldwin wrote: > 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. I believe the recent PCI Heads UP commit fixed my other 4 BARs since it now detects it and attaches properly. I can now get FASTINTR to work with APIC on this card too. Unfortunately APIC breaks my USB mouse, so I have to revert to using it as PS/2. -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired);