From owner-freebsd-mobile Wed Mar 5 6:33:52 2003 Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 487DC37B401 for ; Wed, 5 Mar 2003 06:33:50 -0800 (PST) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [133.11.205.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DF0943FB1 for ; Wed, 5 Mar 2003 06:33:48 -0800 (PST) (envelope-from tamaru@myn.rcast.u-tokyo.ac.jp) Received: from is1.mh.itc.u-tokyo.ac.jp (is1.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is1.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id 222C621811B for ; Wed, 5 Mar 2003 23:33:45 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) by is1.mh.itc.u-tokyo.ac.jp (8.12.8/8.11.3) with ESMTP id h25EXjWg029881 for ; Wed, 5 Mar 2003 23:33:45 +0900 Received: from gin.myn.rcast.u-tokyo.ac.jp (cognac.myn.rcast.u-tokyo.ac.jp [157.82.66.106]) by mailhosting.itc.u-tokyo.ac.jp (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AIA48665; Wed, 5 Mar 2003 23:33:44 +0900 (JST) Date: Wed, 05 Mar 2003 23:33:33 +0900 Message-ID: From: Hiroharu Tamaru To: freebsd-mobile@FreeBSD.ORG Subject: solved (Re: USB ether fails: watchdog timeout) In-Reply-To: References: User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org For the sake of record: With some discussions in bsd-usb ML, the issue is fixed in rev 1.118 of dev/usb/ohci.c committed by shiba@. It is waiting to be MFC'ed. At Tue, 25 Feb 2003 03:36:43 +0900, Hiroharu Tamaru wrote: > > Hi list, > > I have an "I/O DATA USB ETTXS" USB ether NIC (aue, Pegasus > II) which fails to work with Toshiba Libretto M3 (notebook) > on FreeBSD 4.2--5.0 (at least). > > From the reasons described below, I am suspecting if it were > to do with the OHCI controllor on Libretto M3, which is NEC > uPD 9210. > > ohci0: mem 0xffaff000-0xffafffff irq 11 at device 11.0 on pci0 > usb0: OHCI version 1.0 > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > > The only part that's not working seems to be the transmit > part. aue driver attaches and ifconfig succeeds, and tcpdump > even captures the packets on the wire. But once instructed > to send a packet (like ping or dhclient), > > aue0: watchdog timeout > > occurs (but receive side continues normally) and nothing is > sent. I added printfs to see the usb status code that's > acquired inside aue_watchdog after the call to > usbd_get_xfer_status, it turned out to be USB_NOT_STARTED. > 'ifconfig aue0'ing after this timeout shows OACTIVE flag on, > and it never drops until after 'ifconfig aue0 down' is > issued. > > And that was about everything I could try in the absence of > any knowledge for USB programming. > Could someone suggest snything to try with this? > > TIA. > > > PS: > This NIC works fine on a 5.0-RELEASE desktop box with a UHCI > host controller: > > uhci0: > port 0xd000-0xd01f irq 11 at device 31.2 on pci0 > > and also on a 4.7-STABLE desktop box with: > > uhci0: > port 0xd000-0xd01f irq 10 at device 31.2 on pci0 > > USB mice (ums) and USB floppy (umass,da0) work fine with > this Libretto, so the usb subsystem itself is not totally > broken. > > One other thing I might mention is that this Libretto > freezes when I try to use pccard and usb together, unless I > route the pccard (ToPic97) interrups via isa bus by: > hw.pcic.intr_path="1" > hw.pcic.irq="0" > > May be it is so because both pcic and ohci grabs irq 11 if > the pcic is pci routed where as in polling and isa routing > mode, ed0 that's plugged into the PCCard slot grabs irq3 and > thus there's no conflict. BIOS tells me that pci devices > all grab irq11 and is not configurable to anything else. > Most of the internal devices were disabled inside the BIOS > to make things simple during the test. > > FWIW, booting 5.0-RELEASE on this machine fails to find ata > ad0 disk at the very last step just before the login prompt, > unless acpi is disabled. > -- > Hiroharu Tamaru. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message