Re: USB problem with keyboard
Em Sat, 11 Feb 2017 14:23:26 +0100, Hans Petter Selasky escreveu > Hi, > > You might want to check the PCI ID's with Linux's EHCI/OHCI/UHCI and > see if there are particular quirks missing for your ATI USB chipset. hu I have in this machine dual boot with Windowns 10, I'm instal to test my keyoard, and it's work fine. I'll try with Linux. I > > --HPS > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB problem with keyboard
Hi, You might want to check the PCI ID's with Linux's EHCI/OHCI/UHCI and see if there are particular quirks missing for your ATI USB chipset. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
USB problem with keyboard
Hi All, I changed my old multimedia keyboard (Genius) to a new one small and simple keyboard. I thought the problem was the dirty on the keyboard so i clened but it's still not working well ( it's not showing all keys pressed or sometimes repeat the last key pressed). This problem was started when I updated my box, but I had other old problem that I ignored for a while My usb mouse and my no-break APC random disconnect and reconnect sometimes per hours dmesg.yesterday:ugen0.2: at usbus0 dmesg.yesterday:ugen0.2: at usbus0 (disconnected) root@valfenda:/var/log # uname -a FreeBSD valfenda 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r313095: Fri Feb 3 17:48:08 BRST 2017 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 root@valfenda:/var/log # usbconfig list ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAV (0mA) ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAV (0mA) ugen5.1: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAE (0mA) ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAV (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps pwr=ON (100mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pr=SAVE (100mA) ugen2.3: at usbus2, cfg=0 md=HOST spd=HIGH (40Mbps) pwr=ON (100mA) ugen2.4: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps)pwr=SAVE (100mA) ugen2.5: at ubus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (0mA) ugen2.6: at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pw=ON (98mA) ugen2.7: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbs) pwr=ON (250mA) My mothboard is: ASUS M5A78L CPU: AMD FX(tm)-8300 Eight-Core Processor(3465.07-MHz K8-class CPU) Ps. I typed only once a letter t and it has been repeated sometimes --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
I found easy way to ugen problem: in /etc/devfs.rules I added [local_ruleset=10] add path 'ugen*' mode 664 then in /etc/rc.conf devfs_system_ruleset=local_ruleset And this is it. Now user can acces camera (PowerShots50) with gtkam. The resolution was given by (http://lists.freebsd.org/pipermail/freebsd-current/2003-September/009706.html) Jeff Walters*. *Based on man devfs it is impossible to resolve this issue. * * ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
Hi, have severe problems accessing usb devices as non-root user. In this case a Canon Powershot G5 camera. I want to download pics from my digicam using digikam application as user andreas. The devices that are being used by digikam: [EMAIL PROTECTED] ~ lsof | grep digikam | grep /dev digikam 1755root0u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root1u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root2u VCHR5,2 0t19646 110 /dev/ttyp2 digikam 1755root 15u VCHR 114,16 0t0 128 /dev/ugen1 digikam 1755root 16r VCHR 114,17 0t7817 131 /dev/ugen1.1 digikam 1755root 17r VCHR 114,190t16 133 /dev/ugen1.3 Running digikam with SUID root bit turned on doesn't work. [EMAIL PROTECTED] ~ digikam The KDE libraries are not designed to run with suid privileges. Changing the permissions on /dev/ugen1* doesn't work either since - even _if_ the devices are present after turning camera on and - even _if_ permissions of /dev/ugen1 /dev/ugen1.1 ... 1.3 are being changed successfully to 666 the devices seems to be on the 1st access dynamically recreated, since the permissions suddenly are *re-set* to root 644 automagically after the 1st access of the digikam application as user. To sum up: as normal user I'm unable to connect to the USB camera. Is there a more generic approach to be able to use USB devices as non-root user, that I overlooked up to now ? Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
On Mon, Oct 20, 2003 at 12:19:46PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm wri tes: Hi, have severe problems accessing usb devices as non-root user. In this case a Canon Powershot G5 camera. I want to download pics from my digicam using digikam application as user andreas. Use the devfs(8) command to request changes the owner or modes to suit your needs. This works a bit like firewall rules and when the device is created the modes/owner is set. Good idea. But no success and inexpected results. Well now I use both /etc/devfs.conf and devfs rule add in /etc/rc.local. It was 1st unclear to me after reading the devfs(8) manpage, that the devfs rule add - command 1st needs a command like devfs ruleset 100 So now I have 1) /etc/devfs.conf with: permugen1 0666 permugen1.1 0666 permugen1.2 0666 permugen1.3 0666 and 2) devfs rule show 100 path ugen mode 666 I halted system, turned camera off and on Booted FreeBSD. 1. Step, check permissions without having started any camersa application ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-rw-rw- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-rw-rw- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-rw-rw- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 You see the camera is on, therefore the ugen1 devices have been created. Good so far. A bit strange is, that ugen0 (USB printer) still has mode 644, this is the printer... I would expect, that the devfs rule 100 would have been applied by the system and it should be active for this device as well ! Note: And later we see, that even the permission of the ugen1 interface change again to 644 after the 1st access or whatever ! Well lets repeat, the machine is freshly restarted, camera was on and ugen1 devices have 0666. 2. step: start digikam as user [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-rw-rw- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-rw-rw- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-rw-rw- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 The startup itself is harmless nothing happens and no access to camera. The digikam application has a config files and presents the camera found in the last session (from config file). 3. step, try to access camera by klick on the Canon PowerShot G5 line in digikam failed to initialize the camera [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. Note: I think the lpd daemon accesses the printer on startup. Therefore the ugen0 device already had the new permission 644 which I observed in the previous step ! Any idea how to resolve this ? And BTW, shouldn't the devfs(8) manpage have a reference to devfs.conf ? I understand, that /etc/devfs.conf is only used by the /etc/rc.d/devfs startup script, to setup permissions via chmod commands and such so no real relationship to the devfs command. But I'd find it useful to have a reference to it. Or ... something like a devfs.conf(5) manpage is missing and a SEE ALSO devfs.conf(5) in devfs(8) is missing, what would probably be better ... Or what do you think ? -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
In message [EMAIL PROTECTED], Andreas Klemm writ es: 1) /etc/devfs.conf with: permugen1 0666 permugen1.1 0666 permugen1.2 0666 permugen1.3 0666 I would probably just use a wildcard: permugen* 0666 1st needs a command like devfs ruleset 100 This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. 3. step, try to access camera by klick on the Canon PowerShot G5 line in digikam failed to initialize the camera [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. And BTW, shouldn't the devfs(8) manpage have a reference to devfs.conf ? I understand, that /etc/devfs.conf is only used by the /etc/rc.d/devfs startup script, to setup permissions via chmod commands and such so no real relationship to the devfs command. Yes, probably a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
Poul-Henning, many thanks for you kind guidance to the wonderful world of devfs (which I never had to tweak in the past) ;-) On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: I would probably just use a wildcard: permugen* 0666 The wildcard feature is really fine ! Thanks for pointing me into that direction. This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. Good hint ! Thanks ! Well and now things work like expected. I put these devfs commands now into /etc/rc.local. But since /etc/rc.local officially has gone, I think this is not the best place ... After a longer examination of /etc/devfs, /etc/rc.subr /etc/defaults/devfs.rules and /etc/defaults/rc.conf I got the clue, that I can put the statements into /etc/devfs.rules. Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
In message [EMAIL PROTECTED], Andreas Klemm writ es: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) I personally end up less(1)'ing /etc/rc.d/* every time I want to do something... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
On Mon, Oct 20, 2003 at 02:40:00PM +0200, Poul-Henning Kamp wrote: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) That's not the right attitude for something that is 100% your baby. You've added a completely new subsystem to FreeBSD, one that people have no choice but to deal with when they move from 4.x to 5.x since you made devfs mandatory. It is YOUR responsibility to document it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm writ es: [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. An USB device can be switched between several alternative configurations. If such a change is requested (USB_SET_CONFIG) the devicenode for everything but the control channel is recreated. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted
In message [EMAIL PROTECTED], Bernd Walter writes: On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Andreas Klemm writ es: [EMAIL PROTECTED] ~ ls -l /dev/ugen* crw-r--r-- 1 root operator 114, 0 Oct 20 13:14 /dev/ugen0 crw-r--r-- 1 root operator 114, 2 Oct 20 13:14 /dev/ugen0.2 crw-rw-rw- 1 root operator 114, 16 Oct 20 13:14 /dev/ugen1 crw-r--r-- 1 root operator 114, 17 Oct 20 13:14 /dev/ugen1.1 crw-r--r-- 1 root operator 114, 18 Oct 20 13:14 /dev/ugen1.2 crw-r--r-- 1 root operator 114, 19 Oct 20 13:14 /dev/ugen1.3 And voila, ther permission are wrong again. I have no idea what goes on here. An USB device can be switched between several alternative configurations. If such a change is requested (USB_SET_CONFIG) the devicenode for everything but the control channel is recreated. But the devfs rules should still set the mode when it is recreated... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB problem (Who owns USB code in -current?)
Dear Hackers, i'm replying to myself, because i think i might have found some more information on the problem. i would appreciate if any USB expert would care to comment on this. please take a look at http://www.geocities.com/m_evmenkin/usb/24505201.pdf and look for USB Dribble section. Let me quote it here quote 12. USB Dribble Issue: A USB receive packet with a bitstuff following the transmission of CRC, coupled with a dribble bit due to prop delays through cables and HUBs, may be incorrectly interpreted by the USB host controller state machine as a poorly formed EOP. Implication: The host controller response to this is a non-acknowledge with a CRC/Timeout status communicated to the software. If this condition persists, the error count associated with this packet will be exceeded and an interrupt can be generated to software. This will stall the USB device. Current software reports a device error to the user via a pop-up window. Another implication is that the installed base may have limited USB expandability via HUBs. Workaround: There are two possible workarounds. 1. Hardware: Attach the USB device into a USB port closer to the root hub. 2. Software: Detect the CRC/Timeout error and count exceeded and attempt to re-queue the packets while changing the length of the packets. Changing the length of the packets will change the CRC and thus will likely remove the combination of the two events causing the failure. Status: Fixed in B-0 stepping. Note: This erratum was carried over from the Intel® 82371EB (PIIX4E). /quote Needless to say that i have Intel 82371AB/EB chip in my laptop *and* i'm getting CRCTO,TIMEOUT errors. all the dumps still available at http://www.geocities.com/m_evmenkin/usb/ could this be the problem? thanks, max Maksim Yevmenkin wrote: Dear Hackers, Who owns USB code in -current? I need an USB expert advice on the FreeBSD specific USB problem. Basically whenever i put my laptop into docking station and try to plug Bluetooth USB dongle i get uhub1: device problem, disabling port 1 message. This problem *does not* exist when i try to connect the USB dognle directly to the laptop. My current theory is that extra USB hub in docking station somehow makes the difference. I have attached few files that might help. This problem is FreeBSD-specific and seems related to Bluetooth USB dongles only. I have been contacted by other people who have the same problem. I do not know what is so special about Bluetooth USB dongles. USB mouse, for example, works fine. Can it be power related? Both Windows and Linux do not have this problem which makes me think that there is something different about FreeBSD way of doing things. Please advice. I will try to read USB spec, but if someone could give me the right direction, that would be helpful. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
Maksim Yevmenkin wrote: 1. Hardware: Attach the USB device into a USB port closer to the root hub. 2. Software: Detect the CRC/Timeout error and count exceeded and attempt to re-queue the packets while changing the length of the packets. Changing the length of the packets will change the CRC and thus will likely remove the combination of the two events causing the failure. Status: Fixed in B-0 stepping. Note: This erratum was carried over from the Intel® 82371EB (PIIX4E). /quote Needless to say that i have Intel 82371AB/EB chip in my laptop *and* i'm getting CRCTO,TIMEOUT errors. all the dumps still available at 3. Return your hardware for replacement by hardware with B-0 or higher stepping. 8-). Yes, it's likely the problem. The proper fix is probably #2, since it will make it work, no matter if you have bad hardware or not. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Mon, Nov 04, 2002 at 10:33:24AM -0800, Maksim Yevmenkin wrote: This problem is FreeBSD-specific and seems related to Bluetooth USB dongles only. I have been contacted by other people who have the same problem. I do not know what is so special about Bluetooth USB dongles. USB mouse, for example, works fine. Can it be power related? Both Windows and Linux do not have this problem which makes me think that there is something different about FreeBSD way of doing things. Compile the kernel with 'option USB_DEBUG' and then tweak the hw.usb sysctls to get debug output for your controller, the usb stack and the uhub. Maybe this will shed some light on the problem. 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. = msg46163/pgp0.pgp Description: PGP signature
Re: USB problem (Who owns USB code in -current?)
Josef, This problem is FreeBSD-specific and seems related to Bluetooth USB dongles only. I have been contacted by other people who have the same problem. I do not know what is so special about Bluetooth USB dongles. USB mouse, for example, works fine. Can it be power related? Both Windows and Linux do not have this problem which makes me think that there is something different about FreeBSD way of doing things. Compile the kernel with 'option USB_DEBUG' and then tweak the hw.usb sysctls to get debug output for your controller, the usb stack and the uhub. Maybe this will shed some light on the problem. i *did* compile my kernel with USB_DEBUG and *did* tweak sysctl's. i even attached the dump to my previous message. it seems there is some kind of communication error on the bus and stack can not get device descriptor. i need to know what might cause these communication errors. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
Josef, This problem is FreeBSD-specific and seems related to Bluetooth USB dongles only. I have been contacted by other people who have the same problem. I do not know what is so special about Bluetooth USB dongles. USB mouse, for example, works fine. Can it be power related? Both Windows and Linux do not have this problem which makes me think that there is something different about FreeBSD way of doing things. Compile the kernel with 'option USB_DEBUG' and then tweak the hw.usb sysctls to get debug output for your controller, the usb stack and the uhub. Maybe this will shed some light on the problem. i *did* compile my kernel with USB_DEBUG and *did* tweak sysctl's. i even attached the dump to my previous message. I didn't see the dump, just the output of usbdevs. Maybe I missed it. it seems there is some kind of communication error on the bus and stack can not get device descriptor. i need to know what might cause these communication errors. It's got to be a bug in the uhub area. You said that it works ok if the device is plugged in directly? What I'd like to see is the output with: hw.*.usb.debug=50 hw.*.uhub.debug=50 i set all sysctl's to 99 and put the all the dumps at http://www.geocities.com/m_evmenkin/usb/ may be attachment was too big for the list. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Mon, Nov 04, 2002 at 10:33:24AM -0800, Maksim Yevmenkin wrote: Dear Hackers, Who owns USB code in -current? I need an USB expert advice on the FreeBSD specific USB problem. Basically whenever i put my laptop into docking station and try to plug Bluetooth USB dongle i get uhub1: device problem, disabling port 1 Is you usb hub really self powered as it claims to be? If it is not the problem you are seeing is not surprising. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
Bernd, Who owns USB code in -current? I need an USB expert advice on the FreeBSD specific USB problem. Basically whenever i put my laptop into docking station and try to plug Bluetooth USB dongle i get uhub1: device problem, disabling port 1 Is you usb hub really self powered as it claims to be? If it is not the problem you are seeing is not surprising. the hub (the TI one) is the inside docking station. i've no idea if its self powered or not. how can i check it? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
On Wed, Nov 06, 2002 at 09:33:16PM +, Josef Karthauser wrote: On Wed, Nov 06, 2002 at 01:00:43PM -0800, Maksim Yevmenkin wrote: Bernd, Who owns USB code in -current? I need an USB expert advice on the FreeBSD specific USB problem. Basically whenever i put my laptop into docking station and try to plug Bluetooth USB dongle i get uhub1: device problem, disabling port 1 Is you usb hub really self powered as it claims to be? If it is not the problem you are seeing is not surprising. the hub (the TI one) is the inside docking station. i've no idea if its self powered or not. how can i check it? If it's inside the docking station I would assume that it's powered. Agreed - I had overread this detail. On my machine with an external hub I do get messages about power budget being exceeded so it's probably not that. That's a design issue. Some ports implement overcurrent protection by self healing fuses. Others do not even that. I've seen many awfull cheap implementations. Btw.: I had seen similar problems with a self build device on some ports. It turned out to be a problem with the device oscillator to not properly work under some conditions. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB problem (Who owns USB code in -current?)
Josef Karthauser wrote: On Wed, Nov 06, 2002 at 10:43:50PM +0100, Bernd Walter wrote: On Wed, Nov 06, 2002 at 09:33:16PM +, Josef Karthauser wrote: If it's inside the docking station I would assume that it's powered. Agreed - I had overread this detail. On my machine with an external hub I do get messages about power budget being exceeded so it's probably not that. That's a design issue. Some ports implement overcurrent protection by self healing fuses. Others do not even that. I've seen many awfull cheap implementations. Btw.: I had seen similar problems with a self build device on some ports. It turned out to be a problem with the device oscillator to not properly work under some conditions. Hmm, ok. Then this is the most likely explanation then. i doubt. both Linux and Windows have no problem with the device. everything else is the *same* (laptop, docking station, etc). do USB dumps make any sense? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB problem (Who owns USB code in -current?)
Dear Hackers, Who owns USB code in -current? I need an USB expert advice on the FreeBSD specific USB problem. Basically whenever i put my laptop into docking station and try to plug Bluetooth USB dongle i get uhub1: device problem, disabling port 1 message. This problem *does not* exist when i try to connect the USB dognle directly to the laptop. My current theory is that extra USB hub in docking station somehow makes the difference. I have attached few files that might help. This problem is FreeBSD-specific and seems related to Bluetooth USB dongles only. I have been contacted by other people who have the same problem. I do not know what is so special about Bluetooth USB dongles. USB mouse, for example, works fine. Can it be power related? Both Windows and Linux do not have this problem which makes me think that there is something different about FreeBSD way of doing things. Please advice. I will try to read USB spec, but if someone could give me the right direction, that would be helpful. thanks, max boot-v.txt.gz Description: GNU Zip compressed data usb-messages.txt.gz Description: GNU Zip compressed data Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 uhub0 port 1 powered port 2 addr 2: full speed, self powered, config 1, UT-USB41 hub(0x1446), Texas Instruments(0x0451), rev 1.00 uhub1 port 1 powered port 2 powered port 3 powered port 4 powered
USB problem
hiya, While attaching USB Flash card reader to FreeBSD box I am getting message: _ uhub0: device problem, disabling port 1 - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
