From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 15 14:03:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A47EF37B401 for ; Tue, 15 Jul 2003 14:03:32 -0700 (PDT) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A64543F85 for ; Tue, 15 Jul 2003 14:03:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14706 invoked from network); 15 Jul 2003 21:03:31 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 15 Jul 2003 21:03:31 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6FL3SGI020861; Tue, 15 Jul 2003 17:03:29 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <1058288512.1026.30.camel@klotz.local> Date: Tue, 15 Jul 2003 17:03:44 -0400 (EDT) From: John Baldwin To: Martin cc: freebsd-hackers@freebsd.org Subject: Re: USB device programming with ugen [Solved] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 21:03:33 -0000 On 15-Jul-2003 Martin wrote: > On Tue, 2003-07-15 at 09:04, Terry Lambert wrote: >> The attach should have failed, if it didn't have an interrupt. > > Somehow uhci0 didn't have interrupt, but it managed to find the webcam > on ugen0. Don't ask me why. I have attached my logs below. > You can see many devices sharing same irq. I don't know what line 2 > means exactly, but if it means that my USB-controller was assigned > irq 11, it could lock several important devices at once, if IRQs are > not handled properly. > > In new logs uhci0 was found configured on irq 9. It means we routed uhci0 an interrupt and gave it IRQ 11 based on what the tables said. The BIOS gave it 9. The interrupt being wrong would explain the hang since PCI interrupts are level-triggered. > Earlier dmesg (from /var/log/messages): > Jul 11 20:35:58 xxx kernel: uhci0: controller> port 0xc000-0xc01f at device 7.2 on pci0 > Jul 11 20:35:58 xxx kernel: pci_cfgintr: 0:7 INTD routed to irq 11 > ... > Jul 11 20:35:58 xxx kernel: ugen0: WINBOND W9967CF, rev 1.10/1.10, addr > 2 > ... > Jul 11 20:35:58 xxx kernel: sym0: <875> port 0xc400-0xc4ff mem > 0xe7002000-0xe7002fff,0xe7001000-0xe70010ff irq 11 at device 11.0 on > pci0 > ... > Jul 11 20:35:58 xxx kernel: atapci1: controller> port 0xd400-0xd4ff,0xd000-0xd003,0xcc00-0xcc07 irq 11 at > device 19.0 on pci0 > Jul 11 20:35:58 xxx kernel: ata2: at 0xcc00 on atapci1 > Jul 11 20:35:58 xxx kernel: atapci2: controller> port 0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 11 at > device 19.1 on pci0 > Jul 11 20:35:58 xxx kernel: ata3: at 0xd800 on atapci2 > > Now dmesg: > uhci0: port 0xc000-0xc01f irq > 9 at device 7.2 on pci0 > ... > ugen0: WINBOND W9967CF, rev 1.10/1.10, addr 2 > ... > sym0: <875> port 0xc400-0xc4ff mem > 0xe7002000-0xe7002fff,0xe7001000-0xe70010ff irq 11 at device 11.0 on > pci0 > ... > atapci1: port > 0xd400-0xd4ff,0xd000-0xd003,0xcc00-0xcc07 irq 11 at device 19.0 on pci0 > ata2: at 0xcc00 on atapci1 > atapci2: port > 0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 11 at device 19.1 on pci0 -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/