Re: CPU Cache and busdma usage in USB
1) My analysis: Only the data areas are being flushed/invalidated. No
transfer descriptors are flushed/invalidated. I see no cache operations
happening on any DMA control structures, even though there are calls from
EHCI to xxx_pc_flush() and xxx_pc_invalidate().
This is 100% correct if control structures are marked as BUS_DMA_COHERENT.
One patch you can try is to add an additional unload call to
usbd_transfer_setup_sub_malloc():
//depot/projects/usb/src/sys/dev/usb/usb_transfer.c#159 -
/home/hans_other/usb.p4/src/sys/dev/usb/usb_transfer.c
@@ -268,6 +268,10 @@
pg, z, align)) {
return (1); /* failure */
}
+
+ bus_dmamap_unload(parm-dma_page_cache_ptr-tag,
+ parm-dma_page_cache_ptr-map);
+
/* Set beginning of current buffer */
buf = parm-dma_page_cache_ptr-buffer;
/* Make room for one DMA page cache and one page */
This will avoid the same memory area being loaded twice. Not sure if there
is still a bug in pmap about this!
I checked this patch and I did not saw any changes in USB behaviour.
The problem sill was visible.
Could you provide a new trace, showing an enumeration failure. In your
previous trace there was no error, because the printouts probably caused to
CPU to flush out its cache.
I have tried many times and I was unable to generate trace showing enumeration
faliure. Even little amount of debugging code caused proper enumeration.
However access to attached device (pendrive) was not possible - SCSI layer
reported errors.
Probaby you see more on your AT91 device as you know USB stack internals. Have
you tried to bring up OHCI on you ARM board ?
--
Best Regards,
Piotr Ziecik
___
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: CPU Cache and busdma usage in USB
On Tuesday 14 July 2009 10:31:10 Piotr Zięcik wrote: 1) My analysis: Only the data areas are being flushed/invalidated. No transfer descriptors are flushed/invalidated. I see no cache operations happening on any DMA control structures, even though there are calls from EHCI to xxx_pc_flush() and xxx_pc_invalidate(). Probaby you see more on your AT91 device as you know USB stack internals. Have you tried to bring up OHCI on you ARM board ? Not yet. I'm terribly busy with some LibUSB stuff headed for the 8-current release. As soon as I find time I will fire off a build and debug. BTW: Has pmap been fixed for ARM in 8-current? --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: settings usb mouse rate
here's your reminder. *riiing* ;) alex ___ 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: CPU Cache and busdma usage in USB
On 2009-07-14, at 10:36, Hans Petter Selasky wrote: On Tuesday 14 July 2009 10:31:10 Piotr Zięcik wrote: 1) My analysis: Only the data areas are being flushed/invalidated. No transfer descriptors are flushed/invalidated. I see no cache operations happening on any DMA control structures, even though there are calls from EHCI to xxx_pc_flush() and xxx_pc_invalidate(). Probaby you see more on your AT91 device as you know USB stack internals. Have you tried to bring up OHCI on you ARM board ? Not yet. I'm terribly busy with some LibUSB stuff headed for the 8- current release. As soon as I find time I will fire off a build and debug. Please note these problems should be considered as a showstopper for the release since USB is currently broken on at least three ARM platforms in the tree (Marvell). BTW: Has pmap been fixed for ARM in 8-current? Seems like the most critical problems (panics) are resolved and will be pushed into SVN shortly. In case you'd like to apply the fix directly, see: http://people.freebsd.org/~raj/patches/arm/pmap-fixes.diff Rafal ___ 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
power_off/power_on with usb mouse/keyboard and hald
when i do `usbconfig power_off` and usbconfig power_on` with my usb keayboard/mouse it won't come up again in X. i suspect this is due to hald managing both devices. to get the devices running again under X without restarting it i have to unplug them then plug them in again. after that i need to switch to the console once and then back again to X. otherwise no keyboard input is being processed. also on a side note i noticed the following: when doing `usbconfig -u X -a Y suspend; usbconfig -u X -a Y resume` on a keyboard the very first keystroke doesn't get processed. so issuing the command sequence and typing hello results in ello being displayed on the console. alex ___ 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: settings usb mouse rate
Hi, The patch is in. http://perforce.freebsd.org/chv.cgi?CH=166075 Please try rates from moused -F 1 XXX to moused -F 1000 XXX. Check that the rate is actually set by enabling ums debugging: sysctl hw.usb.ums.debug=15 --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/102066: [ukbd] usb keyboard and multimedia keys don't work
The following reply was made to PR usb/102066; it has been noted by GNATS. From: Lapo Luchini l...@lapo.it To: bug-follo...@freebsd.org, trios...@triosoft.com.ua Cc: Subject: Re: usb/102066: [ukbd] usb keyboard and multimedia keys don't work Date: Tue, 14 Jul 2009 13:03:23 +0200 Also F13-F19 on new Apple USB keyboards recognize no scancode. % sysctl dev.ukbd dev.ukbd.0.%desc: Apple, Inc Apple Keyboard, class 0/0, rev 2.00/0.69, addr 3 dev.ukbd.0.%driver: ukbd dev.ukbd.0.%location: port=1 interface=0 dev.ukbd.0.%pnpinfo: vendor=0x05ac product=0x0221 devclass=0x00 devsubclass=0x00 release=0x0069 sernum= intclass=0x03 intsubclass=0x01 dev.ukbd.0.%parent: uhub7 OTOH I've seen in CVS that /src/sys/dev/usb/ukbd.c was deleted in HEAD, as 8.0 will contain the new USB stack, so the patch better be done to the new file ;-) âThere is no reason anyone would want a computer in their home.â (Ken Olson, founder of DEC, 1977) ___ 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: settings usb mouse rate
thx for the patch. i'm recompiling my kernel right now and will test the changes right away. any reason you limited the rate to = 1000? i had a quick look at the specs of my mouse: - 6400 frames per second (5.8 megapixels per second) - 1800dpi Razer Precision 3G infrared sensor what about the mouse resolution? moused comes has the -r switch to change it. would usb mice benefit from that option? cheers. alex Hans Petter Selasky schrieb am 2009-07-14: Hi, The patch is in. http://perforce.freebsd.org/chv.cgi?CH=166075 Please try rates from moused -F 1 XXX to moused -F 1000 XXX. Check that the rate is actually set by enabling ums debugging: sysctl hw.usb.ums.debug=15 --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
usb/125264: [patch] sysctl for set usb mouse rate (very useful for gamers - FPS games)
The following reply was made to PR usb/125264; it has been noted by GNATS. From: Hans Petter Selasky hsela...@c2i.net To: bug-follo...@freebsd.org, v...@quakeworld.ru Cc: Subject: usb/125264: [patch] sysctl for set usb mouse rate (very useful for gamers - FPS games) Date: Tue, 14 Jul 2009 12:30:57 +0200 Hi, The patch is in. http://perforce.freebsd.org/chv.cgi?CH=166075 Thanks for being patient. Please test. --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: settings usb mouse rate
Hi, On Tuesday 14 July 2009 13:28:28 Alexander Best wrote: thx for the patch. i'm recompiling my kernel right now and will test the changes right away. any reason you limited the rate to = 1000? i had a quick look at the specs of my mouse: USB has a limitation of polling 1000 times per second. - 6400 frames per second (5.8 megapixels per second) - 1800dpi Razer Precision 3G infrared sensor what about the mouse resolution? moused comes has the -r switch to change it. would usb mice benefit from that option? I'm not sure if setting the mouse resolution has a standard USB request yet. Else it would not be much trouble adding support for that aswell. --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: settings usb mouse rate
On Tuesday 14 July 2009 15:25:59 Alexander Best wrote: i tested the patch with rates of 1, 100 and 1000: 1: random copypastes when moving the mouse 100: also random copypastes when moving the mouse 1000: OK Could you try another USB mouse. Also I would like to see some ums debug prints when you see random mouse clicks. I'm not sure, but probably your mouse expects a certain minimum polling rate, which is passed through the endpoint descriptor, else it goes mad :-) setting hw.usb.ums.debug=15 indicates that the polling rate is set exactly to moused's -F value. Good. at some point i experienced a crash including a reboot. no core dump was produced however. i've tried to reproduce the crash but wasn't able to. i think the crash occured when i booted with a low -F value, then set -F to a higher value in /etc/rc.conf and after that unplugged the mouse and plugged it in again. as i said i'm not able to produce the panic any longer. might have been caused by old code fragments in my /usr/src. --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
ulpt(EPSON PM-820C Inkjet Printer) does not work on 8-current
hi.
I upgrade my home server to 8.0-BETA1(8-current).
But ulpt does not work fine with EPSON PM-820C Ink jet Printer.
dmesg
usbus2: NEC uPD 9210 USB controller on ohci1
ship
usbus2: 12Mbps Full Speed USB v1.0
ulpt0: EPSON USB Printer, class 0/0, rev 1.00/1.00, addr 2 on usbus2
ulpt0: using bi-directional mode
[Problem 1] /etc/devd.conf does not work.
I use EPSON PM-820C with Windows 2000 Professional via samba.
And this printer was needed to send magic packet(which was written
in devd, printf), when I use via USB port. And I restart all print
jobs (``lpc restart all'').
But after I upgrade to 8-current, that was not executed correctly,
I think.
/etc/printcap
lp|local line printer:\
:sh:mx#0:\
:lp=/dev/ulpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
/etc/devd.conf
attach 100 {
device-name ulpt[0-9]+;
match vendor 0x04b8;
match product 0x0005;
match release 0x0100;
action sleep 5;printf '000\033\...@ejl 1284@ejl \n' | tr 0
'\0' /dev/$device-name;
action lpc restart all;
};
detach 100 {
device-name ulpt[0-9]+;
action lprm -;
};
[Problem 2] print job was stop at printing
I send magic packet and restart print job manually.
Print Job which send from Windows 2000 Pro was hung up when
1/3 range of paper size was printed.
No message was output to dmesg.
How can I debug this problem?
Cheers.
---
MIHIRA, Sanpei Yoshiro
Tokyo, Japan.
___
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: ulpt(EPSON PM-820C Inkjet Printer) does not work on 8-current
On Tuesday 14 July 2009 16:35:17 MIHIRA Sanpei Yoshiro wrote:
hi.
I upgrade my home server to 8.0-BETA1(8-current).
But ulpt does not work fine with EPSON PM-820C Ink jet Printer.
dmesg
usbus2: NEC uPD 9210 USB controller on ohci1
ship
usbus2: 12Mbps Full Speed USB v1.0
ulpt0: EPSON USB Printer, class 0/0, rev 1.00/1.00, addr 2 on usbus2
ulpt0: using bi-directional mode
[Problem 1] /etc/devd.conf does not work.
I use EPSON PM-820C with Windows 2000 Professional via samba.
And this printer was needed to send magic packet(which was written
in devd, printf), when I use via USB port. And I restart all print
jobs (``lpc restart all'').
But after I upgrade to 8-current, that was not executed correctly,
I think.
/etc/printcap
lp|local line printer:\
:sh:mx#0:\
:lp=/dev/ulpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:
/etc/devd.conf
attach 100 {
device-name ulpt[0-9]+;
match vendor 0x04b8;
match product 0x0005;
match release 0x0100;
action sleep 5;printf '000\033\...@ejl 1284@ejl \n' | tr
0 '\0' /dev/$device-name; action lpc restart all;
};
detach 100 {
device-name ulpt[0-9]+;
action lprm -;
};
[Problem 2] print job was stop at printing
I send magic packet and restart print job manually.
Print Job which send from Windows 2000 Pro was hung up when
1/3 range of paper size was printed.
No message was output to dmesg.
How can I debug this problem?
Hi,
Replace the USB files in your system with the ones in the attached tarball.
Then build a new kernel and report again.
FreeBSD 8-current only.
tar -jxvf usb_files.tar.bz2 -C /sys/dev/usb
--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: settings usb mouse rate
you were right. i attached a different usb mouse and setting the rate to 10 or 100 didn't cause the random copypaste issue. what's the reason the usb polling rate is limited to 1000? performance? because gaming devices feature a very high rate. would be great to have full support for them. i've seen laser mice with a rate of 10.000. i've attached the output of hw.usb.ums.debug=15 and included a note where the copypaste occured. however when the debug output is enabled the random copypaste issue doesn't appear that often. if a disable the debug output ~ 2 lines per second get pasted to the console when moving the mouse. alex Hans Petter Selasky schrieb am 2009-07-14: On Tuesday 14 July 2009 15:25:59 Alexander Best wrote: i tested the patch with rates of 1, 100 and 1000: 1: random copypastes when moving the mouse 100: also random copypastes when moving the mouse 1000: OK Could you try another USB mouse. Also I would like to see some ums debug prints when you see random mouse clicks. I'm not sure, but probably your mouse expects a certain minimum polling rate, which is passed through the endpoint descriptor, else it goes mad :-) setting hw.usb.ums.debug=15 indicates that the polling rate is set exactly to moused's -F value. Good. at some point i experienced a crash including a reboot. no core dump was produced however. i've tried to reproduce the crash but wasn't able to. i think the crash occured when i booted with a low -F value, then set -F to a higher value in /etc/rc.conf and after that unplugged the mouse and plugged it in again. as i said i'm not able to produce the panic any longer. might have been caused by old code fragments in my /usr/src. --HPS rates.log Description: Binary data ___ 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/136761: [usbdevs] [patch] Teach usbdevs / u3g(4) about Huawei E180v 3G modem
Number: 136761
Category: usb
Synopsis: [usbdevs] [patch] Teach usbdevs / u3g(4) about Huawei E180v 3G
modem
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: change-request
Submitter-Id: current-users
Arrival-Date: Tue Jul 14 16:40:00 UTC 2009
Closed-Date:
Last-Modified:
Originator: Beat Gätzi
Release:FreeBSD 8.0-BETA1 i386
Organization:
Environment:
System: FreeBSD daedalus.network.local 8.0-BETA1 FreeBSD 8.0-BETA1 #10: Tue Jul
14 14:01:16 CEST 2009 r...@daedalus.network.local:/usr/obj/usr/src/sys/BEASTIE
i386
Description:
Add support for Huawei E180v 3G modem:
# usbconfig | grep HUAWEI
ugen6.2: HUAWEI Mobile HUAWEI Technology at usbus6, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON
# usbconfig -u 6 -a 2 dump_device_desc | grep id
idVendor = 0x12d1
idProduct = 0x140c
Functional testing successful with up to date CURRENT and attached
patch.
How-To-Repeat:
Fix:
--- HUAWEI-E180V.patch begins here ---
Index: share/man/man4/u3g.4
===
--- share/man/man4/u3g.4(Revision 195677)
+++ share/man/man4/u3g.4(Arbeitskopie)
@@ -64,7 +64,7 @@
.It
Qualcomm Inc. CDMA MSM
.It
-Huawei B190, E220 ('Huawei Mobile')
+Huawei B190, E180v, E220 ('Huawei Mobile')
.It
Novatel U740, MC950D, X950D, etc.
.It
Index: sys/dev/usb/serial/u3g.c
===
--- sys/dev/usb/serial/u3g.c(Revision 195677)
+++ sys/dev/usb/serial/u3g.c(Arbeitskopie)
@@ -186,6 +186,7 @@
U3G_DEV(QUALCOMMINC, CDMA_MSM, U3GFL_SCSI_EJECT),
/* OEM: Huawei */
U3G_DEV(HUAWEI, MOBILE, U3GFL_HUAWEI_INIT),
+ U3G_DEV(HUAWEI, E180V, U3GFL_HUAWEI_INIT),
U3G_DEV(HUAWEI, E220, U3GFL_HUAWEI_INIT),
/* OEM: Novatel */
U3G_DEV(NOVATEL, CDMA_MODEM, 0),
Index: sys/dev/usb/usbdevs
===
--- sys/dev/usb/usbdevs (Revision 195677)
+++ sys/dev/usb/usbdevs (Arbeitskopie)
@@ -1473,6 +1473,7 @@
/* HUAWEI products */
product HUAWEI MOBILE 0x1001 Huawei Mobile
product HUAWEI E2200x1003 Huawei HSDPA modem
+product HUAWEI E180V 0x140c Huawei Mobile E180V
/* HUAWEI 3com products */
product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g
--- HUAWEI-E180V.patch ends here ---
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
Re: settings usb mouse rate
On Tuesday 14 July 2009 18:29:33 Alexander Best wrote: you were right. i attached a different usb mouse and setting the rate to 10 or 100 didn't cause the random copypaste issue. what's the reason the usb polling rate is limited to 1000? performance? because gaming devices feature a very high rate. would be great to have full support for them. i've seen laser mice with a rate of 10.000. The USB hardware cannot poll more than 1000 times per second on INTERRUPT endpoints typically. Using a BULK endpoint you can at maximum poll 8000 times per second. --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: CPU Cache and busdma usage in USB
On 2009-07-14, at 18:58, Marcel Moolenaar wrote: On Jul 14, 2009, at 2:21 AM, Rafal Jaworowski wrote: On 2009-07-14, at 10:36, Hans Petter Selasky wrote: On Tuesday 14 July 2009 10:31:10 Piotr Zięcik wrote: 1) My analysis: Only the data areas are being flushed/ invalidated. No transfer descriptors are flushed/invalidated. I see no cache operations happening on any DMA control structures, even though there are calls from EHCI to xxx_pc_flush() and xxx_pc_invalidate(). Probaby you see more on your AT91 device as you know USB stack internals. Have you tried to bring up OHCI on you ARM board ? Not yet. I'm terribly busy with some LibUSB stuff headed for the 8- current release. As soon as I find time I will fire off a build and debug. Please note these problems should be considered as a showstopper for the release since USB is currently broken on at least three ARM platforms in the tree (Marvell). Rafal, Anything I can do to help? (as a reminder: I have an Orion board) Your input on the desired final solution to these issues would be appreciated. Please see the beginning of this thread (originated on usb@ ML), where a quick fix was proposed by Piotr. That patch works around the problems for us (also for some MIPS and noncoherent PPC), but the problem here is that we believe that using bus dma for the purpose of cache synchronization is improper in principle, and cpu- specific calls should be used instead, although Hans is rather reluctant to embracing the latter path. BTW: Has pmap been fixed for ARM in 8-current? Seems like the most critical problems (panics) are resolved and will be pushed into SVN shortly. In case you'd like to apply the fix directly, see: http://people.freebsd.org/~raj/patches/arm/pmap-fixes.diff Good! I was about to start a discussion about reverting rev. 194459 for now. We're about to start BETA-2 and it helps (at least Juniper :-) to have 8.0-RELEASE not be DOA :-) No worries, we're also looking forward to 8.0 as a great ARM release :-) I will be following up on that pmap-related stuff, but am waiting for confirmation from stas@ there are no regressions on AT91 with this patch. Rafal ___ 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: settings usb mouse rate
thanks for the info. so right now i'm running the patched kernel with no problems whatsoever. mouse is running smoothly with a rate of 1000. only values 100 cause the issue i mentioned beforehand with this mouse. unfortnunately i lost the manual, but i think two of the buttons on this mouse are meant to control the rate. i don't know if their're output is just being caught by some windows driver-app or if the buttons control the mouse rate internaly. here's the output when pressing both buttons: Jul 14 19:39:54 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:54 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 01 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:282: x:0 y:0 z:-1 t:0 w:0 buttons:0x Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:55 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:55 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:55 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 ff 00 00 00 00 Jul 14 19:39:56 otaku kernel: ums_intr_callback:282: x:0 y:0 z:1 t:0 w:0 buttons:0x Jul 14 19:39:56 otaku kernel: ums_intr_callback:206: sc=0xc826b000 actlen=8 Jul 14 19:39:56 otaku kernel: ums_intr_callback:224: data = 00 00 00 00 00 00 00 00 alex Hans Petter Selasky schrieb am 2009-07-14: On Tuesday 14 July 2009 18:29:33 Alexander Best wrote: you were right. i attached a different usb mouse and setting the rate to 10 or 100 didn't cause the random copypaste issue. what's the reason the usb polling rate is limited to 1000? performance? because gaming devices feature a very high rate. would be great to have full support for them. i've seen laser mice with a rate of 10.000. The USB hardware cannot poll more than 1000 times per second on INTERRUPT endpoints typically. Using a BULK endpoint you can at maximum poll 8000 times per second. --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: CPU Cache and busdma usage in USB
On Jul 14, 2009, at 2:21 AM, Rafal Jaworowski wrote: On 2009-07-14, at 10:36, Hans Petter Selasky wrote: On Tuesday 14 July 2009 10:31:10 Piotr Zięcik wrote: 1) My analysis: Only the data areas are being flushed/ invalidated. No transfer descriptors are flushed/invalidated. I see no cache operations happening on any DMA control structures, even though there are calls from EHCI to xxx_pc_flush() and xxx_pc_invalidate(). Probaby you see more on your AT91 device as you know USB stack internals. Have you tried to bring up OHCI on you ARM board ? Not yet. I'm terribly busy with some LibUSB stuff headed for the 8- current release. As soon as I find time I will fire off a build and debug. Please note these problems should be considered as a showstopper for the release since USB is currently broken on at least three ARM platforms in the tree (Marvell). Rafal, Anything I can do to help? (as a reminder: I have an Orion board) BTW: Has pmap been fixed for ARM in 8-current? Seems like the most critical problems (panics) are resolved and will be pushed into SVN shortly. In case you'd like to apply the fix directly, see: http://people.freebsd.org/~raj/patches/arm/pmap-fixes.diff Good! I was about to start a discussion about reverting rev. 194459 for now. We're about to start BETA-2 and it helps (at least Juniper :-) to have 8.0-RELEASE not be DOA :-) -- Marcel Moolenaar xcl...@mac.com ___ 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
Atheros wireless device driver developer
Hello Everyone, I have an opportunity for a device driver developer with a heavy wireless Atheros background. Please let me know if anyone is interested or might know someone. Please see job description below. Thank you very much -Dave Senior Software Engineer with WLAN Device Driver Development Experience The ideal candidate will have several years of communication experience as well as experience programming low level hardware drivers. Requirements: * BSCS or BSEE or relevant experience * 5+ years of experience in development of WLAN device drivers * Fluency in coding and debugging C * Experience with Atheros drivers a plus * Expertise in one or more of these protocols: § 802.11 § ATM § Sonet/SDH § NDIS § Bluetooth § Ethernet, GBit Ethernet * Experience with one or more of the following operating systems: § MS Windows, WinCE § Linux § Embedded RTOS David A. Horvay Sr. Account Executive Technology Solutions Division MRINetwork Ultimate Placements, LLC One Park Centre Drive, Suite 305A TF:877-334-0285 ext. 202 dhor...@4whitetiger.com blocked::blocked::http://www.linkedin.com/in/davidhorvay http://www.linkedin.com/in/davidhorvay www.MRINetwork.com blocked::blocked::http://www.mrinetwork.com/ blocked::blocked::http://www.mrinetwork.com/ BUILDING THE HEART OF BUSINESS (TM) Please understand my mission at MRI Ultimate Placements is to partner with those select clients where there is a philosophical fit. My goal has never been to be all things to all people. As a client-focused search consultant I evaluate each potential assignment based on alignment with my area of expertise and the timing and urgency of each search. ___ 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
ukbd vs. uhid
Hi all,
just bumping this issue, triggered by the mentioning of PR 102066, and
using a better subject line which might receive replies :-)
While trying to get my keyboard and its multimedia keys to work with
usbhidctl (it doesn't really work at the moment), I came across this:
- the keyboard is only handled by *either* ukbd *or* uhid. In fact, if
unpatched, uhid will not even try to consider the device, because of the
following code inside uhid.c's uhid_probe() function:
if (uaa-use_generic == 0) {
/* give Mouse and Keyboard drivers a try first */
return (ENXIO);
}
That means that the keyboard always ends up as device ukbdX, and never
as uhidY.
Before even trying to get it to work using uhid, I think this is the
issue that needs to be sorted out: Can a device be handled by *two*
independent drivers at once?
- If so, how?
- If not, what could a possible solution be?
Thanks cheers,
Chris
___
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: Atheros wireless device driver developer
You know, it would be a lot easier if you just email Sam directly rather than spam the lists with this :) Especially since you don't mention FreeBSD at all... 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
