Re: The rc.d mess strikes back
On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen wrote: > On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis wrote: >> >> I don't have much time to debug this, but I've not had problems with >> services starting too early on the systems I've been running with async >> dhcp. If there is a problem with the wait process we need to actually >> debug it. If the wait for a route/running interface isn't sufficent we >> should try to figure out what is. Synchronous dhcp sucks and yeilds >> justifed user complaints so it would be nice to kill it off. I switched >> the default because it worked for me and I hoped that people would help >> find and fix edge cases. > > Can you elaborate why synchronous DHCP sucks ? The only reason I could see is bringup time. Am I correct in this assumption? >> >> BTW, the change to background by default still doesn't make sense to >> me. At best it shouldn't do anything useful in the async case and it >> entierly defeats the sync case. >> > > Yeah, I realized this as soon as people started complaining about the > changes and reverting that commit didn't fix their problem. I'll back > it out. Thanks :), -Garrett ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: The rc.d mess strikes back
On Mon, Mar 2, 2009 at 3:32 PM, Andrew Reilly wrote: > On Mon, Mar 02, 2009 at 01:25:22PM -0700, M. Warner Losh wrote: >> In message: <2fd864e0903020512i22b2c31fg487aaf37fed63...@mail.gmail.com> >> Astrodog writes: >> : As unfortunate (and annoying) as that delay was, your system was in a >> : "defined" state, at the end of rc.d. As things stand now, that doesn't >> : appear to be the case anymore, and I think that may be a more >> : significant issue than the delay. >> >> I'd be happy with synchronous dhcp. > > The more general problem is the (large) number of network > applications that assume that network addresses and routes never > change (because that's how things were when they were written.) > My personal pet peeve is ntpd, but there are many others. Any > daemon that caches host IP address information at startup is > (IMO) broken, and needs to be fixed. There are many reasons why > network addresses may change *after* startup, and it is not > reasonable to go around and manually HUP everything when that > happens. > > Needing synchronous DHCP as a work-around here is just the > signifier of the problem: it isn't the over-all solution. I completely and wholeheartedly agree with you. This could be more difficult with contributed software, but it can be done! Thanks =], -Garrett ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
Hi Steve, On Tuesday 03 March 2009, Steve Calfee wrote: > > I think the reduced performance can be explained by a clamp on the > > interrupt rate around 1000 interrupts per second instead of 8000. Maybe > > someone has an explanation for this? > > > > The EHCI is being programmed to interrupt at 125us intervals, but there > > seems to be limits other places. > > > > It is possible to workaround this in the umass driver by doing the cmd + > > read in one operation. > > Hi Hans, > > I am looking at using FreeBSD in an embedded product. I have not > examined your ehci software, but I am aware of how Linux and other > OSes run the controller. > > Why are you taking an interrupt every uFrame SOF? If the transaction completes before 125us we take the interrupt before 125us. The problem is that the interrupt delay becomes critical to performance when the interrupt rate is close to the interrupt limitation. For example: Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 interrupts. Hence the Mass Storage state machine has three steps the throughput is computed like (600/3)*65536 bytes. If we on the average have to wait 0.5ms for an interrupt we loose throughput. > async > doesn't care at all If you have to wait for a transaction before you can do the next one it matters. > - the only impact is possible xfer speed. Taking > really fast periodic (uFrame) interrupts guarantees no faster > transfers than just having the end of transfer interrupt. > --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
>Repeat the same test using FreeBSD -current. >a) On the machine where it is slow. vmstat -i ; sleep 1 ; vmstat -i interrupt total rate irq1: atkbd0 233 2 irq14: ata0 85 0 irq16: vgapci0 5377 52 irq21: hdac0 ohci0 742 7 irq22: nfe0 ehci0 23610229 irq23: atapci1 5405 52 cpu0: timer 203959 1980 cpu1: timer 200914 1950 Total 440325 4275 interrupt total rate irq1: atkbd0 234 2 irq14: ata0 85 0 irq16: vgapci0 5439 52 irq21: hdac0 ohci0 742 7 irq22: nfe0 ehci0 24621236 irq23: atapci1 5405 51 cpu0: timer 205981 1980 cpu1: timer 202937 1951 Total 445444 4283 >I think the reduced performance can be explained by a clamp on the interrupt >rate around 1000 interrupts per second instead of 8000. Maybe someone has an >explanation for this? You right, the interrupt rate around 1000 (1011) on this machine, but on FreeBSD 7.1 more 3000. If it is some kind of interrupt aggregation, may be I can try to turn it off? >b) On the machine where it is fast. vmstat -i ; sleep 1 ; vmstat -i interrupt total rate irq4: uart0 4154 0 irq14: ata0 472922 0 irq15: ata1 26 0 irq18: em0752711 0 irq21: ahc0 53 0 irq23: ehci0 103456 0 irq24: em1 147 0 cpu0: timer 1551216517 2000 cpu1: timer 1551195251 2000 Total 3103745237 4001 interrupt total rate irq4: uart0 4154 0 irq14: ata0 472923 0 irq15: ata1 26 0 irq18: em0752713 0 irq21: ahc0 53 0 irq23: ehci0 110949 0 irq24: em1 147 0 cpu0: timer 1551218551 2000 cpu1: timer 1551197285 2000 Total 3103756801 4001 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Knobs to reduce PCI interrupt latency [was: Low perfomance when read from usb flash drive]
Hi, Do we have any knobs in FreeBSD to reduce the interrupt latency? I am currently seeing performance differences between 8.x and 7.x. Anyone have any ideas? --HPS On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: > >Repeat the same test using FreeBSD -current. > > > >a) On the machine where it is slow. > > vmstat -i ; sleep 1 ; vmstat -i > interrupt total rate > irq1: atkbd0 233 2 > irq14: ata0 85 0 > irq16: vgapci0 5377 52 > irq21: hdac0 ohci0 742 7 > irq22: nfe0 ehci0 23610229 > irq23: atapci1 5405 52 > cpu0: timer 203959 1980 > cpu1: timer 200914 1950 > Total 440325 4275 > interrupt total rate > irq1: atkbd0 234 2 > irq14: ata0 85 0 > irq16: vgapci0 5439 52 > irq21: hdac0 ohci0 742 7 > irq22: nfe0 ehci0 24621236 > irq23: atapci1 5405 51 > cpu0: timer 205981 1980 > cpu1: timer 202937 1951 > Total 445444 4283 > > >I think the reduced performance can be explained by a clamp on the > > interrupt rate around 1000 interrupts per second instead of 8000. Maybe > > someone has an explanation for this? > > You right, the interrupt rate around 1000 (1011) on this machine, but on > FreeBSD 7.1 more 3000. If it is some kind of interrupt aggregation, may be > I can try to turn it off? > > >b) On the machine where it is fast. > > vmstat -i ; sleep 1 ; vmstat -i > interrupt total rate > irq4: uart0 4154 0 > irq14: ata0 472922 0 > irq15: ata1 26 0 > irq18: em0752711 0 > irq21: ahc0 53 0 > irq23: ehci0 103456 0 > irq24: em1 147 0 > cpu0: timer 1551216517 2000 > cpu1: timer 1551195251 2000 > Total 3103745237 4001 > interrupt total rate > irq4: uart0 4154 0 > irq14: ata0 472923 0 > irq15: ata1 26 0 > irq18: em0752713 0 > irq21: ahc0 53 0 > irq23: ehci0 110949 0 > irq24: em1 147 0 > cpu0: timer 1551218551 2000 > cpu1: timer 1551197285 2000 > Total 3103756801 4001 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
I forgot to write, that a similar problem was observed in FreeBSD 7 with usb4bsd patches. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
In message: <200903040922.48163.hsela...@c2i.net> Hans Petter Selasky writes: : Hi Steve, : : On Tuesday 03 March 2009, Steve Calfee wrote: : > > I think the reduced performance can be explained by a clamp on the : > > interrupt rate around 1000 interrupts per second instead of 8000. Maybe : > > someone has an explanation for this? : > > : > > The EHCI is being programmed to interrupt at 125us intervals, but there : > > seems to be limits other places. : > > : > > It is possible to workaround this in the umass driver by doing the cmd + : > > read in one operation. : > : > Hi Hans, : > : > I am looking at using FreeBSD in an embedded product. I have not : > examined your ehci software, but I am aware of how Linux and other : > OSes run the controller. : > : > Why are you taking an interrupt every uFrame SOF? : : If the transaction completes before 125us we take the interrupt before 125us. : The problem is that the interrupt delay becomes critical to performance when : the interrupt rate is close to the interrupt limitation. : : For example: : : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 : interrupts. Hence the Mass Storage state machine has three steps the : throughput is computed like (600/3)*65536 bytes. If we on the average have to : wait 0.5ms for an interrupt we loose throughput. Shouldn't you be using filters and such to make this less relevant? A filter runs on the order of 5us after the interrupt on fast machines, and 20us on slower (400MHz) ones. You can feed the pipeline better, and handle higher interrupt rates... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Knobs to reduce PCI interrupt latency
In message: <200903040942.39191.hsela...@c2i.net> Hans Petter Selasky writes: : Do we have any knobs in FreeBSD to reduce the interrupt latency? I am : currently seeing performance differences between 8.x and 7.x. Anyone have any : ideas? If we did, don't you think they would be enabled by default :) Seriously, I measured interrupt latency on a 7.0-current system at around 20us for a fast interrupt/filter (300MHz or 400MHz low-power CPU). For fast machines, this can approach 1us, which is hard to measure with the setup I had for the 300MHz case. Deferring work to the scheduled interrupt can be useful, especailly if you can keep the pipeline full such that the filter can kick off the next set of transactions quickly, and then call the completion routines on the last set in parallel in the ithread. This works well for most random-access things, but less well for single threaded, sequential benchmarks. Warner : --HPS : : On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: : > >Repeat the same test using FreeBSD -current. : > > : > >a) On the machine where it is slow. : > : > vmstat -i ; sleep 1 ; vmstat -i : > interrupt total rate : > irq1: atkbd0 233 2 : > irq14: ata0 85 0 : > irq16: vgapci0 5377 52 : > irq21: hdac0 ohci0 742 7 : > irq22: nfe0 ehci0 23610229 : > irq23: atapci1 5405 52 : > cpu0: timer 203959 1980 : > cpu1: timer 200914 1950 : > Total 440325 4275 : > interrupt total rate : > irq1: atkbd0 234 2 : > irq14: ata0 85 0 : > irq16: vgapci0 5439 52 : > irq21: hdac0 ohci0 742 7 : > irq22: nfe0 ehci0 24621236 : > irq23: atapci1 5405 51 : > cpu0: timer 205981 1980 : > cpu1: timer 202937 1951 : > Total 445444 4283 : > : > >I think the reduced performance can be explained by a clamp on the : > > interrupt rate around 1000 interrupts per second instead of 8000. Maybe : > > someone has an explanation for this? : > : > You right, the interrupt rate around 1000 (1011) on this machine, but on : > FreeBSD 7.1 more 3000. If it is some kind of interrupt aggregation, may be : > I can try to turn it off? : > : > >b) On the machine where it is fast. : > : > vmstat -i ; sleep 1 ; vmstat -i : > interrupt total rate : > irq4: uart0 4154 0 : > irq14: ata0 472922 0 : > irq15: ata1 26 0 : > irq18: em0752711 0 : > irq21: ahc0 53 0 : > irq23: ehci0 103456 0 : > irq24: em1 147 0 : > cpu0: timer 1551216517 2000 : > cpu1: timer 1551195251 2000 : > Total 3103745237 4001 : > interrupt total rate : > irq4: uart0 4154 0 : > irq14: ata0 472923 0 : > irq15: ata1 26 0 : > irq18: em0752713 0 : > irq21: ahc0 53 0 : > irq23: ehci0 110949 0 : > irq24: em1 147 0 : > cpu0: timer 1551218551 2000 : > cpu1: timer 1551197285 2000 : > Total 3103756801 4001 : : : ___ : freebsd-usb@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-usb : To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org" : : ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wednesday 04 March 2009, M. Warner Losh wrote: > In message: <200903040922.48163.hsela...@c2i.net> > > Hans Petter Selasky writes: > : Hi Steve, > : > : On Tuesday 03 March 2009, Steve Calfee wrote: > : > > I think the reduced performance can be explained by a clamp on the > : > > interrupt rate around 1000 interrupts per second instead of 8000. > : > > Maybe someone has an explanation for this? > : > > > : > > The EHCI is being programmed to interrupt at 125us intervals, but > : > > there seems to be limits other places. > : > > > : > > It is possible to workaround this in the umass driver by doing the > : > > cmd + read in one operation. > : > > : > Hi Hans, > : > > : > I am looking at using FreeBSD in an embedded product. I have not > : > examined your ehci software, but I am aware of how Linux and other > : > OSes run the controller. > : > > : > Why are you taking an interrupt every uFrame SOF? > : > : If the transaction completes before 125us we take the interrupt before > : 125us. The problem is that the interrupt delay becomes critical to > : performance when the interrupt rate is close to the interrupt limitation. > : > : For example: > : > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 > : interrupts. Hence the Mass Storage state machine has three steps the > : throughput is computed like (600/3)*65536 bytes. If we on the average > : have to wait 0.5ms for an interrupt we loose throughput. > > Shouldn't you be using filters and such to make this less relevant? A > filter runs on the order of 5us after the interrupt on fast machines, > and 20us on slower (400MHz) ones. You can feed the pipeline better, > and handle higher interrupt rates... > Yes, that's one possibility. It looks like there is some timing slightly out of sync. I have an AMD box with the same symptoms. I will try to figure out what is causing it. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
In message: <200903041001.37376.hsela...@c2i.net> Hans Petter Selasky writes: : On Wednesday 04 March 2009, M. Warner Losh wrote: : > In message: <200903040922.48163.hsela...@c2i.net> : > : > Hans Petter Selasky writes: : > : Hi Steve, : > : : > : On Tuesday 03 March 2009, Steve Calfee wrote: : > : > > I think the reduced performance can be explained by a clamp on the : > : > > interrupt rate around 1000 interrupts per second instead of 8000. : > : > > Maybe someone has an explanation for this? : > : > > : > : > > The EHCI is being programmed to interrupt at 125us intervals, but : > : > > there seems to be limits other places. : > : > > : > : > > It is possible to workaround this in the umass driver by doing the : > : > > cmd + read in one operation. : > : > : > : > Hi Hans, : > : > : > : > I am looking at using FreeBSD in an embedded product. I have not : > : > examined your ehci software, but I am aware of how Linux and other : > : > OSes run the controller. : > : > : > : > Why are you taking an interrupt every uFrame SOF? : > : : > : If the transaction completes before 125us we take the interrupt before : > : 125us. The problem is that the interrupt delay becomes critical to : > : performance when the interrupt rate is close to the interrupt limitation. : > : : > : For example: : > : : > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 : > : interrupts. Hence the Mass Storage state machine has three steps the : > : throughput is computed like (600/3)*65536 bytes. If we on the average : > : have to wait 0.5ms for an interrupt we loose throughput. : > : > Shouldn't you be using filters and such to make this less relevant? A : > filter runs on the order of 5us after the interrupt on fast machines, : > and 20us on slower (400MHz) ones. You can feed the pipeline better, : > and handle higher interrupt rates... : > : : Yes, that's one possibility. It looks like there is some timing slightly out : of sync. I have an AMD box with the same symptoms. I will try to figure out : what is causing it. Maybe there's just good, old-fashioned lock contention going on? 7.x has more Giant use than 8.0 will, and in the past this has been a source of problems. Something else to check into. Maybe enabling lock profiling might yield some good data? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wed, Mar 04, 2009 at 10:01:36AM +0100, Hans Petter Selasky wrote: > On Wednesday 04 March 2009, M. Warner Losh wrote: > > In message: <200903040922.48163.hsela...@c2i.net> > > > > : > I am looking at using FreeBSD in an embedded product. I have not > > : > examined your ehci software, but I am aware of how Linux and other > > : > OSes run the controller. > > : > > > : > Why are you taking an interrupt every uFrame SOF? > > : > > : If the transaction completes before 125us we take the interrupt before > > : 125us. The problem is that the interrupt delay becomes critical to > > : performance when the interrupt rate is close to the interrupt limitation. > > : > > : For example: > > : > > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 > > : interrupts. Hence the Mass Storage state machine has three steps the > > : throughput is computed like (600/3)*65536 bytes. If we on the average > > : have to wait 0.5ms for an interrupt we loose throughput. > > > > Shouldn't you be using filters and such to make this less relevant? A > > filter runs on the order of 5us after the interrupt on fast machines, > > and 20us on slower (400MHz) ones. You can feed the pipeline better, > > and handle higher interrupt rates... > > > > Yes, that's one possibility. It looks like there is some timing slightly out > of sync. I have an AMD box with the same symptoms. I will try to figure out > what is causing it. If you do change to filters then this is much easier with taskqueues as it has a fast variant, otherwise you would need an intermediate step in order to signal the existing usb threading scheme. The taskqueue changeover will be happening soonish anyway. Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: The rc.d mess strikes back
On Wed, Mar 04, 2009 at 12:04:06AM -0800, Garrett Cooper wrote: > On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen > wrote: > > On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis wrote: > >> > >> I don't have much time to debug this, but I've not had problems with > >> services starting too early on the systems I've been running with async > >> dhcp. ?If there is a problem with the wait process we need to actually > >> debug it. ?If the wait for a route/running interface isn't sufficent we > >> should try to figure out what is. ?Synchronous dhcp sucks and yeilds > >> justifed user complaints so it would be nice to kill it off. ?I switched > >> the default because it worked for me and I hoped that people would help > >> find and fix edge cases. > > > > Can you elaborate why synchronous DHCP sucks ? > > The only reason I could see is bringup time. Am I correct in this assumption? If you use synchronous DHCP then every interface that wants to try to get a DHCP address if it has link needs to run through the full link timeout at boot. On a laptop this is annoying and generally pointless. The changes to defaultroute to wait for a default route to be set mean that you consolidate the wait in one location and you don't waste time starting dhclient on interfaces until a link exists (or an association is made for wlan devices). There may well be something better to wait or a need for a longer timeout in some environments. It's also quite possible that we have an ordering problem and need to move some more things after defaultroute or move the checks to a different location. -- Brooks pgpAbzxDQ6Gd2.pgp Description: PGP signature
usb/132312: Xorg 7.4 halts USB controller
>Number: 132312 >Category: usb >Synopsis: Xorg 7.4 halts USB controller >Confidential: no >Severity: critical >Priority: high >Responsible:freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 04 17:10:02 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Alexey Viziryakin >Release:7.1 Stable >Organization: none >Environment: FreeBSD freebsd.localhost 7.1-STABLE FreeBSD 7.1-STABLE #0: Sun Feb 15 14:27:11 MSK 2009 r...@freebsd.localhost:/usr/obj/usr/src/sys/I686VESA7R i386 >Description: After perfoming upgrade to Xorg 7.4, it halts my internal USB controller completely. I have this in /var/log/messages: Mar 4 19:42:51 freebsd kernel: usb3: unrecoverable error, controller halted Mar 4 19:42:51 freebsd kernel: usb3: blocking intrs 0x10 Part of my dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-STABLE #0: Sun Feb 15 14:27:11 MSK 2009 r...@freebsd.localhost:/usr/obj/usr/src/sys/I686VESA7R Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.20GHz (2200.17-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 1006612480 (959 MB) avail memory = 975761408 (930 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=487144kB. acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3bf0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd800-0xd87f mem 0xe800-0xefff,0 xcf80-0xcf81 irq 16 at device 0.0 on pci1 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0 xa400-0xa40f irq 16 at device 2.5 on pci0 ata0: on atapci0 ata1: [ITHREAD] pcm0: port 0x9400-0x94ff,0x9000-0x907f irq 18 at device 2.7 on pci0 pcm0: [ITHREAD] pcm0: ohci0: mem 0xce80-0xce800fff irq 20 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xce00-0xce000fff irq 21 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xcd80-0xcd800fff irq 22 at device 3.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xcd00-0xcd000fff irq 23 at d evice 3.3 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self poweredA channel 0> on atapci0 umass0: on uhub3 uhub4: on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered uhub5: on uhub4 uhub5: single transaction translator uhub5: 4 ports with 4 removable, self powered Xorg has compiled without HAL and AIGLX options. >How-To-Repeat: start Xorg 7.4 on same hardware. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
usb touchpad not working properly on CURRENT with usb2
Hi, The touchpad of my laptop is not responding properly to input anymore. It used to work fine with the old usb stack. The laptop is running CURRENT from yesterday: FreeBSD zembla.universe 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Mar 4 17:30:05 EET 2009 u...@zembla.universe:/usr/obj/usr/src/sys/CUSTOM amd64 When I move my finger horizontally on the touchpad of the laptop, the cursor moves up and down. Moving the finger vertically moves the cursor a little and then it stops. Pressing the touchpad button moves the cursor to the right. The touchpad is detected as: ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Resetting the touchpad produces the following dmesg output: ukbd0: at uhub0, port 2, addr 2 (disconnected) ums1: at uhub0, port 2, addr 2 (disconnected) ums_detach:608: sc=0xff000188c400 uhid1: at uhub0, port 2, addr 2 (disconnected) ukbd0: on usbus0 kbd1 at ukbd0 ums1: on usbus0 ums_attach:530: WARNING: report size, 67 bytes, is larger than interrupt size, 64 bytes! ums1: 3 buttons and [XY] coordinates ums_attach:546: sc=0xff000184e800 ums_attach:547: X 8/8 ums_attach:548: Y 16/8 ums_attach:549: Z 0/0 ums_attach:550: T 0/0 ums_attach:551: W 0/0 ums_attach:555: B1 0/1 ums_attach:555: B2 1/1 ums_attach:555: B3 2/1 ums_attach:557: size=67, id=0 uhid1: on usbus0 What other information should I provide to help solving this problem? Sincerely, Boris Kotzev ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wednesday 04 March 2009, Andrew Thompson wrote: > On Wed, Mar 04, 2009 at 10:01:36AM +0100, Hans Petter Selasky wrote: > > On Wednesday 04 March 2009, M. Warner Losh wrote: > > > In message: <200903040922.48163.hsela...@c2i.net> > > > > > > : > I am looking at using FreeBSD in an embedded product. I have not > > > : > examined your ehci software, but I am aware of how Linux and other > > > : > OSes run the controller. > > > : > > > > : > Why are you taking an interrupt every uFrame SOF? > > > : > > > : If the transaction completes before 125us we take the interrupt > > > : before 125us. The problem is that the interrupt delay becomes > > > : critical to performance when the interrupt rate is close to the > > > : interrupt limitation. > > > : > > > : For example: > > > : > > > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates > > > : 600 interrupts. Hence the Mass Storage state machine has three steps > > > : the throughput is computed like (600/3)*65536 bytes. If we on the > > > : average have to wait 0.5ms for an interrupt we loose throughput. > > > > > > Shouldn't you be using filters and such to make this less relevant? A > > > filter runs on the order of 5us after the interrupt on fast machines, > > > and 20us on slower (400MHz) ones. You can feed the pipeline better, > > > and handle higher interrupt rates... > > > > Yes, that's one possibility. It looks like there is some timing slightly > > out of sync. I have an AMD box with the same symptoms. I will try to > > figure out what is causing it. > > If you do change to filters then this is much easier with taskqueues as > it has a fast variant, otherwise you would need an intermediate step in > order to signal the existing usb threading scheme. The taskqueue > changeover will be happening soonish anyway. I am not going to do anything with filters. I'm going to try some other things. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
In message: <200903041910.58446.hsela...@c2i.net> Hans Petter Selasky writes: : On Wednesday 04 March 2009, Andrew Thompson wrote: : > On Wed, Mar 04, 2009 at 10:01:36AM +0100, Hans Petter Selasky wrote: : > > On Wednesday 04 March 2009, M. Warner Losh wrote: : > > > In message: <200903040922.48163.hsela...@c2i.net> : > > > : > > > : > I am looking at using FreeBSD in an embedded product. I have not : > > > : > examined your ehci software, but I am aware of how Linux and other : > > > : > OSes run the controller. : > > > : > : > > > : > Why are you taking an interrupt every uFrame SOF? : > > > : : > > > : If the transaction completes before 125us we take the interrupt : > > > : before 125us. The problem is that the interrupt delay becomes : > > > : critical to performance when the interrupt rate is close to the : > > > : interrupt limitation. : > > > : : > > > : For example: : > > > : : > > > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates : > > > : 600 interrupts. Hence the Mass Storage state machine has three steps : > > > : the throughput is computed like (600/3)*65536 bytes. If we on the : > > > : average have to wait 0.5ms for an interrupt we loose throughput. : > > > : > > > Shouldn't you be using filters and such to make this less relevant? A : > > > filter runs on the order of 5us after the interrupt on fast machines, : > > > and 20us on slower (400MHz) ones. You can feed the pipeline better, : > > > and handle higher interrupt rates... : > > : > > Yes, that's one possibility. It looks like there is some timing slightly : > > out of sync. I have an AMD box with the same symptoms. I will try to : > > figure out what is causing it. : > : > If you do change to filters then this is much easier with taskqueues as : > it has a fast variant, otherwise you would need an intermediate step in : > order to signal the existing usb threading scheme. The taskqueue : > changeover will be happening soonish anyway. : : I am not going to do anything with filters. I'm going to try some other : things. Then you will always have the scheduling delay... Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wednesday 04 March 2009, M. Warner Losh wrote: > : > > : > If you do change to filters then this is much easier with taskqueues as > : > it has a fast variant, otherwise you would need an intermediate step in > : > order to signal the existing usb threading scheme. The taskqueue > : > changeover will be happening soonish anyway. > : > : I am not going to do anything with filters. I'm going to try some other > : things. > > Then you will always have the scheduling delay... But the scheduling delay is not in the millisecond range on a 2.4GHz ?? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/132312: Xorg 7.4 halts USB controller
On Wednesday 04 March 2009, Alexey Viziryakin wrote: > >Number: 132312 > >Category: usb > >Synopsis: Xorg 7.4 halts USB controller > >Confidential: no > >Severity: critical > >Priority: high > >Responsible:freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Mar 04 17:10:02 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Alexey Viziryakin > >Release:7.1 Stable > >Organization: > > none > > >Environment: > > FreeBSD freebsd.localhost 7.1-STABLE FreeBSD 7.1-STABLE #0: Sun Feb 15 > 14:27:11 MSK 2009 r...@freebsd.localhost:/usr/obj/usr/src/sys/I686VESA7R > i386 > > >Description: > > After perfoming upgrade to Xorg 7.4, it halts my internal USB controller > completely. I have this in /var/log/messages: > > Mar 4 19:42:51 freebsd kernel: usb3: unrecoverable error, controller > halted Mar 4 19:42:51 freebsd kernel: usb3: blocking intrs 0x10 > > Part of my dmesg: > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-STABLE #0: Sun Feb 15 14:27:11 MSK 2009 > r...@freebsd.localhost:/usr/obj/usr/src/sys/I686VESA7R > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 2.20GHz (2200.17-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbffA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x4400 > real memory = 1006612480 (959 MB) > avail memory = 975761408 (930 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > kqemu version 0x00010300 > kqemu: KQEMU installed, max_locked_mem=487144kB. > acpi0: on motherboard > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, 3bf0 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xd800-0xd87f mem > 0xe800-0xefff,0 xcf80-0xcf81 irq 16 at device 0.0 on pci1 > isab0: at device 2.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0 xa400-0xa40f irq 16 at device 2.5 on > pci0 > ata0: ata1: on atapci0 > ata1: [ITHREAD] > pcm0: port 0x9400-0x94ff,0x9000-0x907f irq 18 at device 2.7 on > pci0 pcm0: [ITHREAD] > pcm0: > ohci0: mem 0xce80-0xce800fff irq 20 at device > 3.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > ohci1: mem 0xce00-0xce000fff irq 21 at device > 3.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ohci2: mem 0xcd80-0xcd800fff irq 22 at device > 3.2 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb2: OHCI version 1.0, legacy support > usb2: SMM does not respond, resetting > usb2: on ohci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xcd00-0xcd000fff irq 23 > at d evice 3.3 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self poweredA channel 0> on atapci0 > umass0: 2.00 /0.01, addr 2> on uhub3 > uhub4: on > uhub3 uhub4: single transaction translator > uhub4: 4 ports with 4 removable, self powered > uhub5: on > uhub4 uhub5: single transaction translator > uhub5: 4 ports with 4 removable, self powered > > Xorg has compiled without HAL and AIGLX options. > > >How-To-Repeat: > > start Xorg 7.4 on same hardware. > > >Fix: > > > > > >Release-Note: > >Audit-Trail: > >Unformatted: This is probably an IRQ problem. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb touchpad not working properly on CURRENT with usb2
On Wednesday 04 March 2009, Boris Kotzev wrote: > Hi, > > The touchpad of my laptop is not responding properly to input anymore. It > used to work fine with the old usb stack. > > The laptop is running CURRENT from yesterday: > > FreeBSD zembla.universe 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Mar 4 > 17:30:05 EET 2009 u...@zembla.universe:/usr/obj/usr/src/sys/CUSTOM amd64 > > When I move my finger horizontally on the touchpad of the laptop, the > cursor moves up and down. Moving the finger vertically moves the cursor a > little and then it stops. Pressing the touchpad button moves the cursor to > the right. > > The touchpad is detected as: > > ugen0.2: at usbus0, > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > > Resetting the touchpad produces the following dmesg output: > > ukbd0: at uhub0, port 2, addr 2 (disconnected) > ums1: at uhub0, port 2, addr 2 (disconnected) > ums_detach:608: sc=0xff000188c400 > uhid1: at uhub0, port 2, addr 2 (disconnected) > ukbd0: on usbus0 > kbd1 at ukbd0 > ums1: on usbus0 > ums_attach:530: WARNING: report size, 67 bytes, is larger than interrupt > size, 64 bytes! ums1: 3 buttons and [XY] coordinates > ums_attach:546: sc=0xff000184e800 > ums_attach:547: X 8/8 > ums_attach:548: Y 16/8 > ums_attach:549: Z 0/0 > ums_attach:550: T 0/0 > ums_attach:551: W 0/0 > ums_attach:555: B10/1 > ums_attach:555: B21/1 > ums_attach:555: B32/1 > ums_attach:557: size=67, id=0 > uhid1: on usbus0 > > What other information should I provide to help solving this problem? > > Sincerely, > > Boris Kotzev Could you get the USB HID descriptors dumped using: usbhidctl --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
In message: <200903042031.37578.hsela...@c2i.net> Hans Petter Selasky writes: : On Wednesday 04 March 2009, M. Warner Losh wrote: : > : > : > : > If you do change to filters then this is much easier with taskqueues as : > : > it has a fast variant, otherwise you would need an intermediate step in : > : > order to signal the existing usb threading scheme. The taskqueue : > : > changeover will be happening soonish anyway. : > : : > : I am not going to do anything with filters. I'm going to try some other : > : things. : > : > Then you will always have the scheduling delay... : : But the scheduling delay is not in the millisecond range on a 2.4GHz ?? Not typically. Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/132312: Xorg 7.4 halts USB controller
The following reply was made to PR usb/132312; it has been noted by GNATS. From: Hans Petter Selasky To: freebsd-usb@freebsd.org Cc: Alexey Viziryakin , freebsd-gnats-sub...@freebsd.org Subject: Re: usb/132312: Xorg 7.4 halts USB controller Date: Wed, 4 Mar 2009 20:38:56 +0100 On Wednesday 04 March 2009, Alexey Viziryakin wrote: > >Number: 132312 > >Category: usb > >Synopsis: Xorg 7.4 halts USB controller > >Confidential: no > >Severity: critical > >Priority: high > >Responsible:freebsd-usb > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Mar 04 17:10:02 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Alexey Viziryakin > >Release:7.1 Stable > >Organization: > > none > > >Environment: > > FreeBSD freebsd.localhost 7.1-STABLE FreeBSD 7.1-STABLE #0: Sun Feb 15 > 14:27:11 MSK 2009 r...@freebsd.localhost:/usr/obj/usr/src/sys/I686VESA7R > i386 > > >Description: > > After perfoming upgrade to Xorg 7.4, it halts my internal USB controller > completely. I have this in /var/log/messages: > > Mar 4 19:42:51 freebsd kernel: usb3: unrecoverable error, controller > halted Mar 4 19:42:51 freebsd kernel: usb3: blocking intrs 0x10 > > Part of my dmesg: > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-STABLE #0: Sun Feb 15 14:27:11 MSK 2009 > r...@freebsd.localhost:/usr/obj/usr/src/sys/I686VESA7R > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Celeron(R) CPU 2.20GHz (2200.17-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbffA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0x4400 > real memory = 1006612480 (959 MB) > avail memory = 975761408 (930 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > kqemu version 0x00010300 > kqemu: KQEMU installed, max_locked_mem=487144kB. > acpi0: on motherboard > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a (3) failed > acpi0: reservation of 10, 3bf0 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xd800-0xd87f mem > 0xe800-0xefff,0 xcf80-0xcf81 irq 16 at device 0.0 on pci1 > isab0: at device 2.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0 xa400-0xa40f irq 16 at device 2.5 on > pci0 > ata0: ata1: on atapci0 > ata1: [ITHREAD] > pcm0: port 0x9400-0x94ff,0x9000-0x907f irq 18 at device 2.7 on > pci0 pcm0: [ITHREAD] > pcm0: > ohci0: mem 0xce80-0xce800fff irq 20 at device > 3.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > ohci1: mem 0xce00-0xce000fff irq 21 at device > 3.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ohci2: mem 0xcd80-0xcd800fff irq 22 at device > 3.2 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb2: OHCI version 1.0, legacy support > usb2: SMM does not respond, resetting > usb2: on ohci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xcd00-0xcd000fff irq 23 > at d evice 3.3 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self poweredA channel 0> on atapci0 > umass0: 2.00 /0.01, addr 2> on uhub3 > uhub4: on > uhub3 uhub4: single transaction translator > uhub4: 4 ports with 4 removable, self powered > uhub5: on > uhub4 uhub5: single transaction translator > uhub5: 4 ports with 4 removable, self powered > > Xorg has compiled without HAL and AIGLX options. > > >How-To-Repeat: > > start Xorg 7.4 on same hardware. > > >Fix: > > > > > >Release-Note: > >Aud
Re: usb touchpad not working properly on CURRENT with usb2
> On Wednesday 04 March 2009, Boris Kotzev wrote: > > Hi, > > > > The touchpad of my laptop is not responding properly to input anymore. It > > used to work fine with the old usb stack. > > > > The laptop is running CURRENT from yesterday: > > > > FreeBSD zembla.universe 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Mar 4 > > 17:30:05 EET 2009 u...@zembla.universe:/usr/obj/usr/src/sys/CUSTOM amd64 > > > > When I move my finger horizontally on the touchpad of the laptop, the > > cursor moves up and down. Moving the finger vertically moves the cursor a > > little and then it stops. Pressing the touchpad button moves the cursor > > to the right. > > > > The touchpad is detected as: > > > > ugen0.2: at usbus0, > > cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON > > > > Resetting the touchpad produces the following dmesg output: > > > > ukbd0: at uhub0, port 2, addr 2 (disconnected) > > ums1: at uhub0, port 2, addr 2 (disconnected) > > ums_detach:608: sc=0xff000188c400 > > uhid1: at uhub0, port 2, addr 2 (disconnected) > > ukbd0: on usbus0 > > kbd1 at ukbd0 > > ums1: on usbus0 > > ums_attach:530: WARNING: report size, 67 bytes, is larger than interrupt > > size, 64 bytes! ums1: 3 buttons and [XY] coordinates > > ums_attach:546: sc=0xff000184e800 > > ums_attach:547: X 8/8 > > ums_attach:548: Y 16/8 > > ums_attach:549: Z 0/0 > > ums_attach:550: T 0/0 > > ums_attach:551: W 0/0 > > ums_attach:555: B1 0/1 > > ums_attach:555: B2 1/1 > > ums_attach:555: B3 2/1 > > ums_attach:557: size=67, id=0 > > uhid1: on usbus0 > > > > What other information should I provide to help solving this problem? > > > > Sincerely, > > > > Boris Kotzev > > Could you get the USB HID descriptors dumped using: > > usbhidctl > > --HPS All information I managed to extract by using usbhidctl is below: # usbhidctl -f /dev/uhid1 -ra Report descriptor: Collection page=Consumer usage=Consumer_Control Input size=8 count=1 page=Consumer usage=Eject, logical range 0..255 End collection Total input size 1 bytes Total output size 0 bytes Total feature size 0 bytes usbhidctl: USB_SET_IMMED: Device not configured If it is not enough, will you explain to me how to use this utility? Thanks! Boris Kotzev ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: > I forgot to write, that a similar problem was observed in FreeBSD 7 with > usb4bsd patches. Here is a patch which I think will address your problem. It is EHCI hardware related. Different models behave differently. Try this: http://perforce.freebsd.org/chv.cgi?CH=158692 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wed, Mar 4, 2009 at 12:22 AM, Hans Petter Selasky wrote: > Hi Steve, > > On Tuesday 03 March 2009, Steve Calfee wrote: >> > I think the reduced performance can be explained by a clamp on the >> > interrupt rate around 1000 interrupts per second instead of 8000. Maybe >> > someone has an explanation for this? >> > >> > The EHCI is being programmed to interrupt at 125us intervals, but there >> > seems to be limits other places. >> > >> > It is possible to workaround this in the umass driver by doing the cmd + >> > read in one operation. >> >> Hi Hans, >> >> I am looking at using FreeBSD in an embedded product. I have not >> examined your ehci software, but I am aware of how Linux and other >> OSes run the controller. >> >> Why are you taking an interrupt every uFrame SOF? > > If the transaction completes before 125us we take the interrupt before 125us. > The problem is that the interrupt delay becomes critical to performance when > the interrupt rate is close to the interrupt limitation. > Hi Hans, Ok I have looked a little at your ehci.c code and the ehci spec. I see that you are talking about the "interrupt threshold control" field which Intel added to the ehci to keep the high speed controller from flooding the cpu with interrupts. It has nothing to do with SOF interrupts. > For example: > > Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600 > interrupts. Hence the Mass Storage state machine has three steps the > throughput is computed like (600/3)*65536 bytes. If we on the average have to > wait 0.5ms for an interrupt we loose throughput. > I think here you are referring to the awkward synchronous scsi protocol embedded in usb mass storage devices. In this protocol the host does a IN and gets a USBS... status data block, does an OUT with a USBC... data block and then the data transfer (either IN or OUT). I don't think I have seen Linux or Windows transfer (in one scsi xfer) more than about 40K, but ok lets say 65K is possible. This means 128 -- 512 byte packet transfers. The max number of transfers I have seen in a microframe is about 11, but lets say it is 16 with some super ehci/dma controller. That says you can transfer 65K in 128/16 == 8 uFrames (this is higher than the 60Mbyte/sec bus speed of light, but it is easy to calculate). In this same super computer/ehci hardware the 3 packets (USBS, USBC, data) will most likely all be in different microframes. So in this scenario there will be 3 interrupts in 10 microframes = 1.250 milliseconds. In practice the USB mass storage device is the limiting factor and will be much slower than this. So what I am getting at is it is hard to believe the interrupt rate which will limit your xfer speed. Now the interesting question (for me a FreeBSD novice) is how does the OS limit the number of interrupts? Usually they would be limited by the available CPU power, and unlikely be limited to some arbitrary number per second (1000 or 8000). Does FreeBSD run all interrupts out of what Linux would call a bottom-half or tasklet? In that case latency for sequential I/O in the 3 step scsi protocol could add up to hurt you. Regards, Steve ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wed, Mar 4, 2009 at 2:10 PM, Hans Petter Selasky wrote: > On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: >> I forgot to write, that a similar problem was observed in FreeBSD 7 with >> usb4bsd patches. > > Here is a patch which I think will address your problem. It is EHCI hardware > related. Different models behave differently. Try this: > > http://perforce.freebsd.org/chv.cgi?CH=158692 > Wow, that is bizarre. The "doorbell" is usually used so the software knows that the cpu vs dma race is complete when moving qtds off the qh - ie dequeueing requests. What you have done is asked the guy doing the photo finish at the end of a horse race to press the shutter a little before the horse crosses the line - so the shutter latency will allow a picture right as the horse crosses the line. Unfortunately, this (like all races) is affected by the object doing the racing - horse speed and camera speed are variable! I believe something else must be wrong. Regards, Steve ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
> Here is a patch which I think will address your problem. It is EHCI hardware > related. Different models behave differently. Try this: > > http://perforce.freebsd.org/chv.cgi?CH=158692 Much better: dd if=/dev/da0 of=/dev/null bs=64k count=5000 5000+0 records in 5000+0 records out 32768 bytes transferred in 17.282871 secs (18959813 bytes/sec) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
On Wednesday 04 March 2009, Steve Calfee wrote: > On Wed, Mar 4, 2009 at 2:10 PM, Hans Petter Selasky wrote: > > On Wednesday 04 March 2009, Artyom Mirgorodsky wrote: > >> I forgot to write, that a similar problem was observed in FreeBSD 7 with > >> usb4bsd patches. > > > > Here is a patch which I think will address your problem. It is EHCI > > hardware related. Different models behave differently. Try this: > > > > http://perforce.freebsd.org/chv.cgi?CH=158692 > > Wow, that is bizarre. The "doorbell" is usually used so the software > knows that the cpu vs dma race is complete when moving qtds off the qh > - ie dequeueing requests. What you have done is asked the guy doing > the photo finish at the end of a horse race to press the shutter a > little before the horse crosses the line - so the shutter latency will > allow a picture right as the horse crosses the line. Unfortunately, > this (like all races) is affected by the object doing the racing - > horse speed and camera speed are variable! > > I believe something else must be wrong. The new USB stack _is_ doing things faster than the old one. I have gone through a large range of tests before I landed on the doorbell trick. Actually the new USB stack doesn't use the doorbell, we use software timers instead. The hardware certainly behaves different from vendor to vendor. Probably somone making the chips have to explain what is wrong. In my (Nvidia+AMD64+EHCI) test case I tried: No doorbell: 12 Mbyte/sec Doorbell after transfer (after QH removal): 14 Mbyte/sec Doorbell after next transfer (after QH insertion): 21 Mbyte/sec On my other reference Intel chip I did not get any noticable performance increase by doing this trick ... I think this trick is the best I can do. I've seen peculiarities before regarding the doorbell not behaving like it should --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
TODO
Hi, I have started a page to track USB tasks, please update with any items and feel free to work on any. Any discussion about the items should happen on the usb@ mailing list. http://wiki.freebsd.org/USBTODO cheers, Andrew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Low perfomance when read from usb flash drive
Excuse my ignorance, but what is meant by "doorbell" ? -aW 0n Thu, Mar 05, 2009 at 12:09:47AM +0100, Hans Petter Selasky wrote: >The new USB stack _is_ doing things faster than the old one. I have gone >through a large range of tests before I landed on the doorbell trick. >Actually the new USB stack doesn't use the doorbell, we use software timers >instead. The hardware certainly behaves different from vendor to vendor. >Probably somone making the chips have to explain what is wrong. > >In my (Nvidia+AMD64+EHCI) test case I tried: > >No doorbell: 12 Mbyte/sec >Doorbell after transfer (after QH removal): 14 Mbyte/sec >Doorbell after next transfer (after QH insertion): 21 Mbyte/sec IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: TODO
2009/3/5 Andrew Thompson : > Hi, > > > I have started a page to track USB tasks, please update with any items > and feel free to work on any. > > Any discussion about the items should happen on the usb@ mailing list. > > http://wiki.freebsd.org/USBTODO > Please, add the DDB support. This is now impossible due to threaded nature of USB. -- wbr, pluknet ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
