bugzilla-noreply | 20 May 23:15 2016
Picon

[Bug 209674] USB keyboard's keys become sticky

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209674

            Bug ID: 209674
           Summary: USB keyboard's keys become sticky
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb <at> FreeBSD.org
          Reporter: bourne.identity <at> hotmail.com
                CC: freebsd-amd64 <at> FreeBSD.org
                CC: freebsd-amd64 <at> FreeBSD.org

I would like to report a possible bug on my amd64 system running FreeBSD 10.2,
which at least one gentleman also suffers from on his 10.3 system. While typing
with the X server running, keys of my keyboard become 'sticky': pressing 'A'
once results in multiple (dozens, sometimes hundreds) of 'A'. This nuisance -
which happens about once in 5 minutes of typing - usually stops by itself and
the key gets 'unstuck' automatically after a couple of seconds. This happens
only under FreeBSD (not Linux, not Windows) and only under the X server (not
when typing on the console when there is no X).

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
(Continue reading)

bugzilla-noreply | 19 May 12:53 2016
Picon

[Bug 209636] usr/src/sys/dev/usb/controller/generic_ohci.c:169: possible bad size ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209636

            Bug ID: 209636
           Summary: usr/src/sys/dev/usb/controller/generic_ohci.c:169:
                    possible bad size ?
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb <at> FreeBSD.org
          Reporter: dcb314 <at> hotmail.com

[usr/src/sys/dev/usb/controller/generic_ohci.c:169]: (warning) Size of pointer
'clkp' used instead of size of its data.

Source code is

  clkp = malloc(sizeof(clkp), M_DEVBUF, M_WAITOK | M_ZERO);

Maybe better code

  clkp = malloc(sizeof(*clkp), M_DEVBUF, M_WAITOK | M_ZERO);

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
(Continue reading)

bugzilla-noreply | 17 May 20:53 2016
Picon

[Bug 209586] Ozone Strike Pro Keyboard bugged

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209586

            Bug ID: 209586
           Summary: Ozone Strike Pro Keyboard bugged
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: usb
          Assignee: freebsd-usb <at> FreeBSD.org
          Reporter: jakob <at> gillich.me
                CC: freebsd-amd64 <at> FreeBSD.org
                CC: freebsd-amd64 <at> FreeBSD.org

