Re: USB ethernet problem
On Tue, Nov 05, 2002 at 09:05:38PM +0300, Anton Vinokurov wrote: > Hi! > > I am running FreeBSD 4.7-release and try to use ATEN UC10T USB-to-Ethernet > adapter. Unfortunately it causes my system to print something like: > kue0: watchdog timeout > kue0: usb error on tx: TIMEOUT > following by freeze. I got this problem while forwarding 50pps/64kbit UDP > packet stream which comes from Cisco ATA186 voice gateway in several minutes > after call starts. Same time, OpenBSD 3.2 with a similar if_kue.c driver > works fine at least under one day voice traffic load. I tried original > driver and altq modifed with no success. > Could someone suggest me a way to fix my problem? > It could be one of the many USB bugs that are in -stable. Does the problem happen under -current too? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg37858/pgp0.pgp Description: PGP signature
USB ethernet problem
Hi! I am running FreeBSD 4.7-release and try to use ATEN UC10T USB-to-Ethernet adapter. Unfortunately it causes my system to print something like: kue0: watchdog timeout kue0: usb error on tx: TIMEOUT following by freeze. I got this problem while forwarding 50pps/64kbit UDP packet stream which comes from Cisco ATA186 voice gateway in several minutes after call starts. Same time, OpenBSD 3.2 with a similar if_kue.c driver works fine at least under one day voice traffic load. I tried original driver and altq modifed with no success. Could someone suggest me a way to fix my problem? Anton L. Vinokurov, CCNA [EMAIL PROTECTED] NeTAMS Development Team To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible solution for USB Ethernet problem
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: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible solution for USB Ethernet problem
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. 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. Hm, I'll have to find someone with an 82371SB board and borrow that for a while to get a trace and see what is happening on the wire. This problem should show up with any bulk-64b device if you are right. Cheers, Nick > I downloaded a copy of the Intel UHCI spec document from > ftp://download.intel.com/design/usb/UHCI11D.PDF and scrutinized it > for a while. On page 17, it describes the MAXP bit in the command > register. The description reads: > > Max Packet (MAXP). 1=64 bytes, 0=32 bytes. This bit selects the > maximum packet size that can be used for full speed bandwitdh > reclamation at the end of a frame. This value is used by the > Host Controller to determine whether it should initiate another > transaction based on the time remaining in the SOF counter. Use > of reclamation packets larger than the programmed size will > cause a Babble error if executed during the critical window at > frame end. The Babble error results in the offending endpoint > being stalled. Software is responsible for ensuring that any > packet which could be executed under bandwidth reclamation be > within this size limit. > > The ADMtek part is documented to use 64-byte USB packets for frame > transfers. However, /sys/dev/usb/uhci.c:uhci_run() never sets the > MAXP bit in the command register when it starts the controller running. > I modified uhci_run() to include the UHCI_CMD_MAXP bit and now the > ADMtek ethernet controller sends and receives 1500-byte frames with > no problems. > > The question is, how should this be handled? Should the UHCI_CMD_MAXP > bit be set all the time, or just when high speed devices are attached > to the bus? The Intel manual seems to imply that it's safe to leave this > bit enabled all the time, however I can't test this since I only have > the one USB device. Also, should something similar be done with OHCI > controllers, or do they handle this sort of thing correctly? > > -Bill > > -- > = > -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu > Work: [EMAIL PROTECTED] | Center for Telecommunications Research > Home: [EMAIL PROTECTED] | Columbia University, New York City > = > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > = > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible solution for USB Ethernet problem
we were usug both IHCI and UHCI which is why we didn't mention it. we DID have a problem one one of them (which seemed unrelated) but I can't remember which. It was reported by other people around the same time so we didn't connect it with our driver. On Tue, 21 Dec 1999, Bill Paul wrote: > Previously I mentioned that I was having trouble sending full sized > ethernet frames (1500 bytes) over USB using my ADMtek AN986 Pegasus > eval board. The problem turned out to be in the uhci driver, however > I'm not certain exactly how to incorporate my fix. > > The problem I was seeing was that large frames would trigger babble > errors, which would cause an endpoint halt and wedge the RX or TX pipe. > Julian brought up another driver written by Doug Ambrisko which appeared > to be able to transfer 1500-byte frames without any trouble. However, > neither he nor Doug bothered to mention if their test machines had UHCI > or OHCI hubs. Given what I've learned, I suspect they were OHCI. > I downloaded a copy of the Intel UHCI spec document from > ftp://download.intel.com/design/usb/UHCI11D.PDF and scrutinized it > for a while. On page 17, it describes the MAXP bit in the command > register. The description reads: > > Max Packet (MAXP). 1=64 bytes, 0=32 bytes. This bit selects the > maximum packet size that can be used for full speed bandwitdh > reclamation at the end of a frame. This value is used by the > Host Controller to determine whether it should initiate another > transaction based on the time remaining in the SOF counter. Use > of reclamation packets larger than the programmed size will > cause a Babble error if executed during the critical window at > frame end. The Babble error results in the offending endpoint > being stalled. Software is responsible for ensuring that any > packet which could be executed under bandwidth reclamation be > within this size limit. > > The ADMtek part is documented to use 64-byte USB packets for frame > transfers. However, /sys/dev/usb/uhci.c:uhci_run() never sets the > MAXP bit in the command register when it starts the controller running. > I modified uhci_run() to include the UHCI_CMD_MAXP bit and now the > ADMtek ethernet controller sends and receives 1500-byte frames with > no problems. > > The question is, how should this be handled? Should the UHCI_CMD_MAXP > bit be set all the time, or just when high speed devices are attached > to the bus? The Intel manual seems to imply that it's safe to leave this > bit enabled all the time, however I can't test this since I only have > the one USB device. Also, should something similar be done with OHCI > controllers, or do they handle this sort of thing correctly? > > -Bill > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible solution for USB Ethernet problem
Bill Paul writes: | Previously I mentioned that I was having trouble sending full sized | ethernet frames (1500 bytes) over USB using my ADMtek AN986 Pegasus | eval board. The problem turned out to be in the uhci driver, however | I'm not certain exactly how to incorporate my fix. | | The problem I was seeing was that large frames would trigger babble | errors, which would cause an endpoint halt and wedge the RX or TX pipe. | Julian brought up another driver written by Doug Ambrisko which appeared | to be able to transfer 1500-byte frames without any trouble. However, | neither he nor Doug bothered to mention if their test machines had UHCI | or OHCI hubs. Given what I've learned, I suspect they were OHCI. We used both OHCI to itself for initial debugging then an OHCI machine to UHCI and a UHCI to UHCI. So it didn't seem that saying what stack we used was important since they both worked for us. This was -current as of a week or so ago. We did run into an issue with OHCI, in that if we plugged in any USB device after the machine was booted we would get the td_??? panic. So we had to have the device plugged in when we booted the machine. After the machine was up we could unplug it and plug it back in. For testing we did ping's and ftp's of /kernel and it worked okay. I also ran netperf and got 3.4Mbits/sec with MTU's of 900 & 1500. So we are not saying the USB stack is perfect, but it worked for us. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Possible solution for USB Ethernet problem
Previously I mentioned that I was having trouble sending full sized ethernet frames (1500 bytes) over USB using my ADMtek AN986 Pegasus eval board. The problem turned out to be in the uhci driver, however I'm not certain exactly how to incorporate my fix. The problem I was seeing was that large frames would trigger babble errors, which would cause an endpoint halt and wedge the RX or TX pipe. Julian brought up another driver written by Doug Ambrisko which appeared to be able to transfer 1500-byte frames without any trouble. However, neither he nor Doug bothered to mention if their test machines had UHCI or OHCI hubs. Given what I've learned, I suspect they were OHCI. I downloaded a copy of the Intel UHCI spec document from ftp://download.intel.com/design/usb/UHCI11D.PDF and scrutinized it for a while. On page 17, it describes the MAXP bit in the command register. The description reads: Max Packet (MAXP). 1=64 bytes, 0=32 bytes. This bit selects the maximum packet size that can be used for full speed bandwitdh reclamation at the end of a frame. This value is used by the Host Controller to determine whether it should initiate another transaction based on the time remaining in the SOF counter. Use of reclamation packets larger than the programmed size will cause a Babble error if executed during the critical window at frame end. The Babble error results in the offending endpoint being stalled. Software is responsible for ensuring that any packet which could be executed under bandwidth reclamation be within this size limit. The ADMtek part is documented to use 64-byte USB packets for frame transfers. However, /sys/dev/usb/uhci.c:uhci_run() never sets the MAXP bit in the command register when it starts the controller running. I modified uhci_run() to include the UHCI_CMD_MAXP bit and now the ADMtek ethernet controller sends and receives 1500-byte frames with no problems. The question is, how should this be handled? Should the UHCI_CMD_MAXP bit be set all the time, or just when high speed devices are attached to the bus? The Intel manual seems to imply that it's safe to leave this bit enabled all the time, however I can't test this since I only have the one USB device. Also, should something similar be done with OHCI controllers, or do they handle this sort of thing correctly? -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
