From owner-freebsd-hackers Wed Dec 22 8: 7:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 11C54154E9 for ; Wed, 22 Dec 1999 08:07:15 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id LAA09261; Wed, 22 Dec 1999 11:11:17 -0500 From: Bill Paul Message-Id: <199912221611.LAA09261@skynet.ctr.columbia.edu> Subject: Re: Possible solution for USB Ethernet problem To: n_hibma@webweaving.org Date: Wed, 22 Dec 1999 11:11:15 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: from "Nick Hibma" at Dec 22, 99 11:43:54 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2624 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Nick Hibma had to walk into mine and say: > > Nice catch (of yet another stupidity in the UHCI controllers). > > In 1.3.1 they say that 'the preSOF point also prevents a packet that may > not fit in the remaining frame period from being initiated.' So the UHCI > controller should not start a 64 byte transfer if the MAXP is not set. > > What happens probably is that the controller does start it and ends up > overruning its SOF. > > The reason for not setting it is that using a MAXP of 32 is more > efficient. However, up to now I;ve not seen a device with a packet size > of 32 (only 64, 16 and smaller). So switching it on should be no > problem. It better not be, since this is the only way this device will work. Leave it to me to get all the oddball hardware. > You have a 'Intel 82371SB (PIIX3) USB controller' ? If so, we might be > looking at a problem with the 1.0 specification. (please post > 'dmesg|grep USB'). I have never had a BABBLE error here, which indicates > to me that there was a problem with the 82371SB, which has been solved > in the AB/EB. isab0: at device 7.0 on pci0 isa0: on isab0 ata-pci0: at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 uhci0: irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered So this is an AB/EB hub. The machine is a Dell Latitude CPi R400GT laptop, running FreeBSD 4.0-19991221-CURRENT. Note that there appears to be abother unrelated problem, which is that kldloading the usb KLD module into a kernel without USB support compiled in doesn't work: the machine panics immediately after printing the "uhci0: " line above. I bet a quarter it's trying to do yet another tsleep() when it's not really able to. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message