I have a "Ozone Strike Pro" USB keyboard that is pretty bugged on FreeBSD
-CURRENT r299864 (yesterday's head) and 20160429-r298793 (the latest snapshot).
Relevant dmesg output:

ugen1.3: <vendor 0x058f> at usbus1
uhub5: <vendor 0x058f product 0x6254, class 9/0, rev 2.00/1.00, addr 3> on
usbus1
uhub5: 4 ports with 4 removable, self powered
ugen1.4: <vendor 0x04d9> at usbus1
ukbd1: <vendor 0x04d9 USB Keyboard, class 0/0, rev 2.00/d.04, addr 4> on usbus1
kbd3 at ukbd1
ukbd2: <vendor 0x04d9 USB Keyboard, class 0/0, rev 2.00/d.04, addr 4> on usbus1
kbd4 at ukbd2
(Continue reading)

Karl Denninger | 17 May 18:53 2016
Picon
Gravatar

Oddity with ugen

Consider the following snippet of code....

                sprintf(tmp, "/dev/usb/0.%d.1", x); /* Get input handle */
                _i = open(tmp, O_RDONLY|O_NDELAY);  /* Open it */
                if (_i < 0) {
                    syslog(LOG_WARNING, "Error opening USB input channel
(%d)", errno);
                } else {
                    y = 8;  /* Set buffer size */
                    if (ioctl(_i, USB_SET_RX_BUFFER_SIZE, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB buffer");
                    }
                    y = 0;  /* Set timeout */
                    if (ioctl(_i, USB_SET_RX_TIMEOUT, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB timeout
to zero")
;
                    }
                    y = 1;  /* Set short xfer ok */
                    if (ioctl(_i, USB_SET_RX_SHORT_XFER, &y) < 0) {
                        syslog(LOG_WARNING, "Error setting USB short XFER");
                    }
                }
                sprintf(tmp, "/dev/usb/0.%d.2", x); /* Get output handle */
                _o = open(tmp, O_WRONLY);   /* Open it */
                if (_o < 0) {
                    syslog(LOG_WARNING, "Error opening USB output
channel (%d)", errno);
                } else {
                    y = 8;  /* Set buffer size; low-speed device */
(Continue reading)

Neal Horman | 14 May 20:50 2016

Re: ehci_disown - Olimex ARM A20 Lime & USB FTDI RS-485 shuts down USB port

On 5/12/16 7:00 AM, freebsd-usb-request <at> freebsd.org wrote:

>> ehci_disown() means that there should be a full speed controller that should
>> handle the device, because it is not high-speed. Does your board have
>> OHCI/UHCI or only EHCI? How are the USB parts wired. Is there a High-Speed TT
>> (USB HUB chip) connected to the EHCI port?
> The A20 SoC has an OHCI controller but the ALLWINNER kernel is missing the
> ohci driver. There is a patch for review here: https://reviews.freebsd.org/D5481
>
> Cheers,
> Jared

Jared:
     Thanks for pointing me to the patch, that was very helpful.

All:
     I can report that I was able to apply the D5481 patch to svn.head 
revision 298609 after changing the kernel conf A20 patched file name to 
ALLWINNER.
     The kernel built without errors.
     I installed the kernel, and the ohci driver appears to attach and 
work correctly with my FTDI devices.

Emanuel:
     Overall, I'd like to see this committed because it appears to be 
functional.
     Although, I wouldn't / don't expect to have to include the "device 
ohci" and "device generic_ohc" drivers for the kernel to work correctly 
on the platform.
     It just doesn't make sense in my mind and doesn't feel right.
(Continue reading)

bugzilla-noreply | 14 May 09:48 2016
Picon

[Bug 209495] [ure] [patch] support for Lenovo USB-ethernet adapter USB3NETWORK

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209495

            Bug ID: 209495
           Summary: [ure] [patch] support for Lenovo USB-ethernet adapter
                    USB3NETWORK
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb <at> FreeBSD.org
          Reporter: hannes <at> mehnert.org
          Keywords: patch

Created attachment 170270
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170270&action=edit
lenovo usb device ID, quirk, and registration into ure

Lenovo ThinkPad Network Adapter (part no 4X90E51405), USB3.0 to RJ45 contains a
realtek 8153 chip, which is supported by the ure driver (rtl8152)

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
Neal Horman | 11 May 19:22 2016

Re: freebsd-usb Digest, Vol 573, Issue 1

Hello Hans,

On 5/11/16 7:00 AM, freebsd-usb-request <at> freebsd.org wrote:
> Hi,
>
> ehci_disown() means that there should be a full speed controller that
> should handle the device, because it is not high-speed

Ok

> Does your board have OHCI/UHCI or only EHCI?

It's EHCI/OHCI... from the A20 User Manual revision 1.3  <at>  
http://dl.linux-sunxi.org/A20/
--- start ---
User USB Host controller is fully compliant with the USB 2.0 
specification, Enhanced Host Controller Interface (EHCI) Specification, 
Revision 1.0, and the Open Host Controller Interface (OHCI) 
Specification Release 1.0a. The controller supports high-speed, 480-Mbps 
transfers (40 times faster than USB 1.1 full-speed mode) using an EHCI 
Host controller, as well as full and low speed through one or more 
integrated OHCI host controllers.
--- end ---

> How are the USB parts wired.
Acording to

https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/A20-OLinuXino-LIME/A20-OLinuXino-Lime_Rev_C.pdf, 
the two USB Host connectors are wired through a SY6280 for 5V power 
control and current limiting, but otherwise, D+ and D- are directly 
(Continue reading)

Neal Horman | 11 May 00:03 2016

ehci_disown - Olimex ARM A20 Lime & USB FTDI RS-485 shuts down USB port

Hello,
     Sorry for the cross post, but I'm not sure were this should land.
     I posted on https://forums.freebsd.org/threads/56211/ and it was 
suggested that I ask here.

     I'm having problems trying to get my host to recognize a USB FTDI 
RS-485 serial port on an Olimex ARM A20 Lime host.

     To be clear, this is not a "I need to connect to the host console 
port" problem, that is done and works.

     I'm trying to use the RS-485 port to talk to Modbus devices with a 
custom application.

     The FTDI device has been tested on other hosts, and it works.
     When I use the same device on this host running Linux, it works 
just fine.

     When I insert the FTDI RS-485 device (or any other FTDI or Prolific 
serial device) into the FreeBSD host USB connector with 
hw.usb.ehci.debug = 1 I get:

         ehci_roothub_exec: ehci after reset, status=0x00001801
         ehci_disown: index=1 lowspeed=0

     and then the port is unresponsive to any device plug events afterwards.

     I used svn.head -r 298609 and crochet w/ a derived version of 
cubieboard2 board profile and the ALLWINNER kernel.
     I've tried the Olimex DTBs that get built from that profile, but 
(Continue reading)

Karl Denninger | 30 Apr 16:06 2016
Picon
Gravatar

Prevent attach of modem serial emulated device on USB attach?

So I have managed to get access via ugen to one of the USB devices I
want to talk to.

I would like to generalize that in a library, but am confounded by a
/second /device that comes up "looking like a modem", although it is
not.  This is convenient if you want to open and deal with it like a
modem, but unfortunately that attachment appears to prevent me from
successfully using it with the ugen interface at the same time, as the
attachment looks like it "eats" the inbound byte stream.

Is there a reasonably-easy way to /prevent /FreeBSD from declaring this
device eligible to be attached as if it was a character-style modem,
leaving it only on ugen?  I have figured out how to use devd to change
permissions on attach, but not how to prevent it from attaching a
generic USB device to a specific driver.

--

-- 
Karl Denninger
karl <at> denninger.net <mailto:karl <at> denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
Attachment (smime.p7s): application/pkcs7-signature, 4051 bytes
bugzilla-noreply | 30 Apr 02:00 2016
Picon

[Bug 208632] 11.0-CURRENT crashes after removing TP-LINK TL-WN725N USB Wi-Fi adapter (urtwn)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208632

Johannes Lundberg <johannes <at> brilliantservice.co.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannes <at> brilliantservice.c
                   |                            |o.jp

--- Comment #3 from Johannes Lundberg <johannes <at> brilliantservice.co.jp> ---
Solved with fix in bug #208605, comment #3 ?

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
bugzilla-noreply | 27 Apr 17:22 2016
Picon

[Bug 208605] Kernel panic when unplug and replug USB WiFi dongle.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208605

Johannes Lundberg <johannes <at> brilliantservice.co.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Closed
         Resolution|---                         |FIXED

--- Comment #4 from Johannes Lundberg <johannes <at> brilliantservice.co.jp> ---
Seems to been fixed. No more crashes now. Thank you!

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Gmane