From hps at selasky.org  Wed Oct  1 06:34:18 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 01 Oct 2014 08:34:11 +0200
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <CAB8uncbtGf+SP5CqRvixMBFF0VKm+ZsBi0h7_nnQ9+eTgjXS2g@mail.gmail.com>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>	<542A92AF.8040606@selasky.org>	<CAB8uncYPv5xFnzHXZjmAEBF=_OxJ4KD47O_1_6NtkkAduRZijQ@mail.gmail.com>	<542AA716.3070701@selasky.org>	<CAB8uncb3qUGnv-Ppa_PnQj0shMP-ZssT-OUJ85Ltq2aXc_fasA@mail.gmail.com>	<542AAEE2.70206@selasky.org>	<CAB8uncYKJYzJbXFWZUmqKCCdvCVUYPKRZu26k-PHMi3vWj-yaQ@mail.gmail.com>	<542AB58D.9080602@selasky.org>
 <CAB8uncbtGf+SP5CqRvixMBFF0VKm+ZsBi0h7_nnQ9+eTgjXS2g@mail.gmail.com>
Message-ID: <542BA063.3060105@selasky.org>

On 09/30/14 16:12, Huang Wen Hui wrote:
> http://sw.gddsn.org.cn/freebsd/hps-bios-message.txt
> http://sw.gddsn.org.cn/freebsd/hps-uefi-message.txt
>

Hi,

Can you try the attached patch again, and send verbose dmesg including 
xhci debug on?

--HPS


From huanghwh at gmail.com  Wed Oct  1 07:24:07 2014
From: huanghwh at gmail.com (Huang Wen Hui)
Date: Wed, 1 Oct 2014 15:24:04 +0800
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <542BA063.3060105@selasky.org>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>
 <542A92AF.8040606@selasky.org>
 <CAB8uncYPv5xFnzHXZjmAEBF=_OxJ4KD47O_1_6NtkkAduRZijQ@mail.gmail.com>
 <542AA716.3070701@selasky.org>
 <CAB8uncb3qUGnv-Ppa_PnQj0shMP-ZssT-OUJ85Ltq2aXc_fasA@mail.gmail.com>
 <542AAEE2.70206@selasky.org>
 <CAB8uncYKJYzJbXFWZUmqKCCdvCVUYPKRZu26k-PHMi3vWj-yaQ@mail.gmail.com>
 <542AB58D.9080602@selasky.org>
 <CAB8uncbtGf+SP5CqRvixMBFF0VKm+ZsBi0h7_nnQ9+eTgjXS2g@mail.gmail.com>
 <542BA063.3060105@selasky.org>
Message-ID: <CAB8uncburHy73G2sG1nqnUn+vZR8jWFOukawYsxxArq4ETGQfA@mail.gmail.com>

verbose dmesg with patch, hw.usb.xhci.debug=16 and hw.usb.xhci.use_polling=1

http://sw.gddsn.org.cn/freebsd/hps-bios-message2.txt
<http://sw.gddsn.org.cn/freebsd/hps-bios-message.txt>
http://sw.gddsn.org.cn/freebsd/hps-uefi-message2.txt
<http://sw.gddsn.org.cn/freebsd/hps-uefi-message.txt>


2014-10-01 14:34 GMT+08:00 Hans Petter Selasky <hps at selasky.org>:

> On 09/30/14 16:12, Huang Wen Hui wrote:
>
>> http://sw.gddsn.org.cn/freebsd/hps-bios-message.txt
>> http://sw.gddsn.org.cn/freebsd/hps-uefi-message.txt
>>
>>
> Hi,
>
> Can you try the attached patch again, and send verbose dmesg including
> xhci debug on?
>
> --HPS
>
>

From hps at selasky.org  Wed Oct  1 07:30:24 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 01 Oct 2014 09:30:17 +0200
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <CAB8uncburHy73G2sG1nqnUn+vZR8jWFOukawYsxxArq4ETGQfA@mail.gmail.com>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>	<542A92AF.8040606@selasky.org>	<CAB8uncYPv5xFnzHXZjmAEBF=_OxJ4KD47O_1_6NtkkAduRZijQ@mail.gmail.com>	<542AA716.3070701@selasky.org>	<CAB8uncb3qUGnv-Ppa_PnQj0shMP-ZssT-OUJ85Ltq2aXc_fasA@mail.gmail.com>	<542AAEE2.70206@selasky.org>	<CAB8uncYKJYzJbXFWZUmqKCCdvCVUYPKRZu26k-PHMi3vWj-yaQ@mail.gmail.com>	<542AB58D.9080602@selasky.org>	<CAB8uncbtGf+SP5CqRvixMBFF0VKm+ZsBi0h7_nnQ9+eTgjXS2g@mail.gmail.com>	<542BA063.3060105@selasky.org>
 <CAB8uncburHy73G2sG1nqnUn+vZR8jWFOukawYsxxArq4ETGQfA@mail.gmail.com>
Message-ID: <542BAD89.60508@selasky.org>

On 10/01/14 09:24, Huang Wen Hui wrote:
> verbose dmesg with patch, hw.usb.xhci.debug=16 and hw.usb.xhci.use_polling=1
>
> http://sw.gddsn.org.cn/freebsd/hps-bios-message2.txt
> http://sw.gddsn.org.cn/freebsd/hps-uefi-message2.txt
>

Hi,

Can you join #bsdusb on EF-net?

BTW: Why are the time-stamps so different in the two logs above?

--HPS

From bugzilla-noreply at freebsd.org  Thu Oct  2 12:06:13 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 12:06:13 +0000
Subject: [Bug 194091] New: Add support for long range USB wireless adapter
 Alpha AWUS036NHRv2
Message-ID: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 194091
           Summary: Add support for long range USB wireless adapter Alpha
                    AWUS036NHRv2
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb at FreeBSD.org
          Reporter: olivier at cochard.me

Created attachment 147911
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147911&action=edit
patch for AWUS036NHR v2

Here is the patch (simply new USB ID added and man page update).

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Thu Oct  2 12:27:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 02 Oct 2014 12:27:55 +0000
Subject: [Bug 194091] Add support for long range USB wireless adapter Alpha
 AWUS036NHRv2
In-Reply-To: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194091-17-1tDKMBTtwU@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #1 from commit-hook at freebsd.org ---
A commit references this bug:

Author: hselasky
Date: Thu Oct  2 12:27:43 UTC 2014
New revision: 272410
URL: https://svnweb.freebsd.org/changeset/base/272410

Log:
  Add new USB ID.

  PR:        194091
  MFC after:    3 days

Changes:
  head/share/man/man4/urtwn.4
  head/sys/dev/usb/usbdevs
  head/sys/dev/usb/wlan/if_urtwn.c

-- 
You are receiving this mail because:
You are the assignee for the bug.

From huanghwh at gmail.com  Fri Oct  3 03:55:05 2014
From: huanghwh at gmail.com (Huang Wen Hui)
Date: Fri, 3 Oct 2014 11:55:02 +0800
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <CAB8uncb6ycJeYaMairr7XnhQBKNtYgYovH2vYNgB_xEGb8BGhw@mail.gmail.com>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>
 <CAB8uncYd24GkgK8Dsd51BAhoMjKFoAeS3AQ0a0=1mZjeprjHUw@mail.gmail.com>
 <541FBD6F.2080507@selasky.org>
 <CAB8uncb+HtjDXJG7gS1QGz8ayR+woaO-UWFbwTVXHrCXnQoa2A@mail.gmail.com>
 <541FDDF0.90502@selasky.org>
 <CAB8uncZaESbHiDJfYjybTg7mfhq0MG66+UqshxqDFVTej6rkeA@mail.gmail.com>
 <CAB8uncYrf=zP=ithL=dCci4opir4U0AWGCWM3JU38EscPdp3Og@mail.gmail.com>
 <542662BE.5050908@selasky.org>
 <CAB8uncYuMvc1hXxJib_bDs+AOrYhCfVkaV8O5VtgjFjJo_T2mA@mail.gmail.com>
 <542701FA.2000408@selasky.org> <5427029B.3060502@selasky.org>
 <CAB8uncajuWXGc6Lb3AmHC6qdnefXmYF4_8h4VPwzNaM595Dy+g@mail.gmail.com>
 <5427AC46.3040707@selasky.org>
 <CAB8uncYZpZ5+gAw5FmXTJ8CH5KBpDqaYHqB00b=FEQVXONd4-g@mail.gmail.com>
 <CAB8uncb6ycJeYaMairr7XnhQBKNtYgYovH2vYNgB_xEGb8BGhw@mail.gmail.com>
Message-ID: <CAB8uncZ=9Hi04YKX4VDX0zzOGQPhV61rurwKmHXdz2FouWw5wA@mail.gmail.com>

I found that how to connect EHCI controller, use "bless" command in MacOSX
with --legacy option:
1. open MacOSX terminal, mkdir /Volumes/EFI
2. mount -t msdos /dev/disk0s1 /Volumes/EFI
3. bless --setBoot --mount /Volumes/EFI --legacy
4. reboot MacOSX, press "option" key, you can feel firmware start a little
slow than without --legacy. I think firmware do some extra things:(
5. select both UEFI and BIOS boot FreeBSD, system can connect EHCI and XHCI
controller.
6. I think BootCamp assistant also add --legacy option.

Cheers,
Huang Wen Hui

2014-09-30 18:19 GMT+08:00 Huang Wen Hui <huanghwh at gmail.com>:

> Hi,
> I got the exactly same MBP 2013 11,3 from my colleague, also same time to
> buy it.
> USB driver works on this in UEFI mode. Both xhci and ehci found in this
> mac, and these
> dmesg only show in this mac:
>
> acpi_ec0: <Embedded Controller: GPE 0x17, ECDT> port 0x62,0x66 on acpi0
> ACPI Error: No handler for Region [CMS0] (0xfffff80008948e00) [SystemCMOS]
> (20130823/evregion-178)
> ACPI Error: Region SystemCMOS (ID=5) has no handler (20130823/exfldio-320)
> ACPI Error: Method parse/execution failed [\134RUSB] (Node
> 0xfffff8000895db80), AE_NOT_EXIST (20130823/psparse-553)
> ACPI Error: Method parse/execution failed [\134_SB_._INI] (Node
> 0xfffff8000895e000), AE_NOT_EXIST (20130823/psparse-553)
> acpi0: Power Button (fixed)
> ...
> xhci0: <Intel Lynx Point USB 3.0 controller> mem 0xc1e00000-0xc1e0ffff at
> device 20.0 on pci0
> xhci0: 32 byte context size.
> xhci0: Port routing mask set to 0xffffffff
> usbus0 on xhci0
> pci0: <simple comms> at device 22.0 (no driver attached)
> ehci0: <Intel Lynx Point USB 2.0 controller USB-B> mem
> 0xc1e19400-0xc1e197ff at device 26.0 on pci0
> usbus1: EHCI version 1.0
> usbus1 on ehci0
> ...
> ehci1: <Intel Lynx Point USB 2.0 controller USB-A> mem
> 0xc1e19000-0xc1e193ff at device 29.0 on pci0
> usbus2: EHCI version 1.0
> usbus2 on ehci1
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> ...
> usbus0: 5.0Gbps Super Speed USB v3.0
> usbus1: 480Mbps High Speed USB v2.0
> usbus2: 480Mbps High Speed USB v2.0
> ugen0.1: <0x8086> at usbus0
> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> ugen1.1: <Intel> at usbus1
> uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
> ugen2.1: <Intel> at usbus2
> uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
> ...
> Timecounter "TSC-low" frequency 1297021897 Hz quality 1000
> Root mount waiting for: usbus2 usbus1 usbus0
> uhub1: 2 ports with 2 removable, self powered
> uhub0: 21 ports with 21 removable, self powered
> uhub2: 2 ports with 2 removable, self powered
> Root mount waiting for: usbus2 usbus1 usbus0
> xhci0: Port routing mask set to 0x00000000
> usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored)
> ugen0.2: <Unknown> at usbus0 (disconnected)
> uhub_reattach_port: could not allocate new device
> ugen1.2: <vendor 0x8087> at usbus1
> uhub3: <vendor 0x8087 product 0x8008, class 9/0, rev 2.00/0.05, addr 2> on
> usbus1
> ugen2.2: <vendor 0x8087> at usbus2
> uhub4: <vendor 0x8087 product 0x8000, class 9/0, rev 2.00/0.05, addr 2> on
> usbus2
> uhub3: 6 ports with 6 removable, self powered
> Root mount waiting for: usbus2 usbus1 usbus0
> xhci0: Port routing mask set to 0x00000000
> usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored)
> ugen0.2: <Unknown> at usbus0 (disconnected)
> uhub_reattach_port: could not allocate new device
> uhub4: 8 ports with 8 removable, self powered
> ugen1.3: <Generic> at usbus1
> umass0: <Generic Mass Storage, class 0/0, rev 2.00/1.12, addr 3> on usbus1
> umass0:  SCSI over Bulk-Only; quirks = 0x4101
> umass0:1:0:-1: Attached to scbus1
> da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
> da0: <Generic Flash Disk 8.07> Removable Direct Access SCSI-4 device
> da0: Serial Number E0629276
> da0: 40.000MB/s transfers
> da0: 3870MB (7925760 512 byte sectors: 255H 63S/T 493C)
> da0: quirks=0x2<NO_6_BYTE>
> ugen1.4: <Apple Inc.> at usbus1
> uhub5: <Apple Inc. BRCM20702 Hub, class 9/0, rev 2.00/1.00, addr 4> on
> usbus1
> Root mount waiting for: usbus1
> uhub5: 3 ports with 0 removable, self powered
> ugen1.5: <vendor 0x05ac> at usbus1
> ukbd0: <vendor 0x05ac product 0x820a, class 0/0, rev 2.00/1.00, addr 5> on
> usbus1
> kbd1 at ukbd0
> Root mount waiting for: usbus1
> ugen1.6: <vendor 0x05ac> at usbus1
> ugen1.7: <Apple Inc.> at usbus1
> Root mount waiting for: usbus1
> ugen1.8: <Apple Inc.> at usbus1
> ukbd1: <Apple Internal Keyboard> on usbus1
> Root mount waiting for: usbus1
> kbd2 at ukbd1
>
> Full dmesg is http://sw.gddsn.org.cn/freebsd/uefi-ehci-dmesg.txt
>
>
>
>
> 2014-09-28 15:35 GMT+08:00 Huang Wen Hui <huanghwh at gmail.com>:
>
>> I found some similar problem of Linux:
>> https://bugzilla.kernel.org/show_bug.cgi?id=52591
>> https://lkml.org/lkml/2013/3/9/134
>>
>>
>> 2014-09-28 14:35 GMT+08:00 Hans Petter Selasky <hps at selasky.org>:
>>
>>> On 09/28/14 06:26, Huang Wen Hui wrote:
>>>
>>>> No lucky. dmesg aslo no change, I could not found "Skipped".
>>>>
>>>> Cheers,
>>>> Huang Wen Hui
>>>>
>>>
>>> Did you try searching if Linux users had such a problem already?
>>>
>>> --HPS
>>>
>>>
>>
>

From hps at selasky.org  Fri Oct  3 06:15:41 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Fri, 03 Oct 2014 08:15:30 +0200
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <CAB8uncZ=9Hi04YKX4VDX0zzOGQPhV61rurwKmHXdz2FouWw5wA@mail.gmail.com>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>	<CAB8uncYd24GkgK8Dsd51BAhoMjKFoAeS3AQ0a0=1mZjeprjHUw@mail.gmail.com>	<541FBD6F.2080507@selasky.org>	<CAB8uncb+HtjDXJG7gS1QGz8ayR+woaO-UWFbwTVXHrCXnQoa2A@mail.gmail.com>	<541FDDF0.90502@selasky.org>	<CAB8uncZaESbHiDJfYjybTg7mfhq0MG66+UqshxqDFVTej6rkeA@mail.gmail.com>	<CAB8uncYrf=zP=ithL=dCci4opir4U0AWGCWM3JU38EscPdp3Og@mail.gmail.com>	<542662BE.5050908@selasky.org>	<CAB8uncYuMvc1hXxJib_bDs+AOrYhCfVkaV8O5VtgjFjJo_T2mA@mail.gmail.com>	<542701FA.2000408@selasky.org>	<5427029B.3060502@selasky.org>	<CAB8uncajuWXGc6Lb3AmHC6qdnefXmYF4_8h4VPwzNaM595Dy+g@mail.gmail.com>	<5427AC46.3040707@selasky.org>	<CAB8uncYZpZ5+gAw5FmXTJ8CH5KBpDqaYHqB00b=FEQVXONd4-g@mail.gmail.com>	<CAB8uncb6ycJeYaMairr7XnhQBKNtYgYovH2vYNgB_xEGb8BGhw@mail.gmail.com>
 <CAB8uncZ=9Hi04YKX4VDX0zzOGQPhV61rurwKmHXdz2FouWw5wA@mail.gmail.com>
Message-ID: <542E3F02.4050401@selasky.org>

On 10/03/14 05:55, Huang Wen Hui wrote:
> I found that how to connect EHCI controller, use "bless" command in MacOSX
> with --legacy option:
> 1. open MacOSX terminal, mkdir /Volumes/EFI
> 2. mount -t msdos /dev/disk0s1 /Volumes/EFI
> 3. bless --setBoot --mount /Volumes/EFI --legacy
> 4. reboot MacOSX, press "option" key, you can feel firmware start a little
> slow than without --legacy. I think firmware do some extra things:(
> 5. select both UEFI and BIOS boot FreeBSD, system can connect EHCI and XHCI
> controller.
> 6. I think BootCamp assistant also add --legacy option.
>
> Cheers,
> Huang Wen Hui

Hi,

Sounds good!

Thanks for figuring this out. At least I found one or two minors in the 
XHCI driver while debugging this :-)

--HPS


From huanghwh at gmail.com  Fri Oct  3 06:44:10 2014
From: huanghwh at gmail.com (=?GB2312?Q? =BB=C6=CE=C4=BB=D4=40Gmail ?=)
Date: Fri, 3 Oct 2014 14:43:26 +0800
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <542E3F02.4050401@selasky.org>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>
 <CAB8uncYd24GkgK8Dsd51BAhoMjKFoAeS3AQ0a0=1mZjeprjHUw@mail.gmail.com>
 <541FBD6F.2080507@selasky.org>
 <CAB8uncb+HtjDXJG7gS1QGz8ayR+woaO-UWFbwTVXHrCXnQoa2A@mail.gmail.com>
 <541FDDF0.90502@selasky.org>
 <CAB8uncZaESbHiDJfYjybTg7mfhq0MG66+UqshxqDFVTej6rkeA@mail.gmail.com>
 <CAB8uncYrf=zP=ithL=dCci4opir4U0AWGCWM3JU38EscPdp3Og@mail.gmail.com>
 <542662BE.5050908@selasky.org>
 <CAB8uncYuMvc1hXxJib_bDs+AOrYhCfVkaV8O5VtgjFjJo_T2mA@mail.gmail.com>
 <542701FA.2000408@selasky.org> <5427029B.3060502@selasky.org>
 <CAB8uncajuWXGc6Lb3AmHC6qdnefXmYF4_8h4VPwzNaM595Dy+g@mail.gmail.com>
 <5427AC46.3040707@selasky.org>
 <CAB8uncYZpZ5+gAw5FmXTJ8CH5KBpDqaYHqB00b=FEQVXONd4-g@mail.gmail.com>
 <CAB8uncb6ycJeYaMairr7XnhQBKNtYgYovH2vYNgB_xEGb8BGhw@mail.gmail.com>
 <CAB8uncZ=9Hi04YKX4VDX0zzOGQPhV61rurwKmHXdz2FouWw5wA@mail.gmail.com>
 <542E3F02.4050401@selasky.org>
Message-ID: <141592A3-A4CD-48F6-B26D-35BF10436012@gmail.com>

But xhci should works under freebsd,like Linux without this trick.
If you want to debug this further, ping me , I will be free after 2 hours;)

Huang Wen Hui

> ? 2014?10?3??14:15?Hans Petter Selasky <hps at selasky.org> ???
> 
>> On 10/03/14 05:55, Huang Wen Hui wrote:
>> I found that how to connect EHCI controller, use "bless" command in MacOSX
>> with --legacy option:
>> 1. open MacOSX terminal, mkdir /Volumes/EFI
>> 2. mount -t msdos /dev/disk0s1 /Volumes/EFI
>> 3. bless --setBoot --mount /Volumes/EFI --legacy
>> 4. reboot MacOSX, press "option" key, you can feel firmware start a little
>> slow than without --legacy. I think firmware do some extra things:(
>> 5. select both UEFI and BIOS boot FreeBSD, system can connect EHCI and XHCI
>> controller.
>> 6. I think BootCamp assistant also add --legacy option.
>> 
>> Cheers,
>> Huang Wen Hui
> 
> Hi,
> 
> Sounds good!
> 
> Thanks for figuring this out. At least I found one or two minors in the XHCI driver while debugging this :-)
> 
> --HPS
> 

From doconnor at gsoft.com.au  Fri Oct  3 11:38:47 2014
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri, 3 Oct 2014 20:49:48 +0930
Subject: Panic in usb_unref_device
Message-ID: <8B31CE4F-F310-49E7-8316-22D6170BF6C6@gsoft.com.au>

Hi,
I have a custom USB device based on the Cypress FX2 and we are finding that with some older kernels it hangs - this was fixed in https://svnweb.freebsd.org/base?view=revision&revision=267240 but now it panics with?

#7  0xffffffff80745a07 in usb_unref_device (cpd=0xfffffe0004b30680, crd=0xffffff812b6af860) at /usr/src/sys/dev/usb/usb_dev.c:348
#8  0xffffffff80748cbd in usb_ioctl (dev=<value optimized out>, cmd=3222040644, addr=0xfffffe0026380000 "\002", fflag=<value optimized out>, td=0xffffffff81819850)
   at /usr/src/sys/dev/usb/usb_dev.c:1127
#9  0xffffffff807d05cb in devfs_ioctl_f (fp=0xfffffe0061d59190, com=3222040644, data=<value optimized out>, cred=<value optimized out>, td=0xfffffe0004e37920)
   at /usr/src/sys/fs/devfs/devfs_vnops.c:758
#10 0xffffffff80938456 in kern_ioctl (td=0xfffffe0004e37920, fd=3, com=3222040644, data=0xfffffe0026380000 "\002") at file.h:311
#11 0xffffffff8093869d in sys_ioctl (td=0xfffffe0004e37920, uap=0xffffff812b6afa70) at /usr/src/sys/kern/sys_generic.c:696

And crd->rxfifo is NULL.

I haven?t looked very hard at this yet, but it is quite easy to reproduce.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


From hps at selasky.org  Fri Oct  3 11:49:02 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Fri, 03 Oct 2014 13:48:55 +0200
Subject: Panic in usb_unref_device
In-Reply-To: <8B31CE4F-F310-49E7-8316-22D6170BF6C6@gsoft.com.au>
References: <8B31CE4F-F310-49E7-8316-22D6170BF6C6@gsoft.com.au>
Message-ID: <542E8D27.2060505@selasky.org>

On 10/03/14 13:19, Daniel O'Connor wrote:
> Hi,
> I have a custom USB device based on the Cypress FX2 and we are finding that with some older kernels it hangs - this was fixed in https://svnweb.freebsd.org/base?view=revision&revision=267240 but now it panics with?
>

Hi,

There's a minor bug there. Can you test the attached patch?

--HPS


From hps at selasky.org  Fri Oct  3 16:10:52 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Fri, 03 Oct 2014 18:10:37 +0200
Subject: Panic in usb_unref_device
In-Reply-To: <542E8D27.2060505@selasky.org>
References: <8B31CE4F-F310-49E7-8316-22D6170BF6C6@gsoft.com.au>
 <542E8D27.2060505@selasky.org>
Message-ID: <542ECA7D.8020207@selasky.org>

On 10/03/14 13:48, Hans Petter Selasky wrote:
> On 10/03/14 13:19, Daniel O'Connor wrote:
>> Hi,
>> I have a custom USB device based on the Cypress FX2 and we are finding
>> that with some older kernels it hangs - this was fixed in
>> https://svnweb.freebsd.org/base?view=revision&revision=267240 but now
>> it panics with?
>>
>

Hi,

This commit should fix it:

https://svnweb.freebsd.org/changeset/base/272480

If not, let me know.

Thank you!

--HPS


From uqs at FreeBSD.org  Sat Oct  4 13:53:19 2014
From: uqs at FreeBSD.org (=?UTF-8?Q?Ulrich_Sp=C3=B6rlein?=)
Date: Sat, 4 Oct 2014 15:53:16 +0200
Subject: CEC device not attaching to xHCI port
In-Reply-To: <20140929174904.GA15642@coyote.spoerlein.net>
References: <20140929174904.GA15642@coyote.spoerlein.net>
Message-ID: <CAJ9axoQ=+ODvNrr_D8PiBOwNFrn_u3SSm7NueXPoP9hmsbjK1g@mail.gmail.com>

2014-09-29 19:49 GMT+02:00 Ulrich Sp?rlein <uqs at freebsd.org>:
> Hi,
>
> I got a CEC adapter using libCEC to bridge the gap between my XBMC and
> TV. The device works fine *if* I plug it into the front ports (which is
> a bit ugly, so I was wondering why this is not working on the other USB
> hub).
>
> Non-working:
> ugen0.2: <Unknown> at usbus0 (disconnected)
> root at coyote:~# usbconfig -u 0 -a 1
> ugen0.1: <XHCI root HUB 0x8086> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
>
> Working:
> ugen1.4: <Pulse-Eight> at usbus1
> ums0: <Pulse-Eight USB-CEC Adapter, class 0/0, rev 1.10/10.00, addr 4> on usbus1
> ums0: 3 buttons and [XY] coordinates ID=0
> umodem0: <Pulse-Eight USB-CEC Adapter, class 0/0, rev 1.10/10.00, addr 4> on usbus1
> umodem0: data interface 1, has CM over data, has break
> root at coyote:~# usbconfig -u 1 -a 4
> ugen1.4: <USB-CEC Adapter Pulse-Eight> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (10mA)
>
> The hubs:
> root at coyote:~# pciconf -l -v xhci0
> xhci0 at pci0:0:20:0:      class=0x0c0330 card=0x72708086 chip=0x1e318086 rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '7 Series/C210 Series Chipset Family USB xHCI Host Controller'
>     class      = serial bus
>     subclass   = USB
> root at coyote:~# pciconf -l -v ehci0
> ehci0 at pci0:0:26:0:      class=0x0c0320 card=0x72708086 chip=0x1e2d8086 rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '7 Series/C210 Series Chipset Family USB Enhanced Host Controller'
>     class      = serial bus
>     subclass   = USB
>
> This is on 10.1-BETA1 and I found this post and workaround, which seem to be relevant:
> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2013-02/msg00701.html
>
> But I haven't rebooted yet with hw.usb.xhci.xhci_port_route -1
>
> Any more info you'd require on this? Should I file a PR to track this?
>
> Cheers,
> Uli

Sorry for the delay, I'm not subscribed to freebsd-usb, please keep me
CC'ed on replies.

The flag hw.usb.xhci.xhci_port_route does nothing for me, as it
doesn't even exist yet. I had to recompile my kernel to get USB_DEBUG
and there's quite a bunch of repetitive output when plugging in the
device into the non-working hub. Here we go:

Oct  4 15:41:12 coyote kernel: usb_needs_explore:
Oct  4 15:41:12 coyote kernel: usb_bus_powerd: bus=0xfffffe0000b54cd8
Oct  4 15:41:12 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:12 coyote kernel: uhub_explore: udev=0xfffff800047e6000 addr=1
Oct  4 15:41:12 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:12 coyote kernel: uhub_explore: udev=0xfffff800048b0000 addr=2
Oct  4 15:41:12 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:12 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:12 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:12 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:12 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:12 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:13 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:13 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:13 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:13 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:13 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:13 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:14 coyote kernel: usb_needs_explore:
Oct  4 15:41:14 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ab4528
Oct  4 15:41:14 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:14 coyote kernel: uhub_explore: udev=0xfffff800047e4000 addr=1
Oct  4 15:41:14 coyote kernel: usb_needs_explore:
Oct  4 15:41:14 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:14 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ad0cd8
Oct  4 15:41:14 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:14 coyote kernel: uhub_explore: udev=0xfffff800047e5000 addr=1
Oct  4 15:41:14 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_explore: udev=0xfffff800048a9000 addr=2
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: usb_needs_explore:
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: usb_bus_powerd: bus=0xfffffe0000b54cd8
Oct  4 15:41:16 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:16 coyote kernel: uhub_explore: udev=0xfffff800047e6000 addr=1
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:16 coyote kernel: uhub_explore: udev=0xfffff800048b0000 addr=2
Oct  4 15:41:16 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:16 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:16 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:17 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:18 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:18 coyote kernel: usb_needs_explore:
Oct  4 15:41:18 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ab4528
Oct  4 15:41:18 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:18 coyote kernel: uhub_explore: udev=0xfffff800047e4000 addr=1
Oct  4 15:41:18 coyote kernel: usb_needs_explore:
Oct  4 15:41:18 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:18 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ad0cd8
Oct  4 15:41:18 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:18 coyote kernel: uhub_explore: udev=0xfffff800047e5000 addr=1
Oct  4 15:41:18 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_explore: udev=0xfffff800048a9000 addr=2
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: usb_needs_explore:
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: usb_bus_powerd: bus=0xfffffe0000b54cd8
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:20 coyote kernel: uhub_explore: udev=0xfffff800047e6000 addr=1
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:20 coyote kernel: uhub_explore: udev=0xfffff800048b0000 addr=2
Oct  4 15:41:20 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:20 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:20 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:21 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:22 coyote kernel: usb_needs_explore:
Oct  4 15:41:22 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ab4528
Oct  4 15:41:22 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:22 coyote kernel: uhub_explore: udev=0xfffff800047e4000 addr=1
Oct  4 15:41:22 coyote kernel: usb_needs_explore:
Oct  4 15:41:22 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:22 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ad0cd8
Oct  4 15:41:22 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:22 coyote kernel: uhub_explore: udev=0xfffff800047e5000 addr=1
Oct  4 15:41:22 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:22 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_explore: udev=0xfffff800048a9000 addr=2
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:23 coyote kernel: usb_needs_explore:
Oct  4 15:41:23 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:24 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x07a0, wPortChange=0x0020, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:24 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:24 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ab4528
Oct  4 15:41:24 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:25 coyote kernel: usb_needs_explore:
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_explore: udev=0xfffff800047e4000 addr=1
Oct  4 15:41:25 coyote kernel: usb_bus_powerd: bus=0xfffffe0000b54cd8
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_explore: udev=0xfffff800047e6000 addr=1
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x07a0, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_explore: udev=0xfffff800048b0000 addr=2
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x01e1, wPortChange=0x0001, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:25 coyote kernel: uhub_reattach_port: reattaching port 4
Oct  4 15:41:25 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x01e1, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_reattach_port: Port 4 is in Host Mode
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:25 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: usb_needs_explore:
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: usb_needs_explore:
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:26 coyote kernel: usb_needs_explore:
Oct  4 15:41:26 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:26 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ad0cd8
Oct  4 15:41:27 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:27 coyote kernel: uhub_explore: udev=0xfffff800047e5000 addr=1
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:27 coyote kernel: uhub_explore: udev=0xfffff800048a9000 addr=2
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:27 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:28 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:28 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:28 coyote kernel: usb_needs_explore:
Oct  4 15:41:28 coyote kernel: usb_bus_powerd: bus=0xfffffe0000b54cd8
Oct  4 15:41:28 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:28 coyote kernel: uhub_explore: udev=0xfffff800047e6000 addr=1
Oct  4 15:41:28 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:28 coyote kernel: uhub_explore: udev=0xfffff800048b0000 addr=2
Oct  4 15:41:28 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:28 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:28 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:28 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:29 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:30 coyote kernel: usbd_setup_device_desc: getting device
descriptor at addr 3 failed, USB_ERR_TIMEOUT
Oct  4 15:41:30 coyote kernel: usb_needs_explore:
Oct  4 15:41:30 coyote last message repeated 2 times
Oct  4 15:41:30 coyote kernel: usb_bus_powerd: bus=0xfffffe0000ad0cd8
Oct  4 15:41:30 coyote kernel: uhub_explore: udev=0xfffff800047e5000 addr=1
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_explore: udev=0xfffff800048a9000 addr=2
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: usbd_req_re_enumerate: addr=3, set
address failed! (USB_ERR_TIMEOUT, ignored)
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:31 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:32 coyote kernel: usbd_setup_device_desc: getting device
descriptor at addr 3 failed, USB_ERR_TIMEOUT
Oct  4 15:41:32 coyote kernel: usb_needs_explore:
Oct  4 15:41:32 coyote kernel: usb_bus_powerd: bus=0xfffffe0000b54cd8
Oct  4 15:41:32 coyote kernel: usb_bus_powerd: Recomputing power masks
Oct  4 15:41:32 coyote kernel: uhub_explore: udev=0xfffff800047e6000 addr=1
Oct  4 15:41:32 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:32 coyote kernel: uhub_explore: udev=0xfffff800048b0000 addr=2
Oct  4 15:41:32 coyote kernel: usbd_transfer_power_ref: Adding type 0
to power state
Oct  4 15:41:32 coyote kernel: usbd_transfer_power_ref: needs power
Oct  4 15:41:32 coyote kernel: uhub_read_port_status: port 1,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:32 coyote kernel: uhub_read_port_status: port 2,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:33 coyote kernel: usb_needs_explore:
Oct  4 15:41:33 coyote kernel: uhub_read_port_status: port 3,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:33 coyote kernel: uhub_read_port_status: port 4,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:33 coyote kernel: uhub_read_port_status: port 5,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:33 coyote kernel: uhub_read_port_status: port 6,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:33 coyote kernel: uhub_read_port_status: port 7,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:33 coyote kernel: uhub_read_port_status: port 8,
wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION
Oct  4 15:41:34 coyote kernel: usbd_req_re_enumerate: addr=3, set
address failed! (USB_ERR_TIMEOUT, ignored)
Oct  4 15:41:35 coyote kernel: usbd_setup_device_desc: getting device
descriptor at addr 3 failed, USB_ERR_TIMEOUT
Oct  4 15:41:36 coyote kernel: usbd_req_re_enumerate: addr=3, set
address failed! (USB_ERR_TIMEOUT, ignored)
Oct  4 15:41:36 coyote kernel: usbd_setup_device_desc: getting device
descriptor at addr 3 failed, USB_ERR_TIMEOUT
Oct  4 15:41:38 coyote kernel: usbd_req_re_enumerate: addr=3, set
address failed! (USB_ERR_TIMEOUT, ignored)
Oct  4 15:41:39 coyote kernel: ugen0.2: <Unknown> at usbus0 (disconnected)
Oct  4 15:41:39 coyote kernel: uhub_reattach_port: could not allocate new device

From hps at selasky.org  Sun Oct  5 00:11:34 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Sun, 05 Oct 2014 02:11:20 +0200
Subject: CEC device not attaching to xHCI port
In-Reply-To: <CAJ9axoQ=+ODvNrr_D8PiBOwNFrn_u3SSm7NueXPoP9hmsbjK1g@mail.gmail.com>
References: <20140929174904.GA15642@coyote.spoerlein.net>
 <CAJ9axoQ=+ODvNrr_D8PiBOwNFrn_u3SSm7NueXPoP9hmsbjK1g@mail.gmail.com>
Message-ID: <54308CA8.5020304@selasky.org>

On 10/04/14 15:53, Ulrich Sp?rlein wrote:
> 2014-09-29 19:49 GMT+02:00 Ulrich Sp?rlein <uqs at freebsd.org>:
>> Hi,
>>
>> I got a CEC adapter using libCEC to bridge the gap between my XBMC and
>> TV. The device works fine *if* I plug it into the front ports (which is
>> a bit ugly, so I was wondering why this is not working on the other USB
>> hub).
>>

Hi,

How many ports have your XHCI got? See dmesg.

--HPS

From uqs at freebsd.org  Sun Oct  5 14:05:25 2014
From: uqs at freebsd.org (=?UTF-8?Q?Ulrich_Sp=C3=B6rlein?=)
Date: Sun, 5 Oct 2014 16:05:21 +0200
Subject: CEC device not attaching to xHCI port
In-Reply-To: <54308CA8.5020304@selasky.org>
References: <20140929174904.GA15642@coyote.spoerlein.net>
 <CAJ9axoQ=+ODvNrr_D8PiBOwNFrn_u3SSm7NueXPoP9hmsbjK1g@mail.gmail.com>
 <54308CA8.5020304@selasky.org>
Message-ID: <CAJ9axoTwk55o+9yTKhtipwLuBeEmPoojbQ7-hmMQ_mYbRDzjkg@mail.gmail.com>

2014-10-05 2:11 GMT+02:00 Hans Petter Selasky <hps at selasky.org>:
> On 10/04/14 15:53, Ulrich Sp?rlein wrote:
>>
>> 2014-09-29 19:49 GMT+02:00 Ulrich Sp?rlein <uqs at freebsd.org>:
>>>
>>> Hi,
>>>
>>> I got a CEC adapter using libCEC to bridge the gap between my XBMC and
>>> TV. The device works fine *if* I plug it into the front ports (which is
>>> a bit ugly, so I was wondering why this is not working on the other USB
>>> hub).
>>>
>
> Hi,
>
> How many ports have your XHCI got? See dmesg.
>
> --HPS

Hey

physically I count 4 in the back and 4 in the front (which is an
expansion plate). Two ports in the back will happily serve umass(4)
devices (not shown in the dmesg below, I only connect them every once
in a while).

root at coyote:~# dmesg | egrep -i "xhci|usbus" | egrep -v "Root mount"

xhci0: <Intel Panther Point USB 3.0 controller> mem
0xe0f20000-0xe0f2ffff irq 21 at device 20.0 on pci0
xhci0: 32 byte context size.
xhci0: Port routing mask set to 0xffffffff
usbus0 on xhci0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
ugen0.1: <0x8086> at usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ugen1.1: <Intel> at usbus1
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
usbus2: 480Mbps High Speed USB v2.0
ugen2.1: <Intel> at usbus2
uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ugen1.2: <vendor 0x8087> at usbus1
uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr
2> on usbus1
ugen2.2: <vendor 0x8087> at usbus2
uhub4: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr
2> on usbus2
ugen1.3: <vendor 0x13d3> at usbus1
ugen0.2: <Unknown> at usbus0 (disconnected)
ubt0: <vendor 0x13d3 product 0x3331, class 224/1, rev 2.00/52.76, addr
3> on usbus1
ugen0.2: <Unknown> at usbus0 (disconnected)
ugen0.2: <Unknown> at usbus0 (disconnected)
ugen1.4: <Pulse-Eight> at usbus1
ums0: <Pulse-Eight USB-CEC Adapter, class 0/0, rev 1.10/10.00, addr 4> on usbus1
umodem0: <Pulse-Eight USB-CEC Adapter, class 0/0, rev 1.10/10.00, addr
4> on usbus1

Or do I need to boot with USB debug enabled?

From hps at selasky.org  Sun Oct  5 20:47:24 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Sun, 05 Oct 2014 22:47:17 +0200
Subject: CEC device not attaching to xHCI port
In-Reply-To: <CAJ9axoTwk55o+9yTKhtipwLuBeEmPoojbQ7-hmMQ_mYbRDzjkg@mail.gmail.com>
References: <20140929174904.GA15642@coyote.spoerlein.net>	<CAJ9axoQ=+ODvNrr_D8PiBOwNFrn_u3SSm7NueXPoP9hmsbjK1g@mail.gmail.com>	<54308CA8.5020304@selasky.org>
 <CAJ9axoTwk55o+9yTKhtipwLuBeEmPoojbQ7-hmMQ_mYbRDzjkg@mail.gmail.com>
Message-ID: <5431AE55.4030006@selasky.org>

On 10/05/14 16:05, Ulrich Sp?rlein wrote:
> 2014-10-05 2:11 GMT+02:00 Hans Petter Selasky <hps at selasky.org>:
>> On 10/04/14 15:53, Ulrich Sp?rlein wrote:
>>>
>>> 2014-09-29 19:49 GMT+02:00 Ulrich Sp?rlein <uqs at freebsd.org>:
>>>>
>>>> Hi,
>>>>
>>>> I got a CEC adapter using libCEC to bridge the gap between my XBMC and
>>>> TV. The device works fine *if* I plug it into the front ports (which is
>>>> a bit ugly, so I was wondering why this is not working on the other USB
>>>> hub).
>>>>
>>
>> Hi,
>>
>> How many ports have your XHCI got? See dmesg.
>>
>> --HPS
>
> Hey
>
> physically I count 4 in the back and 4 in the front (which is an
> expansion plate). Two ports in the back will happily serve umass(4)
> devices (not shown in the dmesg below, I only connect them every once
> in a while).
>

Maybe you need this patch:

https://svnweb.freebsd.org/changeset/base/272479

--HPS


From bugzilla-noreply at freebsd.org  Mon Oct  6 06:04:17 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 06 Oct 2014 06:04:17 +0000
Subject: [Bug 194091] Add support for long range USB wireless adapter Alpha
 AWUS036NHRv2
In-Reply-To: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194091-17-WnwnO6dSMk@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #2 from commit-hook at freebsd.org ---
A commit references this bug:

Author: hselasky
Date: Mon Oct  6 06:03:26 UTC 2014
New revision: 272590
URL: https://svnweb.freebsd.org/changeset/base/272590

Log:
  MFC r272410:
  Add new USB ID.

  PR:        194091

Changes:
_U  stable/10/
  stable/10/share/man/man4/urtwn.4
  stable/10/sys/dev/usb/usbdevs
  stable/10/sys/dev/usb/wlan/if_urtwn.c

-- 
You are receiving this mail because:
You are the assignee for the bug.

From lev at FreeBSD.org  Mon Oct  6 10:54:21 2014
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Mon, 06 Oct 2014 14:54:06 +0400
Subject: Is here maximum size of buffer for libusb_fill_bulk_transfer() call?
Message-ID: <543274CE.5080308@FreeBSD.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


 Is here practical buffer size limit? I mean, maybe, standard limits
transfer size by 64K or something like this?

- -- 
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUMnTNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTM0QAIY/23sBmZVmzfckVXjrlWvI
lCOpv8aVgrImaVzG5hcVJdop8js2zXw0cHh5iMTo+1DPN2D7GU68C02ujVbMPPRh
ylPzJAd74RRnu6NZspqRY+eCW6VNUKCO9hqFYv8h7nFL+tpt+U4ffWa+CWK+N3Js
ZqfReSvPoJVr3ocZnWCEzWo3g9jVO2q46v1WiKYLKFJYFOHoq61Huszj0fuZV/Sh
mOl/M+5YS+/coHxO8wNV1q50jGldg2iFyEYH+Bw5n/l342R23KqVyilnVZ7zjaxF
2GpOoXBXl+IzXiLzeJM4ZLmJ8f4P5kLQNR7xbN0j341NoxmbUGEkij/o5kcUMhQ+
8D2rhJ6UFsMzLkneucqUoqi0GqKxkbDiq4Ank6Qe/KYeTeQtCEXRtgoCiGcJzyFA
Xw7Xj4ix8aVg/OlQpHnykRE84d0fcWLVDgWDfF5xQiC7GK8QKsfVwxFnD867bLlL
krihZW5/hc2siNwVQ5iBJBN9aOVCQBvR2l6gmULQUm2j6yPDdrSTEra73xRqmMcy
qtPPGfX9s79LT0TnH7/n9aOfj8wiPsuyCbdCqfMEm3quX/NSszKKBQ2cguJwFwqk
4xbezsQ4X1JpQDwSVWKTDSBke988RBOyDVtqFCHR1RgZYGSoFQRDvpUsWCfv1mOu
TQDqAJTcD74N4zqOF631
=0Taj
-----END PGP SIGNATURE-----

From hps at selasky.org  Mon Oct  6 11:03:17 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Mon, 06 Oct 2014 13:03:11 +0200
Subject: Is here maximum size of buffer for libusb_fill_bulk_transfer()
 call?
In-Reply-To: <543274CE.5080308@FreeBSD.org>
References: <543274CE.5080308@FreeBSD.org>
Message-ID: <543276EF.5080809@selasky.org>

On 10/06/14 12:54, Lev Serebryakov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>   Is here practical buffer size limit? I mean, maybe, standard limits
> transfer size by 64K or something like this?
>

Hi,

If the transfer is too big, libusb in FreeBSD loops using an internal 
buffer, unlike Linux. You should be able to setup any positive length 
which fits into an integer of type "int" or "uint32_t".

--HPS


From lev at FreeBSD.org  Mon Oct  6 11:06:59 2014
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Mon, 06 Oct 2014 15:06:55 +0400
Subject: Is here maximum size of buffer for libusb_fill_bulk_transfer()
 call?
In-Reply-To: <543276EF.5080809@selasky.org>
References: <543274CE.5080308@FreeBSD.org> <543276EF.5080809@selasky.org>
Message-ID: <543277CF.9050407@FreeBSD.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06.10.2014 15:03, Hans Petter Selasky wrote:

>> Is here practical buffer size limit? I mean, maybe, standard
>> limits transfer size by 64K or something like this?
> 
> If the transfer is too big, libusb in FreeBSD loops using an
> internal buffer, unlike Linux. You should be able to setup any
> positive length which fits into an integer of type "int" or
> "uint32_t".
 My question is more about cross-platform behavior, as I try to write
cross-platform project.

- -- 
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQJ8BAEBCgBmBQJUMnfPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePh5sP/0ZlPkcJ5W00Y0cr5iuDtMTd
bL5YkFOVFgJWobCqXxKE1xlZKfWNPgcQxovHhdNEjsADXXVj7ez56uSLMIfP+sKt
LR/n3fSd9gbi3b6Lr54n2RI/wwLNkIOi43M5yx+Im4bCTdGpeYcfpMpZ7eie/Whw
o8t5sH3ULXUnMRSOIi/F/6H382EmLUNSV9qbXTq0nq9bIJaMewV5EJISgODx+2nt
BFaAB803t0otr5Uwwe5/BEknb9wu1X4A3HFwV1r+5ofz3JwDRiNZqAXj8XT8EIv3
0rMCn/VvFfqpIpBSlQwowgiuqj/5fJFOZ18g0Q3yVy+6XWVSPOUMBBTvjcODZMyN
S1MPonvbZBPOWvTUqeFqpFxdj6CQ+hdi1uwPrqr9SLYrNLKUSjnbmt89ysJUYWeH
KVENtGiES3Uf5TPdN20C8Ok+yo1LUNiE9y0BFRkAYWez9XfGFMuOecHhmYY3Uju4
/L2FNtpWHjDfXWIwlUTWT4+d5saEmKE0seHORd6HjD5bdOfmAXDrNexJ4LBgltyZ
0oMfmHOfDMnehXaFxGW1iYxsrJx29CvWfXHT8U3QK/psuJ/aEuJxf+i/PgrIY45v
ZoywMLkM/pLAuRAUIwLWALtANDBlczJGWqTyYHs2GspVPmDKo68FmIzRVDKf0idq
k/V9+jqWPCDT8k76xwma
=xP8f
-----END PGP SIGNATURE-----

From hps at selasky.org  Mon Oct  6 11:11:50 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Mon, 06 Oct 2014 13:11:45 +0200
Subject: Is here maximum size of buffer for libusb_fill_bulk_transfer()
 call?
In-Reply-To: <543277CF.9050407@FreeBSD.org>
References: <543274CE.5080308@FreeBSD.org> <543276EF.5080809@selasky.org>
 <543277CF.9050407@FreeBSD.org>
Message-ID: <543278F1.9070607@selasky.org>

On 10/06/14 13:06, Lev Serebryakov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 06.10.2014 15:03, Hans Petter Selasky wrote:
>
>>> Is here practical buffer size limit? I mean, maybe, standard
>>> limits transfer size by 64K or something like this?
>>
>> If the transfer is too big, libusb in FreeBSD loops using an
>> internal buffer, unlike Linux. You should be able to setup any
>> positive length which fits into an integer of type "int" or
>> "uint32_t".
>   My question is more about cross-platform behavior, as I try to write
> cross-platform project.
>

Hi,

In Linux you should not transmit more than 16Kbytes at a time for BULK 
at HighSpeed, from what I know. Might have been fixed recently though.

--HPS

From jhs at berklix.com  Mon Oct  6 19:56:44 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Mon, 06 Oct 2014 21:56:08 +0200
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob Lell
Message-ID: <201410061956.s96Ju8S3089675@fire.js.berklix.net>

Hi freebsd-usb at freebsd.org, 		(I suggest replies to usb@)
cc: freebsd-security at freebsd.org	FYI

Ref. article on BadUSB pan OS (non FreeBSD specific) security loophole
	http://www.bbc.com/news/technology-29475566
Dated  6 October 2014 Last updated at 15:29 GMT 

I found https://github.com/search?utf8=%E2%9C%93&q=BadUSB

Then viewed https://www.youtube.com/watch?v=nuruzFqMgIw
	( Which BTW plays nicely inc. sound on FreeBSD-9.2-RELEASE
	+ firefox without any flash installed (certainly no
	ports/graphics/gnash)

A fascinating video by Lecturers Karsten Nohl & Jacob Lell at Black Hat 
USA 2014, Run time 44:30 ) 
  (PS for non native English spekers on this global list, dont worry if 
  you find Jacob's accent hard, Karsten resumes for last 3rd, listen on :-)

It seems USB controllers (8041 or so based) can first masquerade
one device, then pause & masquerade another device type.  This is
an OS independent security list. Lecturers includes both demo of
an MS to Linux contamination, & consideration of other scenarios.
A predominant USB controller manufacturer in Taipei was not happy.

The lecturers didn't discuss MS or Linux or Android smart phone
protection schemes (except to allude to the danger of someone saying
"Can I plug in my smart phone to your PC to charge it ?".

It can't be ignored as a smart phone exploit: the demo wasn't with a
smart phone but a `dumb' stick. 

One can't get some protection by checking for sernum connecting, as devd shows:
- my USB to PS2 adapter (vendor=0x04b4 product=0x8081) emits sernum=""
- my real USB "Havit" keyboard (vendor=0x1241 product=0x1203) emits sernum=""

For FreeBSD,
  I guess for serious security, every new device that is connected
  & recognised by /sbin/devd should in future be personaly authorised
  by a human !  One can no longer trust what reports itself to be
  eg a keyboard to actually Be a keyboard, etc.

  /usr/src/etc/devd/*.conf & my own .conf do Not meet that awkward
  security requirement... yet. I guess we'll need a couple of hooks
  that support Yes/No, one from cli & one for within X11.

There's no security warning section in
	http://en.wikipedia.org/wiki/Flash_memory

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
		ShellShock - http://www.berklix.com/~jhs/bash/

From oliver.pntr at gmail.com  Mon Oct  6 20:01:21 2014
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Mon, 6 Oct 2014 22:01:19 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: <201410061956.s96Ju8S3089675@fire.js.berklix.net>
References: <201410061956.s96Ju8S3089675@fire.js.berklix.net>
Message-ID: <CAPjTQNGk4XDgeJcu=-LKVV9eajuNG+Vxiru_6dGomrEG3eCy3Q@mail.gmail.com>

fwd to HardenedBSD Developers

On 10/6/14, Julian H. Stacey <jhs at berklix.com> wrote:
> Hi freebsd-usb at freebsd.org, 		(I suggest replies to usb@)
> cc: freebsd-security at freebsd.org	FYI
>
> Ref. article on BadUSB pan OS (non FreeBSD specific) security loophole
> 	http://www.bbc.com/news/technology-29475566
> Dated  6 October 2014 Last updated at 15:29 GMT
>
> I found https://github.com/search?utf8=%E2%9C%93&q=BadUSB
>
> Then viewed https://www.youtube.com/watch?v=nuruzFqMgIw
> 	( Which BTW plays nicely inc. sound on FreeBSD-9.2-RELEASE
> 	+ firefox without any flash installed (certainly no
> 	ports/graphics/gnash)
>
> A fascinating video by Lecturers Karsten Nohl & Jacob Lell at Black Hat
> USA 2014, Run time 44:30 )
>   (PS for non native English spekers on this global list, dont worry if
>   you find Jacob's accent hard, Karsten resumes for last 3rd, listen on :-)
>
> It seems USB controllers (8041 or so based) can first masquerade
> one device, then pause & masquerade another device type.  This is
> an OS independent security list. Lecturers includes both demo of
> an MS to Linux contamination, & consideration of other scenarios.
> A predominant USB controller manufacturer in Taipei was not happy.
>
> The lecturers didn't discuss MS or Linux or Android smart phone
> protection schemes (except to allude to the danger of someone saying
> "Can I plug in my smart phone to your PC to charge it ?".
>
> It can't be ignored as a smart phone exploit: the demo wasn't with a
> smart phone but a `dumb' stick.
>
> One can't get some protection by checking for sernum connecting, as devd
> shows:
> - my USB to PS2 adapter (vendor=0x04b4 product=0x8081) emits sernum=""
> - my real USB "Havit" keyboard (vendor=0x1241 product=0x1203) emits
> sernum=""
>
> For FreeBSD,
>   I guess for serious security, every new device that is connected
>   & recognised by /sbin/devd should in future be personaly authorised
>   by a human !  One can no longer trust what reports itself to be
>   eg a keyboard to actually Be a keyboard, etc.
>
>   /usr/src/etc/devd/*.conf & my own .conf do Not meet that awkward
>   security requirement... yet. I guess we'll need a couple of hooks
>   that support Yes/No, one from cli & one for within X11.
>
> There's no security warning section in
> 	http://en.wikipedia.org/wiki/Flash_memory
>
> Cheers,
> Julian
> --
> Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich
> http://berklix.com
>  Indent previous with "> ".  Interleave reply paragraphs like a play
> script.
>  Send plain text, not quoted-printable, HTML, base64, or
> multipart/alternative.
> 		ShellShock - http://www.berklix.com/~jhs/bash/
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
>

From jhs at berklix.com  Mon Oct  6 20:26:09 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Mon, 06 Oct 2014 22:25:48 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: Your message "Mon, 06 Oct 2014 21:56:08 +0200."
Message-ID: <201410062026.s96KPmCh090415@fire.js.berklix.net>

> one device, then pause & masquerade another device type.  This is
> an OS independent security list.
.............................^^^^  Oops typed too fast.  Swap /list/liability/

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.

From phk at phk.freebsd.dk  Mon Oct  6 20:30:09 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 06 Oct 2014 20:30:00 +0000
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: <201410061956.s96Ju8S3089675@fire.js.berklix.net>
References: <201410061956.s96Ju8S3089675@fire.js.berklix.net>
Message-ID: <66233.1412627400@critter.freebsd.dk>

--------
In message <201410061956.s96Ju8S3089675 at fire.js.berklix.net>, "Julian H. Stacey
" writes:

>For FreeBSD,
>  I guess for serious security, every new device that is connected
>  & recognised by /sbin/devd should in future be personaly authorised
>  by a human !  One can no longer trust what reports itself to be
>  eg a keyboard to actually Be a keyboard, etc.

"no longer" ?

When you could you *ever* trust a USB device about anything ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

From hps at selasky.org  Mon Oct  6 20:48:20 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Mon, 06 Oct 2014 22:48:14 +0200
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob
 Lell
In-Reply-To: <66233.1412627400@critter.freebsd.dk>
References: <201410061956.s96Ju8S3089675@fire.js.berklix.net>
 <66233.1412627400@critter.freebsd.dk>
Message-ID: <5433000E.7000404@selasky.org>

On 10/06/14 22:30, Poul-Henning Kamp wrote:
> --------
> In message <201410061956.s96Ju8S3089675 at fire.js.berklix.net>, "Julian H. Stacey
> " writes:
>
>> For FreeBSD,
>>   I guess for serious security, every new device that is connected
>>   & recognised by /sbin/devd should in future be personaly authorised
>>   by a human !  One can no longer trust what reports itself to be
>>   eg a keyboard to actually Be a keyboard, etc.
>
> "no longer" ?
>
> When you could you *ever* trust a USB device about anything ?
>

Hi,

You should not assume you can trust hardware :-) Especially removable 
hardware.

It is possible to add a sysctl to halt the probing of USB devices, so 
that USB devices can only be detached from the system. The problem is 
that if the main input is a USB keyboard and that goes away, you have no 
easy way to recover your system ...

Anyway, USB 2.0 and 1.0 are broadcast based, and technically one device 
might highjack the traffic of another one.

--HPS

From bugzilla-noreply at freebsd.org  Tue Oct  7 16:20:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 16:20:57 +0000
Subject: [Bug 194226] New: USB does not work early in the boot process when
 60/64 emulation support is enabled
Message-ID: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 194226
           Summary: USB does not work early in the boot process when 60/64
                    emulation support is enabled
           Product: Base System
           Version: 10.1-BETA3
          Hardware: amd64
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb at FreeBSD.org
          Reporter: nefar at otherware.org

My motherboard (http://www.amazon.com/gp/product/B00FM4M7TQ) which I recently
shipped arrived with "Port 60/64 emulation" enabled which according to the BIOS
"enables I/O port 60h/64h emulation support"

The downside of this emulation is that while I can select boot options, as soon
as I'm past the boot prompt, my keyboard stops working until I'm prompted to
login.

The real problem is that when enabling root disk encryption with geli, the
keyboard does NOT work when prompted for the geli keyboard.

So it seems there's some issue dealing with this emulation.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Tue Oct  7 17:01:46 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 07 Oct 2014 17:01:46 +0000
Subject: [Bug 194226] USB does not work early in the boot process when 60/64
 emulation support is enabled
In-Reply-To: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194226-17-XeMLutkfUM@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #1 from nefar at otherware.org ---
It was disabling all legacy USB options that got it geli to work for me.
However, then I was unable to choose bootloader option. So I enabled it again
and tried disabling the emulation support.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From mike at sentex.net  Tue Oct  7 19:04:44 2014
From: mike at sentex.net (Mike Tancsa)
Date: Tue, 07 Oct 2014 15:04:36 -0400
Subject: XHCI device probe inconsistency
Message-ID: <54343944.2040103@sentex.net>

Hi,
	on r272695 AMD64, I have a USB 3.0 CF reader/writer that does not 
consistently work the same.  At bootup time, if I have the reader 
attached, it connects as a USB 2.0 device. If I disconnect and reconnect 
it, it attaches and seems to function at the proper speed.

after physically disconnecting and reconnecting it shows as

  usbconfig
ugen0.1: <XHCI root HUB 0x8086> at usbus0, cfg=0 md=HOST spd=SUPER 
(5.0Gbps) pwr=SAVE (0mA)
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=SAVE (0mA)
ugen2.1: <EHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=SAVE (0mA)
ugen0.2: <USB-Serial Controller Prolific Technology Inc.> at usbus0, 
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen1.2: <product 0x8008 vendor 0x8087> at usbus1, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.2: <product 0x8000 vendor 0x8087> at usbus2, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.3: <Generic USB KB vendor 0x13ba> at usbus0, cfg=0 md=HOST spd=LOW 
(1.5Mbps) pwr=ON (100mA)
ugen0.5: <Virtual Keyboard and Mouse American Megatrends Inc.> at 
usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA)
ugen0.4: <USB3.0 Media Reader Kingston> at usbus0, cfg=0 md=HOST 
spd=SUPER (5.0Gbps) pwr=ON (200mA)



ugen0.4: <USB3.0 Media Reader Kingston> at usbus0, cfg=0 md=HOST 
spd=SUPER (5.0Gbps) pwr=ON (200mA)

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0300
   bDeviceClass = 0x0000
   bDeviceSubClass = 0x0000
   bDeviceProtocol = 0x0000
   bMaxPacketSize0 = 0x0009
   idVendor = 0x11b0
   idProduct = 0x6348
   bcdDevice = 0x0308
   iManufacturer = 0x0001  <Kingston>
   iProduct = 0x0002  <USB3.0 Media Reader>
   iSerialNumber = 0x0003  <08735342214972>
   bNumConfigurations = 0x0001

At bootup time, dmesg shows

ugen0.4: <Kingston> at usbus0
umass0: <Bulk-In, Bulk-Out, Interface> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:7:0:-1: Attached to scbus7
da0 at umass-sim0 bus 0 scbus7 target 0 lun 0
da0: < FCR-HS3       -0 1.00> Removable Direct Access SCSI-4 device
da0: Serial Number 08735342214972
da0: 40.000MB/s transfers
da0: 1919MB (3931200 512 byte sectors: 255H 63S/T 244C)
da0: quirks=0x2<NO_6_BYTE>
da1 at umass-sim0 bus 0 scbus7 target 0 lun 1
da1: < FCR-HS3       -1 1.00> Removable Direct Access SCSI-4 device
da1: Serial Number 08735342214972
da1: 40.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
da1: quirks=0x2<NO_6_BYTE>
da2 at umass-sim0 bus 0 scbus7 target 0 lun 2
da2: < FCR-HS3       -2 1.00> Removable Direct Access SCSI-4 device
da2: Serial Number 08735342214972
da2: 40.000MB/s transfers
da2: Attempt to query device size failed: NOT READY, Medium not present
da2: quirks=0x2<NO_6_BYTE>
da3 at umass-sim0 bus 0 scbus7 target 0 lun 3
da3: < FCR-HS3       -3 1.00> Removable Direct Access SCSI-4 device
da3: Serial Number 08735342214972
da3: 40.000MB/s transfers
da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2<NO_6_BYTE>
Root mount waiting for: usbus0

and then disconnect
..
(da2:umass-sim0:0:0:2): Periph destroyed
(da3:umass-sim0:0:0:3): Periph destroyed
ugen0.4: <Kingston> at usbus0
umass0: <Bulk-In, Bulk-Out, Interface> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x4000
umass0:7:0:-1: Attached to scbus7
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 
10 00 00
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid 
field in CDB)
(probe0:umass-sim0:0:0:0): Error 22, Unretryable error
da0 at umass-sim0 bus 0 scbus7 target 0 lun 0
da0: < FCR-HS3       -0 1.00> Removable Direct Access SCSI-6 device
da0: Serial Number 08735342214972
da0: 400.000MB/s transfers
da0: 1919MB (3931200 512 byte sectors: 255H 63S/T 244C)
da0: quirks=0x2<NO_6_BYTE>
da1 at umass-sim0 bus 0 scbus7 target 0 lun 1
da1: < FCR-HS3       -1 1.00> Removable Direct Access SCSI-6 device
da1: Serial Number 08735342214972
da1: 400.000MB/s transfers
da1: Attempt to query device size failed: NOT READY, Medium not present
da1: quirks=0x2<NO_6_BYTE>
da2 at umass-sim0 bus 0 scbus7 target 0 lun 2
da2: < FCR-HS3       -2 1.00> Removable Direct Access SCSI-6 device
da2: Serial Number 08735342214972
da2: 400.000MB/s transfers
da2: Attempt to query device size failed: NOT READY, Medium not present
da2: quirks=0x2<NO_6_BYTE>
da3 at umass-sim0 bus 0 scbus7 target 0 lun 3
da3: < FCR-HS3       -3 1.00> Removable Direct Access SCSI-6 device
da3: Serial Number 08735342214972
da3: 400.000MB/s transfers
da3: Attempt to query device size failed: NOT READY, Medium not present
da3: quirks=0x2<NO_6_BYTE>

and its the proper speed.

MB is
BIOS Information
         Vendor: Intel Corp.
         Version: S1200RP.86B.01.04.0002.011020141517
         Release Date: 01/10/2014
Base Board Information
         Manufacturer: Intel Corporation
         Product Name: S1200RP_SE
         Version: G62252-406

xhci0 at pci0:0:20:0:      class=0x0c0330 card=0x35b78086 chip=0x8c318086 
rev=0x05 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'Lynx Point USB xHCI Host Controller'
     class      = serial bus
     subclass   = USB
     bar   [10] = type Memory, range 64, base 0xc0120000, size 65536, 
enabled
     cap 01[70] = powerspec 2  supports D0 D3  current D0
     cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
ehci0 at pci0:0:26:0:      class=0x0c0320 card=0x35b78086 chip=0x8c2d8086 
rev=0x05 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'Lynx Point USB Enhanced Host Controller'
     class      = serial bus
     subclass   = USB
     bar   [10] = type Memory, range 32, base 0xc1420000, size 1024, enabled
     cap 01[50] = powerspec 2  supports D0 D3  current D0
     cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
     cap 13[98] = PCI Advanced Features: FLR TP



-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

From doconnor at gsoft.com.au  Tue Oct  7 21:20:02 2014
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed, 8 Oct 2014 07:49:30 +1030
Subject: Panic in usb_unref_device
In-Reply-To: <542E8D27.2060505@selasky.org>
References: <8B31CE4F-F310-49E7-8316-22D6170BF6C6@gsoft.com.au>
 <542E8D27.2060505@selasky.org>
Message-ID: <F3E6137F-C554-4199-8BF9-BF4670DE3B14@gsoft.com.au>


On 3 Oct 2014, at 21:18, Hans Petter Selasky <hps at selasky.org> wrote:
> On 10/03/14 13:19, Daniel O'Connor wrote:
>> Hi,
>> I have a custom USB device based on the Cypress FX2 and we are finding that with some older kernels it hangs - this was fixed in https://svnweb.freebsd.org/base?view=revision&revision=267240 but now it panics with?
>> 
> There's a minor bug there. Can you test the attached patch?

Sorry for the late reply (there was a holiday on Monday here) - the patch seems to have fixed the crash, thanks!

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


From jhs at berklix.com  Tue Oct  7 22:37:00 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Wed, 08 Oct 2014 00:36:05 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: Your message "Mon, 06 Oct 2014 22:48:14 +0200."
 <5433000E.7000404@selasky.org>
Message-ID: <201410072236.s97Ma56M051223@fire.js.berklix.net>

Hi
Hans Petter Selasky wrote:
> On 10/06/14 22:30, Poul-Henning Kamp wrote:
> > --------
> > In message <201410061956.s96Ju8S3089675 at fire.js.berklix.net>, "Julian H. Stacey
> > " writes:
> >
> >> For FreeBSD,
> >>   I guess for serious security, every new device that is connected
> >>   & recognised by /sbin/devd should in future be personaly authorised
> >>   by a human !  One can no longer trust what reports itself to be
> >>   eg a keyboard to actually Be a keyboard, etc.
> >
> > "no longer" ?
> >
> > When you could you *ever* trust a USB device about anything ?

Yes.  Can't even trust a memory stick, even when avoiding a reboot,
even when not mounting it.


> Hi,
> 
> You should not assume you can trust hardware :-) Especially removable 
> hardware.

Yes. That lecture has fortified my lapsed paranoia ;-)


> It is possible to add a sysctl to halt the probing of USB devices, so 
> that USB devices can only be detached from the system.

Good idea.  
Would provide more protection than my idea of some confirm Yes/No
command called from devd attach, (as a BadUSB device could masquerade
a keyboard device to say Yes).

	sysctl -a -d | grep device | rev | sort | rev | more
shows nothing, so I guess it would be nice if someone wrote such a sysctl.


> The problem is 
> that if the main input is a USB keyboard and that goes away, you have no 
> easy way to recover your system ...

Yes, sometimes some users wouldn't want to enable that sysctl,
but it would allow considerable protection for others.  I think it
would be good to have, just a question of which default state at boot,
inhibit off I guess, as now (least suprise).


> Anyway, USB 2.0 and 1.0 are broadcast based, and technically one device 
> might highjack the traffic of another one.

So a sysctl would provide more safety, but still not be totaly safe,
best we can do I guess.  The end of the lecture alluded to this
masquerading possibility, that devices had no ID encryption key to
prevent it, (& in some cases not even a serial number).

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.

From hps at selasky.org  Wed Oct  8 07:03:37 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 08 Oct 2014 09:03:31 +0200
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob
 Lell
In-Reply-To: <201410072236.s97Ma56M051223@fire.js.berklix.net>
References: <201410072236.s97Ma56M051223@fire.js.berklix.net>
Message-ID: <5434E1C3.9090605@selasky.org>

Hi,

Can you test the following kernel patch and give some feedback:

https://svnweb.freebsd.org/changeset/base/272733

After the patch you will get something like:

hw.usb.disable_enumeration: 0
dev.uhub.0.disable_enumeration: 0
dev.uhub.1.disable_enumeration: 0
...

which is also settable through /boot/loader.conf (tunable)

--HPS

From hps at selasky.org  Wed Oct  8 09:23:33 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 08 Oct 2014 11:23:27 +0200
Subject: xhci problem on UEFI boot MacBookPro 11,3
In-Reply-To: <141592A3-A4CD-48F6-B26D-35BF10436012@gmail.com>
References: <CAB8uncZeUjdJAsDcxT81Yx2wHd8EB3QEzortSXsL8R5iuSKJRA@mail.gmail.com>
 <CAB8uncYd24GkgK8Dsd51BAhoMjKFoAeS3AQ0a0=1mZjeprjHUw@mail.gmail.com>
 <541FBD6F.2080507@selasky.org>
 <CAB8uncb+HtjDXJG7gS1QGz8ayR+woaO-UWFbwTVXHrCXnQoa2A@mail.gmail.com>
 <541FDDF0.90502@selasky.org>
 <CAB8uncZaESbHiDJfYjybTg7mfhq0MG66+UqshxqDFVTej6rkeA@mail.gmail.com>
 <CAB8uncYrf=zP=ithL=dCci4opir4U0AWGCWM3JU38EscPdp3Og@mail.gmail.com>
 <542662BE.5050908@selasky.org>
 <CAB8uncYuMvc1hXxJib_bDs+AOrYhCfVkaV8O5VtgjFjJo_T2mA@mail.gmail.com>
 <542701FA.2000408@selasky.org> <5427029B.3060502@selasky.org>
 <CAB8uncajuWXGc6Lb3AmHC6qdnefXmYF4_8h4VPwzNaM595Dy+g@mail.gmail.com>
 <5427AC46.3040707@selasky.org>
 <CAB8uncYZpZ5+gAw5FmXTJ8CH5KBpDqaYHqB00b=FEQVXONd4-g@mail.gmail.com>
 <CAB8uncb6ycJeYaMairr7XnhQBKNtYgYovH2vYNgB_xEGb8BGhw@mail.gmail.com>
 <CAB8uncZ=9Hi04YKX4VDX0zzOGQPhV61rurwKmHXdz2FouWw5wA@mail.gmail.com>
 <542E3F02.4050401@selasky.org>
 <141592A3-A4CD-48F6-B26D-35BF10436012@gmail.com>
Message-ID: <5435028F.1080806@selasky.org>

FYI

This issue was fixed by:

https://svnweb.freebsd.org/changeset/base/272589

--HPS

From hps at selasky.org  Wed Oct  8 09:24:31 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 08 Oct 2014 11:24:26 +0200
Subject: Panic in usb_unref_device
In-Reply-To: <F3E6137F-C554-4199-8BF9-BF4670DE3B14@gsoft.com.au>
References: <8B31CE4F-F310-49E7-8316-22D6170BF6C6@gsoft.com.au>
 <542E8D27.2060505@selasky.org>
 <F3E6137F-C554-4199-8BF9-BF4670DE3B14@gsoft.com.au>
Message-ID: <543502CA.1030707@selasky.org>

On 10/07/14 23:19, Daniel O'Connor wrote:
>
> On 3 Oct 2014, at 21:18, Hans Petter Selasky <hps at selasky.org> wrote:
>> On 10/03/14 13:19, Daniel O'Connor wrote:
>>> Hi,
>>> I have a custom USB device based on the Cypress FX2 and we are finding that with some older kernels it hangs - this was fixed in https://svnweb.freebsd.org/base?view=revision&revision=267240 but now it panics with?
>>>
>> There's a minor bug there. Can you test the attached patch?
>
> Sorry for the late reply (there was a holiday on Monday here) - the patch seems to have fixed the crash, thanks!

You're welcome!

--HPS


From hps at selasky.org  Wed Oct  8 09:27:34 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 08 Oct 2014 11:27:29 +0200
Subject: XHCI device probe inconsistency
In-Reply-To: <54343944.2040103@sentex.net>
References: <54343944.2040103@sentex.net>
Message-ID: <54350381.4020609@selasky.org>

On 10/07/14 21:04, Mike Tancsa wrote:
> ugen0.4: <USB3.0 Media Reader Kingston> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (200mA)

Hi,

If you plug the device after boot, what happens then?

What speed does the BIOS enumerate the device at?

Have you checked for USB related BIOS settings?

--HPS

From bugzilla-noreply at freebsd.org  Wed Oct  8 09:30:30 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 09:30:30 +0000
Subject: [Bug 194226] USB does not work early in the boot process when 60/64
 emulation support is enabled
In-Reply-To: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194226-17-rmAHxLoZ9w@https.bugs.freebsd.org/bugzilla/>

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

Hans Petter Selasky <hselasky at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hselasky at FreeBSD.org

--- Comment #2 from Hans Petter Selasky <hselasky at FreeBSD.org> ---
Hi,

Is the "ukbd" driver in the kernel or loaded as a module?

If the keyboard is enumerated before the mount root prompt and password prompt,
it should work.

There are some loader options to make the kernel wait a bit more for USB
devices to show up.

BTW: Is this also a problem with 10-stable. Depending on your USB controller,
the following patch might help:

https://svnweb.freebsd.org/changeset/base/272589

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Wed Oct  8 09:30:50 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 09:30:50 +0000
Subject: [Bug 194226] USB does not work early in the boot process when 60/64
 emulation support is enabled
In-Reply-To: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194226-17-rBP5J9CAzD@https.bugs.freebsd.org/bugzilla/>

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

Hans Petter Selasky <hselasky at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|---                         |Normal
             Status|Needs Triage                |In Discussion

-- 
You are receiving this mail because:
You are the assignee for the bug.

From mike at sentex.net  Wed Oct  8 14:37:59 2014
From: mike at sentex.net (Mike Tancsa)
Date: Wed, 08 Oct 2014 10:37:50 -0400
Subject: XHCI device probe inconsistency
In-Reply-To: <54350381.4020609@selasky.org>
References: <54343944.2040103@sentex.net> <54350381.4020609@selasky.org>
Message-ID: <54354C3E.5080100@sentex.net>

On 10/8/2014 5:27 AM, Hans Petter Selasky wrote:
> Hi,
>
> If you plug the device after boot, what happens then?
>
> What speed does the BIOS enumerate the device at?
>
> Have you checked for USB related BIOS settings?

Hi,
	Hmmm, I could not recreate the issue at first!!  I tried both a soft 
and cold boot, and with and without a CF in it and it would always come 
up as USB3....

And then I remember setting the BIOS option

Make USB Non Bootable (Enable/Disable)

so it would not try and boot from the flash.

Once I set that to enable, so it could not boot from a USB device, the 
CF Reader/Writer always probes as USB3 speed!  When its disabled, at 
boot time it probes as USB2 speeds until I disconnect / reconnect.

Thanks!

	---Mike




-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

From bugzilla-noreply at freebsd.org  Wed Oct  8 16:13:11 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 16:13:12 +0000
Subject: [Bug 194226] USB does not work early in the boot process when 60/64
 emulation support is enabled
In-Reply-To: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194226-17-q8ioguIMSE@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #3 from nefar at otherware.org ---
Using vanilla 10.1-BETA3 kernel. No changes in kernel on how "ukbd" is loaded.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Wed Oct  8 16:17:36 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 16:17:35 +0000
Subject: [Bug 194226] USB does not work early in the boot process when 60/64
 emulation support is enabled
In-Reply-To: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194226-17-ZSPkZy4ZRC@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #4 from Hans Petter Selasky <hselasky at FreeBSD.org> ---
Can you show dmesg?

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Wed Oct  8 16:20:14 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Wed, 08 Oct 2014 16:20:14 +0000
Subject: [Bug 194226] USB does not work early in the boot process when 60/64
 emulation support is enabled
In-Reply-To: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194226-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194226-17-9uKYgf8CLH@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #5 from nefar at otherware.org ---
Yes. Standby.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From jhs at berklix.com  Wed Oct  8 20:01:04 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Wed, 08 Oct 2014 21:01:06 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: Your message "Wed, 08 Oct 2014 09:03:31 +0200."
 <5434E1C3.9090605@selasky.org>
Message-ID: <201410081901.s98J160W019899@fire.js.berklix.net>

Hans Petter Selasky wrote:
> Hi,
> 
> Can you test the following kernel patch and give some feedback:
> 
> https://svnweb.freebsd.org/changeset/base/272733
> 
> After the patch you will get something like:
> 
> hw.usb.disable_enumeration: 0
> dev.uhub.0.disable_enumeration: 0
> dev.uhub.1.disable_enumeration: 0
> ...
> 
> which is also settable through /boot/loader.conf (tunable)

Thanks, Quick work !
I downloaded, but before use,
I ran a make world as my current was maybe a week or 2 old,
I made a new generic kernel with CTM src-cur.11644.gz ie (latest
CVS as supplied by CTM)
But src/ make all failed so I ran make world, which also failed:
	-------------------
	/usr/obj/usr/src/tmp/usr/include/dev/usb/usb.h:154:16: note: forward declaration
	      of 'struct usb_device_request'
	typedef struct usb_device_request usb_device_request_t;
	               ^
	19 errors generated.
	*** Error code 1
	
	Stop.
	make[4]: stopped in /usr/src/lib/libusbhid
	-------------------

In parallel to make world I applied your patches to make & that failed:
	--------
	/sys/amd64/compile/GENERIC 
	../../../dev/usb/usbdi.h:301:5: warning: 'USB_HAVE_COMPAT_LINUX' is not defined, evaluates to 0 [-Wundef]
	#if USB_HAVE_COMPAT_LINUX
	    ^
	2 warnings generated.
	mkdep: compile failed
	*** Error code 1
	
	Stop.
	make: stopped in /usr/src/sys/amd64/compile/GENERIC
	--------
But that may be because my system is pehaps a couple of weeks old or so.

The latest generic src/ kernel booted OK 
	FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Wed Oct  8 17:26:13 CEST 2014     jhs at lapr.js.berklix.net:/usr/src/sys/amd64/compile/GENERIC  amd64
	(though I noticed a named: lock order reversal that I will ignore)

When I can get src/ to build (I'm using make -k all now :-),
I'll go back to compiling GENERIC kernel with your changeset/base/272733

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.

From jhs at berklix.com  Wed Oct  8 23:47:44 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Thu, 09 Oct 2014 01:46:44 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: Your message "Wed, 08 Oct 2014 21:01:06 +0200."
 <201410081901.s98J160W019899@fire.js.berklix.net>
Message-ID: <201410082347.s98NkjW3025396@fire.js.berklix.net>

Hi Hans etc
"Julian H. Stacey" wrote:
> Hans Petter Selasky wrote:
> > Hi,
> > 
> > Can you test the following kernel patch and give some feedback:
> > 
> > https://svnweb.freebsd.org/changeset/base/272733

I'm now on latest current with src & sys/ GENERIC 
/usr/src/.ctm_status	# src-cur 11645

This time I downloaded your files properly
(last time I was severely distracted & made a silly mistake)

> > After the patch you will get something like:
> > hw.usb.disable_enumeration: 0
> > dev.uhub.0.disable_enumeration: 0
> > dev.uhub.1.disable_enumeration: 0
> > ...

sysctl -a | grep  enumeration
  hw.usb.disable_enumeration: 0
  dev.uhub.0.disable_enumeration: 0
  dev.uhub.1.disable_enumeration: 0
  dev.uhub.2.disable_enumeration: 0
  dev.uhub.3.disable_enumeration: 0
  dev.uhub.4.disable_enumeration: 0

sysctl -d hw.usb.disable_enumeration
  hw.usb.disable_enumeration: Set to disable all USB device enumeration.

sysctl -d dev.uhub.4.disable_enumeration
  dev.uhub.4.disable_enumeration: Set to disable enumeration on this USB HUB.

usbconfig
ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=OFF (500mA)
ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)

Inserted a WLAN stick
usbconfig
ugen1.5: <802.11 n WLAN Ralink> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA)
ifconfig -a shows run0 & wlan0

Removed WLAN stick
sysctl dev.uhub.4.disable_enumeration=1

Added WLAN stick
ifconfig -a	No run0 & wlan0

Added WLAN stick on different direct PC socket:
ifconfig -a 	Shows run0 & wlan0

usbconfig
ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=OFF (500mA)
ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
ugen1.5: <802.11 n WLAN Ralink> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA)

Great ! Seems to work.

(Though I need to read up on how major & minor of ugen relate to
the digit in eg 4.disable_enumeration)


> > which is also settable through /boot/loader.conf (tunable)

Good, 
I hope/presume loader.conf gets run before any USB, cos I recall
lecturer Karsten Nohl pointing out one could get BadUSB taking up
residence in USB controller chips inside a PC, ie for a built in
mouse or web cam, so one would need to turn off enumeration earlier
than when first external USB approaches to connect.

I've reported back on BBC news form:
	Ref. your 
	6 October 2014 Last updated at 15:29 GMT 
	http://www.bbc.com/news/technology-29475566

	The www.FreeBSD.org project (a Unix OS similar to Linux)
	took just 2 days to develop & test a free solution.
	http://lists.freebsd.org/pipermail/freebsd-usb/2014-October/013304.html

Well done, Thanks Hans!

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.

From hps at selasky.org  Thu Oct  9 06:27:52 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 09 Oct 2014 08:27:46 +0200
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob
 Lell
In-Reply-To: <201410082347.s98NkjW3025396@fire.js.berklix.net>
References: <201410082347.s98NkjW3025396@fire.js.berklix.net>
Message-ID: <54362AE2.90501@selasky.org>

Hi Julian,

On 10/09/14 01:46, Julian H. Stacey wrote:
> Hi Hans etc
> "Julian H. Stacey" wrote:
>> Hans Petter Selasky wrote:
>>> Hi,
>>>
>>> Can you test the following kernel patch and give some feedback:
>>>
>>> https://svnweb.freebsd.org/changeset/base/272733
>
> I'm now on latest current with src & sys/ GENERIC
> /usr/src/.ctm_status	# src-cur 11645
>
> This time I downloaded your files properly
> (last time I was severely distracted & made a silly mistake)
>
>>> After the patch you will get something like:
>>> hw.usb.disable_enumeration: 0
>>> dev.uhub.0.disable_enumeration: 0
>>> dev.uhub.1.disable_enumeration: 0
>>> ...
>
> sysctl -a | grep  enumeration
>    hw.usb.disable_enumeration: 0
>    dev.uhub.0.disable_enumeration: 0
>    dev.uhub.1.disable_enumeration: 0
>    dev.uhub.2.disable_enumeration: 0
>    dev.uhub.3.disable_enumeration: 0
>    dev.uhub.4.disable_enumeration: 0
>
> sysctl -d hw.usb.disable_enumeration
>    hw.usb.disable_enumeration: Set to disable all USB device enumeration.
>
> sysctl -d dev.uhub.4.disable_enumeration
>    dev.uhub.4.disable_enumeration: Set to disable enumeration on this USB HUB.
>
> usbconfig
> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
> ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
> ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
> ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH (480Mbps) pwr=OFF (500mA)
> ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
> ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
>

>
> Great ! Seems to work.
>
> (Though I need to read up on how major & minor of ugen relate to
> the digit in eg 4.disable_enumeration)
>
>
>>> which is also settable through /boot/loader.conf (tunable)
>
> Good,
> I hope/presume loader.conf gets run before any USB, cos I recall
> lecturer Karsten Nohl pointing out one could get BadUSB taking up
> residence in USB controller chips inside a PC, ie for a built in
> mouse or web cam, so one would need to turn off enumeration earlier
> than when first external USB approaches to connect.

Yes, if set by the loader.conf, you will only see the RootHUB after boot.

To get devices back after enabling enumeration again, you will need to 
reset the HUBs:

usbconfig -d X.1 reset

For example.

BTW: I've added some exceptions, that existing devices can be detached, 
suspend/resumed and reset while the enumeration is disabled.

https://svnweb.freebsd.org/changeset/base/272807

>
> I've reported back on BBC news form:
> 	Ref. your
> 	6 October 2014 Last updated at 15:29 GMT
> 	http://www.bbc.com/news/technology-29475566
>
> 	The www.FreeBSD.org project (a Unix OS similar to Linux)
> 	took just 2 days to develop & test a free solution.
> 	http://lists.freebsd.org/pipermail/freebsd-usb/2014-October/013304.html
>

Can you also test that patch?

Thank you!

--HPS


From oliver.pntr at gmail.com  Thu Oct  9 13:59:32 2014
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Thu, 9 Oct 2014 15:59:28 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: <54362AE2.90501@selasky.org>
References: <201410082347.s98NkjW3025396@fire.js.berklix.net>
 <54362AE2.90501@selasky.org>
Message-ID: <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>

On 10/9/14, Hans Petter Selasky <hps at selasky.org> wrote:
> Hi Julian,
>
> On 10/09/14 01:46, Julian H. Stacey wrote:
>> Hi Hans etc
>> "Julian H. Stacey" wrote:
>>> Hans Petter Selasky wrote:
>>>> Hi,
>>>>
>>>> Can you test the following kernel patch and give some feedback:
>>>>
>>>> https://svnweb.freebsd.org/changeset/base/272733
>>
>> I'm now on latest current with src & sys/ GENERIC
>> /usr/src/.ctm_status	# src-cur 11645
>>
>> This time I downloaded your files properly
>> (last time I was severely distracted & made a silly mistake)
>>
>>>> After the patch you will get something like:
>>>> hw.usb.disable_enumeration: 0
>>>> dev.uhub.0.disable_enumeration: 0
>>>> dev.uhub.1.disable_enumeration: 0
>>>> ...
>>
>> sysctl -a | grep  enumeration
>>    hw.usb.disable_enumeration: 0
>>    dev.uhub.0.disable_enumeration: 0
>>    dev.uhub.1.disable_enumeration: 0
>>    dev.uhub.2.disable_enumeration: 0
>>    dev.uhub.3.disable_enumeration: 0
>>    dev.uhub.4.disable_enumeration: 0
>>
>> sysctl -d hw.usb.disable_enumeration
>>    hw.usb.disable_enumeration: Set to disable all USB device enumeration.
>>
>> sysctl -d dev.uhub.4.disable_enumeration
>>    dev.uhub.4.disable_enumeration: Set to disable enumeration on this USB
>> HUB.
>>
>> usbconfig
>> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
>> pwr=SAVE (0mA)
>> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
>> pwr=SAVE (0mA)
>> ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=SAVE (0mA)
>> ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=SAVE (0mA)
>> ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH
>> (480Mbps) pwr=OFF (500mA)
>> ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1, cfg=0
>> md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
>> ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH
>> (480Mbps) pwr=SAVE (100mA)
>>
>
>>
>> Great ! Seems to work.
>>
>> (Though I need to read up on how major & minor of ugen relate to
>> the digit in eg 4.disable_enumeration)
>>
>>
>>>> which is also settable through /boot/loader.conf (tunable)
>>
>> Good,
>> I hope/presume loader.conf gets run before any USB, cos I recall
>> lecturer Karsten Nohl pointing out one could get BadUSB taking up
>> residence in USB controller chips inside a PC, ie for a built in
>> mouse or web cam, so one would need to turn off enumeration earlier
>> than when first external USB approaches to connect.
>
> Yes, if set by the loader.conf, you will only see the RootHUB after boot.
>
> To get devices back after enabling enumeration again, you will need to
> reset the HUBs:
>
> usbconfig -d X.1 reset
>
> For example.
>
> BTW: I've added some exceptions, that existing devices can be detached,
> suspend/resumed and reset while the enumeration is disabled.

Can we somehow improve this change, to powering down the ports/hubs
which has the enumeration disabled?

>
> https://svnweb.freebsd.org/changeset/base/272807
>
>>
>> I've reported back on BBC news form:
>> 	Ref. your
>> 	6 October 2014 Last updated at 15:29 GMT
>> 	http://www.bbc.com/news/technology-29475566
>>
>> 	The www.FreeBSD.org project (a Unix OS similar to Linux)
>> 	took just 2 days to develop & test a free solution.
>> 	http://lists.freebsd.org/pipermail/freebsd-usb/2014-October/013304.html
>>
>
> Can you also test that patch?
>
> Thank you!
>
> --HPS
>
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
>

From jhs at berklix.com  Thu Oct  9 14:07:17 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Thu, 09 Oct 2014 16:06:21 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: Your message "Thu, 09 Oct 2014 15:59:28 +0200."
 <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>
Message-ID: <201410091406.s99E6MpE089417@fire.js.berklix.net>

Hi, Reference:
> From:		Oliver Pinter <oliver.pntr at gmail.com>
> Date:		Thu, 9 Oct 2014 15:59:28 +0200

Oliver Pinter wrote:
> On 10/9/14, Hans Petter Selasky <hps at selasky.org> wrote:
> > Hi Julian,
> >
> > On 10/09/14 01:46, Julian H. Stacey wrote:
> >> Hi Hans etc
> >> "Julian H. Stacey" wrote:
> >>> Hans Petter Selasky wrote:
> >>>> Hi,
> >>>>
> >>>> Can you test the following kernel patch and give some feedback:
> >>>>
> >>>> https://svnweb.freebsd.org/changeset/base/272733
> >>
> >> I'm now on latest current with src & sys/ GENERIC
> >> /usr/src/.ctm_status	# src-cur 11645
> >>
> >> This time I downloaded your files properly
> >> (last time I was severely distracted & made a silly mistake)
> >>
> >>>> After the patch you will get something like:
> >>>> hw.usb.disable_enumeration: 0
> >>>> dev.uhub.0.disable_enumeration: 0
> >>>> dev.uhub.1.disable_enumeration: 0
> >>>> ...
> >>
> >> sysctl -a | grep  enumeration
> >>    hw.usb.disable_enumeration: 0
> >>    dev.uhub.0.disable_enumeration: 0
> >>    dev.uhub.1.disable_enumeration: 0
> >>    dev.uhub.2.disable_enumeration: 0
> >>    dev.uhub.3.disable_enumeration: 0
> >>    dev.uhub.4.disable_enumeration: 0
> >>
> >> sysctl -d hw.usb.disable_enumeration
> >>    hw.usb.disable_enumeration: Set to disable all USB device enumeration.
> >>
> >> sysctl -d dev.uhub.4.disable_enumeration
> >>    dev.uhub.4.disable_enumeration: Set to disable enumeration on this USB
> >> HUB.
> >>
> >> usbconfig
> >> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
> >> pwr=SAVE (0mA)
> >> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
> >> pwr=SAVE (0mA)
> >> ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH
> >> (480Mbps) pwr=SAVE (0mA)
> >> ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH
> >> (480Mbps) pwr=SAVE (0mA)
> >> ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH
> >> (480Mbps) pwr=OFF (500mA)
> >> ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1, cfg=0
> >> md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
> >> ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH
> >> (480Mbps) pwr=SAVE (100mA)
> >>
> >
> >>
> >> Great ! Seems to work.
> >>
> >> (Though I need to read up on how major & minor of ugen relate to
> >> the digit in eg 4.disable_enumeration)
> >>
> >>
> >>>> which is also settable through /boot/loader.conf (tunable)
> >>
> >> Good,
> >> I hope/presume loader.conf gets run before any USB, cos I recall
> >> lecturer Karsten Nohl pointing out one could get BadUSB taking up
> >> residence in USB controller chips inside a PC, ie for a built in
> >> mouse or web cam, so one would need to turn off enumeration earlier
> >> than when first external USB approaches to connect.
> >
> > Yes, if set by the loader.conf, you will only see the RootHUB after boot.
> >
> > To get devices back after enabling enumeration again, you will need to
> > reset the HUBs:
> >
> > usbconfig -d X.1 reset
> >
> > For example.
> >
> > BTW: I've added some exceptions, that existing devices can be detached,
> > suspend/resumed and reset while the enumeration is disabled.
> 
> Can we somehow improve this change, to powering down the ports/hubs
> which has the enumeration disabled?

It's usefull to have the port remain powered up for when someone says

"Can I charge my smart phone on your PC/ laptop ?"

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.

From jhs at berklix.com  Thu Oct  9 14:30:12 2014
From: jhs at berklix.com (Julian H. Stacey)
Date: Thu, 09 Oct 2014 16:29:26 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: Your message "Thu, 09 Oct 2014 08:27:46 +0200."
 <54362AE2.90501@selasky.org>
Message-ID: <201410091429.s99ETQZ7090227@fire.js.berklix.net>

> BTW: I've added some exceptions, that existing devices can be detached, 
> suspend/resumed and reset while the enumeration is disabled.
> 
> https://svnweb.freebsd.org/changeset/base/272807

> Can you also test that patch?

OK, will do.  (I've got a cold so I'm slow & making mistakes, sorry).

I thought I had to first download & overlay those files to replace my
(automatically CTM updated) current, 
(as I also replaced the last set manually, since backed out)

It seems (from MD5s) your code is already in current.
(& I can see diffs between eg 
	revision=272733/sys/dev/usb/usb_hub.c                     
	revision=272807/sys/dev/usb/usb_hub.c
) & my current matches 272807 apart from a header line artifact of svn,

I saw comment MFC & wrongly assumed Merge For Current in 2 weeks,
I assume I was wrong & it's Merge From Current to stable in 2 weeks).

So I've made & rebooted standard current & just need to test now.

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.

From hps at selasky.org  Thu Oct  9 14:44:24 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 09 Oct 2014 16:44:19 +0200
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob
 Lell
In-Reply-To: <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>
References: <201410082347.s98NkjW3025396@fire.js.berklix.net>	<54362AE2.90501@selasky.org>
 <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>
Message-ID: <54369F43.9010806@selasky.org>

On 10/09/14 15:59, Oliver Pinter wrote:
> On 10/9/14, Hans Petter Selasky <hps at selasky.org> wrote:
>> Hi Julian,
>>
>> On 10/09/14 01:46, Julian H. Stacey wrote:
>>> Hi Hans etc
>>> "Julian H. Stacey" wrote:
>>>> Hans Petter Selasky wrote:
>>>>> Hi,
>>>>>
>>>>> Can you test the following kernel patch and give some feedback:
>>>>>
>>>>> https://svnweb.freebsd.org/changeset/base/272733
>>>
>>> I'm now on latest current with src & sys/ GENERIC
>>> /usr/src/.ctm_status	# src-cur 11645
>>>
>>> This time I downloaded your files properly
>>> (last time I was severely distracted & made a silly mistake)
>>>
>>>>> After the patch you will get something like:
>>>>> hw.usb.disable_enumeration: 0
>>>>> dev.uhub.0.disable_enumeration: 0
>>>>> dev.uhub.1.disable_enumeration: 0
>>>>> ...
>>>
>>> sysctl -a | grep  enumeration
>>>     hw.usb.disable_enumeration: 0
>>>     dev.uhub.0.disable_enumeration: 0
>>>     dev.uhub.1.disable_enumeration: 0
>>>     dev.uhub.2.disable_enumeration: 0
>>>     dev.uhub.3.disable_enumeration: 0
>>>     dev.uhub.4.disable_enumeration: 0
>>>
>>> sysctl -d hw.usb.disable_enumeration
>>>     hw.usb.disable_enumeration: Set to disable all USB device enumeration.
>>>
>>> sysctl -d dev.uhub.4.disable_enumeration
>>>     dev.uhub.4.disable_enumeration: Set to disable enumeration on this USB
>>> HUB.
>>>
>>> usbconfig
>>> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
>>> pwr=SAVE (0mA)
>>> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
>>> pwr=SAVE (0mA)
>>> ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH
>>> (480Mbps) pwr=SAVE (0mA)
>>> ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH
>>> (480Mbps) pwr=SAVE (0mA)
>>> ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH
>>> (480Mbps) pwr=OFF (500mA)
>>> ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1, cfg=0
>>> md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
>>> ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH
>>> (480Mbps) pwr=SAVE (100mA)
>>>
>>
>>>
>>> Great ! Seems to work.
>>>
>>> (Though I need to read up on how major & minor of ugen relate to
>>> the digit in eg 4.disable_enumeration)
>>>
>>>
>>>>> which is also settable through /boot/loader.conf (tunable)
>>>
>>> Good,
>>> I hope/presume loader.conf gets run before any USB, cos I recall
>>> lecturer Karsten Nohl pointing out one could get BadUSB taking up
>>> residence in USB controller chips inside a PC, ie for a built in
>>> mouse or web cam, so one would need to turn off enumeration earlier
>>> than when first external USB approaches to connect.
>>
>> Yes, if set by the loader.conf, you will only see the RootHUB after boot.
>>
>> To get devices back after enabling enumeration again, you will need to
>> reset the HUBs:
>>
>> usbconfig -d X.1 reset
>>
>> For example.
>>
>> BTW: I've added some exceptions, that existing devices can be detached,
>> suspend/resumed and reset while the enumeration is disabled.
>
> Can we somehow improve this change, to powering down the ports/hubs
> which has the enumeration disabled?
>

Hi,

I've added this as an orthogonal feature. Please test and report back:

hw.usb.disable_enumeration: 0
hw.usb.disable_port_power: 0

dev.uhub.0.disable_enumeration: 0
dev.uhub.0.disable_port_power: 0

https://svnweb.freebsd.org/changeset/base/272822

Thank you!

--HPS


From oliver.pntr at gmail.com  Thu Oct  9 15:04:12 2014
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Thu, 9 Oct 2014 17:04:10 +0200
Subject: BadUSB - On Accessories that Turn Evil,
 by Karsten Nohl + Jakob Lell
In-Reply-To: <54369F43.9010806@selasky.org>
References: <201410082347.s98NkjW3025396@fire.js.berklix.net>
 <54362AE2.90501@selasky.org>
 <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>
 <54369F43.9010806@selasky.org>
Message-ID: <CAPjTQNE9=iJ=5bF-xqhr4VsFeSWyZmm+9evduX=JFy3CgVFqVA@mail.gmail.com>

On 10/9/14, Hans Petter Selasky <hps at selasky.org> wrote:
> On 10/09/14 15:59, Oliver Pinter wrote:
>> On 10/9/14, Hans Petter Selasky <hps at selasky.org> wrote:
>>> Hi Julian,
>>>
>>> On 10/09/14 01:46, Julian H. Stacey wrote:
>>>> Hi Hans etc
>>>> "Julian H. Stacey" wrote:
>>>>> Hans Petter Selasky wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Can you test the following kernel patch and give some feedback:
>>>>>>
>>>>>> https://svnweb.freebsd.org/changeset/base/272733
>>>>
>>>> I'm now on latest current with src & sys/ GENERIC
>>>> /usr/src/.ctm_status	# src-cur 11645
>>>>
>>>> This time I downloaded your files properly
>>>> (last time I was severely distracted & made a silly mistake)
>>>>
>>>>>> After the patch you will get something like:
>>>>>> hw.usb.disable_enumeration: 0
>>>>>> dev.uhub.0.disable_enumeration: 0
>>>>>> dev.uhub.1.disable_enumeration: 0
>>>>>> ...
>>>>
>>>> sysctl -a | grep  enumeration
>>>>     hw.usb.disable_enumeration: 0
>>>>     dev.uhub.0.disable_enumeration: 0
>>>>     dev.uhub.1.disable_enumeration: 0
>>>>     dev.uhub.2.disable_enumeration: 0
>>>>     dev.uhub.3.disable_enumeration: 0
>>>>     dev.uhub.4.disable_enumeration: 0
>>>>
>>>> sysctl -d hw.usb.disable_enumeration
>>>>     hw.usb.disable_enumeration: Set to disable all USB device
>>>> enumeration.
>>>>
>>>> sysctl -d dev.uhub.4.disable_enumeration
>>>>     dev.uhub.4.disable_enumeration: Set to disable enumeration on this
>>>> USB
>>>> HUB.
>>>>
>>>> usbconfig
>>>> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH
>>>> (480Mbps)
>>>> pwr=SAVE (0mA)
>>>> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH
>>>> (480Mbps)
>>>> pwr=SAVE (0mA)
>>>> ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST
>>>> spd=HIGH
>>>> (480Mbps) pwr=SAVE (0mA)
>>>> ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST
>>>> spd=HIGH
>>>> (480Mbps) pwr=SAVE (0mA)
>>>> ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH
>>>> (480Mbps) pwr=OFF (500mA)
>>>> ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1,
>>>> cfg=0
>>>> md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
>>>> ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH
>>>> (480Mbps) pwr=SAVE (100mA)
>>>>
>>>
>>>>
>>>> Great ! Seems to work.
>>>>
>>>> (Though I need to read up on how major & minor of ugen relate to
>>>> the digit in eg 4.disable_enumeration)
>>>>
>>>>
>>>>>> which is also settable through /boot/loader.conf (tunable)
>>>>
>>>> Good,
>>>> I hope/presume loader.conf gets run before any USB, cos I recall
>>>> lecturer Karsten Nohl pointing out one could get BadUSB taking up
>>>> residence in USB controller chips inside a PC, ie for a built in
>>>> mouse or web cam, so one would need to turn off enumeration earlier
>>>> than when first external USB approaches to connect.
>>>
>>> Yes, if set by the loader.conf, you will only see the RootHUB after
>>> boot.
>>>
>>> To get devices back after enabling enumeration again, you will need to
>>> reset the HUBs:
>>>
>>> usbconfig -d X.1 reset
>>>
>>> For example.
>>>
>>> BTW: I've added some exceptions, that existing devices can be detached,
>>> suspend/resumed and reset while the enumeration is disabled.
>>
>> Can we somehow improve this change, to powering down the ports/hubs
>> which has the enumeration disabled?
>>
>
> Hi,
>
> I've added this as an orthogonal feature. Please test and report back:
>
> hw.usb.disable_enumeration: 0
> hw.usb.disable_port_power: 0
>
> dev.uhub.0.disable_enumeration: 0
> dev.uhub.0.disable_port_power: 0
>
> https://svnweb.freebsd.org/changeset/base/272822

Cool! Thanks! I will test it shortly.

>
> Thank you!
>
> --HPS
>
>

From bugzilla-noreply at freebsd.org  Mon Oct 13 22:44:44 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 13 Oct 2014 22:44:44 +0000
Subject: [Bug 194340] New: Can't boot USB memstick 10.1-RC2 on HP EliteBook
 8460p
Message-ID: <bug-194340-17@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 194340
           Summary: Can't boot USB memstick 10.1-RC2 on HP EliteBook 8460p
           Product: Base System
           Version: 10.1-BETA3
          Hardware: amd64
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: usb
          Assignee: freebsd-usb at FreeBSD.org
          Reporter: olivier at cochard.me

My Elitbook can't boot the USB memstick 10.1-RC2: "BTX Halted" error message.

This problem should be on the USB memstick image format, because this laptop
can boot and run 10.1-RC1 (an old 10.0 upgraded) without problem from its hard
drive.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Tue Oct 14 02:52:05 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 14 Oct 2014 02:52:05 +0000
Subject: [Bug 194340] Can't boot USB memstick 10.1-RC2 on HP EliteBook 8460p
In-Reply-To: <bug-194340-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194340-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194340-17-nMz2ana6sc@https.bugs.freebsd.org/bugzilla/>

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

Tomek CEDRO <cederom at tlen.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cederom at tlen.pl

--- Comment #1 from Tomek CEDRO <cederom at tlen.pl> ---
The same here with HP EliteBook 2740p that can only boot from USB (no
OpticalDrive). Load hangs at random times in bootloader and/or kernel load. I
had to do a PXE Boot Install to get system running.

In other situation I have noticed USB HUB problems. My USB Ethernet adapter
does not work here when connected directly to a port, but works  when connected
via USB HUB. Maybe that would be a hint :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

From uqs at FreeBSD.org  Tue Oct 14 19:43:48 2014
From: uqs at FreeBSD.org (=?UTF-8?Q?Ulrich_Sp=C3=B6rlein?=)
Date: Tue, 14 Oct 2014 21:43:45 +0200
Subject: CEC device not attaching to xHCI port
In-Reply-To: <5431AE55.4030006@selasky.org>
References: <20140929174904.GA15642@coyote.spoerlein.net>
 <CAJ9axoQ=+ODvNrr_D8PiBOwNFrn_u3SSm7NueXPoP9hmsbjK1g@mail.gmail.com>
 <54308CA8.5020304@selasky.org>
 <CAJ9axoTwk55o+9yTKhtipwLuBeEmPoojbQ7-hmMQ_mYbRDzjkg@mail.gmail.com>
 <5431AE55.4030006@selasky.org>
Message-ID: <CAJ9axoR2iQ=8bNF9Oc1ZW=W_f=0w3iKj=Me=UXaWeHz_-XQ9hQ@mail.gmail.com>

2014-10-05 22:47 GMT+02:00 Hans Petter Selasky <hps at selasky.org>:
>
> On 10/05/14 16:05, Ulrich Sp?rlein wrote:
>>
>> 2014-10-05 2:11 GMT+02:00 Hans Petter Selasky <hps at selasky.org>:
>>>
>>> On 10/04/14 15:53, Ulrich Sp?rlein wrote:
>>>>
>>>>
>>>> 2014-09-29 19:49 GMT+02:00 Ulrich Sp?rlein <uqs at freebsd.org>:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I got a CEC adapter using libCEC to bridge the gap between my XBMC and
>>>>> TV. The device works fine *if* I plug it into the front ports (which is
>>>>> a bit ugly, so I was wondering why this is not working on the other USB
>>>>> hub).
>>>>>
>>>
>>> Hi,
>>>
>>> How many ports have your XHCI got? See dmesg.
>>>
>>> --HPS
>>
>>
>> Hey
>>
>> physically I count 4 in the back and 4 in the front (which is an
>> expansion plate). Two ports in the back will happily serve umass(4)
>> devices (not shown in the dmesg below, I only connect them every once
>> in a while).
>>
>
> Maybe you need this patch:
>
> https://svnweb.freebsd.org/changeset/base/272479

I saw that this was merged to 10.1 recently and gave that new kernel a
go, alas no luck

usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_TIMEOUT
usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
usbd_setup_device_desc: getting device descriptor at addr 2 failed,
USB_ERR_TIMEOUT
ugen0.2: <Unknown> at usbus0 (disconnected)
uhub_reattach_port: could not allocate new device

From happier42165 at gmail.com  Wed Oct 15 18:30:02 2014
From: happier42165 at gmail.com (happier42165 at gmail.com)
Date: Wed, 15 Oct 2014 11:30:01 -0700 (PDT)
Subject: Has your website : mail-archive.com been penalized by Google ?
Message-ID: <543ebd29.e41e460a.6dbd.ffffe3da@mx.google.com>

   Good Morning Bussiness Owner
   Has your website lost traffic or rankings in last few weeks ? If yes,
   then your website is a VICTIM to these NEW google algorithm updates. To
   correct this you need to hire a professioanl Search Engine Optimization
   company who understands these changes better than what you can. More
   with these new updates coming each month you need your online web
   presence to be taken care by a group of SEO Experts who are dedicated
   to learn all these new changes coming their way.
   We are presently offering a 15 days FREE Trial for our S.E.O Service,
   so that you can experience our expert S.E.O skills and then decided to
   sign up with us. Our S.E.O Plans start from just 199$ and go to 399$ /
   month making sure your website is optimized for all possible keywords
   and not just 10-20 keywords like other companies offer.
   Google has recently launched 3 Big updates and refreshes keep coming
   every month
   1) Google Panda Update : Targeting Websites with Bad ONSITE
   2) Google Penguin : Targeting Websites with Bad backlinks
   3) Google Pigeon : Targeting Websites with bad local presence
   We have helped our clients pass all these algorithms pass these updates
   in last 3 years and we are one of those few ONLY SEO companies who have
   not been affected MUCH by these updates.
   What makes our company different :
   1) We optimize website not keywords : ( We optimize your website for as
   many keywords possible )
   2) We assure results in first 15 days itself
   3) We have the best possible pricing on the web
   4) We abide by all google rules
   5) Every link built is shared with for your future use
   6) We Offer complete SEO Service not just LINK BUILDING
   Email us back with your website and your phone number so we can study
   your website and email you back with our Customized proposal. Looking
   forward working with you.
   Regards
   Vince G
   SEO Manager ( TOB )
   Skype
   ________________________________________
   NO CLICK in the subject to STOP EMAILS

From gabor at zahemszky.hu  Wed Oct 15 20:49:15 2014
From: gabor at zahemszky.hu (gabor at zahemszky.hu)
Date: Wed, 15 Oct 2014 22:33:08 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
Message-ID: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>

Hi!

I borrowed a Vodafone - Huawei K3772 Mobile stick for some days. It's a 
bit disappointing, that I could not use it under FreeBSD.
This 3g modem is made by Huawei (the K3772z is made by ZTE) with 
vendorID: 0x12d1 and productID: 0x1526.

# usbconfig -d 4.3 dump_device_desc
ugen4.3: <Vodafone Mobile Broadband Huawei Vodafone Huawei> at usbus4, 
cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0200
   bDeviceClass = 0x0000
   bDeviceSubClass = 0x0000
   bDeviceProtocol = 0x0000
   bMaxPacketSize0 = 0x0040
   idVendor = 0x12d1
   idProduct = 0x1526
   bcdDevice = 0x0102
   iManufacturer = 0x0002  <Vodafone (Huawei)>
   iProduct = 0x0001  <Vodafone Mobile Broadband (Huawei)>
   iSerialNumber = 0x0000  <no string>
   bNumConfigurations = 0x0001

I tried to switch it to USB-modem mode, but none of the usb_quirks 
worked. And with EJECT_HUAWEI, I got an error, too.

# usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
#

Under Linux, with usb_modeswitch, I could switch it to modem, with the 
MessageContent="55534243123456780000000000000011062000000100000000000000000000"
string, and after it, it will be Vendor=12d1 ProdID=14cf. There are 
some interesting information about this modem in this forum thread:

http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114

Is it possible, to use this modem under FreeBSD? And if yes, how?

Thanks,

Zahemszky, Gabor < Gabor at Zahemszky dot HU >


From hps at selasky.org  Thu Oct 16 06:31:44 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 16 Oct 2014 08:31:43 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
Message-ID: <543F664F.4010003@selasky.org>

Hi,

On 10/15/14 22:33, gabor at zahemszky.hu wrote:
> Hi!
>
> I borrowed a Vodafone - Huawei K3772 Mobile stick for some days. It's a
> bit disappointing, that I could not use it under FreeBSD.
> This 3g modem is made by Huawei (the K3772z is made by ZTE) with
> vendorID: 0x12d1 and productID: 0x1526.
>
> # usbconfig -d 4.3 dump_device_desc
> ugen4.3: <Vodafone Mobile Broadband Huawei Vodafone Huawei> at usbus4,
> cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
>
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0200
>    bDeviceClass = 0x0000
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0040
>    idVendor = 0x12d1
>    idProduct = 0x1526
>    bcdDevice = 0x0102
>    iManufacturer = 0x0002  <Vodafone (Huawei)>
>    iProduct = 0x0001  <Vodafone Mobile Broadband (Huawei)>
>    iSerialNumber = 0x0000  <no string>
>    bNumConfigurations = 0x0001
>
> I tried to switch it to USB-modem mode, but none of the usb_quirks
> worked. And with EJECT_HUAWEI, I got an error, too.
>
> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
> #

Did you load the u3g and usb_quirk modules first?

>
> Under Linux, with usb_modeswitch, I could switch it to modem, with the
> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>
> string, and after it, it will be Vendor=12d1 ProdID=14cf. There are some
> interesting information about this modem in this forum thread:
>
> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
>
> Is it possible, to use this modem under FreeBSD? And if yes, how?
>

Modeswitch is available under FreeBSD too. Check the ports collection. 
Although we prefer putting the quirks into the kernel.

--HPS


From gabor at zahemszky.hu  Thu Oct 16 06:48:12 2014
From: gabor at zahemszky.hu (gabor at zahemszky.hu)
Date: Thu, 16 Oct 2014 08:48:07 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <543F662E.2010801@bitfrost.no>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
Message-ID: <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>

>> I tried to switch it to USB-modem mode, but none of the usb_quirks
>> worked. And with EJECT_HUAWEI, I got an error, too.
>>
>> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
>> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
>> #
>
> Did you load the u3g and usb_quirk modules first?


Yes. My method was:

- first I plugged in the stick.
- Found, that nothing know about it.
- Pulled out
# kldload u3g
- plugged it second time
- nothing
- pulled out
# kldload usb_quirk
# man usb_quirk
- plugged the stick
- tried all of the u3g quirks, found in the manual and in the usbconfig 
dump_quirk_names list
with the command:

usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*

one after the other. Actually I've just found, that there is a 
remove_quirk subcommand, too.
Maybe I need to remove a quirk if it's not the correct one?

>> Under Linux, with usb_modeswitch, I could switch it to modem, with 
>> the
>> 
>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>>
>> string, and after it, it will be Vendor=12d1 ProdID=14cf. There are 
>> some
>> interesting information about this modem in this forum thread:
>>
>> 
>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
>>
>> Is it possible, to use this modem under FreeBSD? And if yes, how?
>>
>
> Modeswitch is available under FreeBSD too. Check the ports


Hm, I didn't know about it, At the evening, I'll try it.


> collection. Although we prefer putting the quirks into the kernel.

Isn't it a good idea to make it possible to add new quirks from 
userspace?

Thanks,

Gabor < Gabor at Zahemszky dot HU >

From hps at bitfrost.no  Thu Oct 16 06:49:09 2014
From: hps at bitfrost.no (Hans Petter Selasky)
Date: Thu, 16 Oct 2014 08:31:10 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
Message-ID: <543F662E.2010801@bitfrost.no>

Hi,

On 10/15/14 22:33, gabor at zahemszky.hu wrote:
> Hi!
>
> I borrowed a Vodafone - Huawei K3772 Mobile stick for some days. It's a
> bit disappointing, that I could not use it under FreeBSD.
> This 3g modem is made by Huawei (the K3772z is made by ZTE) with
> vendorID: 0x12d1 and productID: 0x1526.
>
> # usbconfig -d 4.3 dump_device_desc
> ugen4.3: <Vodafone Mobile Broadband Huawei Vodafone Huawei> at usbus4,
> cfg=255 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
>
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0200
>    bDeviceClass = 0x0000
>    bDeviceSubClass = 0x0000
>    bDeviceProtocol = 0x0000
>    bMaxPacketSize0 = 0x0040
>    idVendor = 0x12d1
>    idProduct = 0x1526
>    bcdDevice = 0x0102
>    iManufacturer = 0x0002  <Vodafone (Huawei)>
>    iProduct = 0x0001  <Vodafone Mobile Broadband (Huawei)>
>    iSerialNumber = 0x0000  <no string>
>    bNumConfigurations = 0x0001
>
> I tried to switch it to USB-modem mode, but none of the usb_quirks
> worked. And with EJECT_HUAWEI, I got an error, too.
>
> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
> #

Did you load the u3g and usb_quirk modules first?

>
> Under Linux, with usb_modeswitch, I could switch it to modem, with the
> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>
> string, and after it, it will be Vendor=12d1 ProdID=14cf. There are some
> interesting information about this modem in this forum thread:
>
> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
>
> Is it possible, to use this modem under FreeBSD? And if yes, how?
>

Modeswitch is available under FreeBSD too. Check the ports collection. 
Although we prefer putting the quirks into the kernel.

--HPS


From hps at selasky.org  Thu Oct 16 07:36:30 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 16 Oct 2014 09:36:31 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
Message-ID: <543F757F.3080008@selasky.org>

On 10/16/14 08:48, gabor at zahemszky.hu wrote:
>>> I tried to switch it to USB-modem mode, but none of the usb_quirks
>>> worked. And with EJECT_HUAWEI, I got an error, too.
>>>
>>> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
>>> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
>>> #
>>
>> Did you load the u3g and usb_quirk modules first?
>
>
> Yes. My method was:
>
> - first I plugged in the stick.
> - Found, that nothing know about it.
> - Pulled out
> # kldload u3g
> - plugged it second time
> - nothing
> - pulled out
> # kldload usb_quirk
> # man usb_quirk
> - plugged the stick
> - tried all of the u3g quirks, found in the manual and in the usbconfig
> dump_quirk_names list
> with the command:
>
> usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*
>
> one after the other. Actually I've just found, that there is a
> remove_quirk subcommand, too.
> Maybe I need to remove a quirk if it's not the correct one?
>
>>> Under Linux, with usb_modeswitch, I could switch it to modem, with the
>>>
>>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>>>
>>>
>>> string, and after it, it will be Vendor=12d1 ProdID=14cf. There are some
>>> interesting information about this modem in this forum thread:
>>>
>>>
>>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
>>>
>>> Is it possible, to use this modem under FreeBSD? And if yes, how?
>>>
>>
>> Modeswitch is available under FreeBSD too. Check the ports
>
>
> Hm, I didn't know about it, At the evening, I'll try it.
>
>
>> collection. Although we prefer putting the quirks into the kernel.
>
> Isn't it a good idea to make it possible to add new quirks from userspace?

Not always, because then the dummy CD-ROMs will enumerate first.

--HPS


From gljennjohn at gmail.com  Thu Oct 16 07:51:17 2014
From: gljennjohn at gmail.com (Gary Jennejohn)
Date: Thu, 16 Oct 2014 09:51:11 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <543F757F.3080008@selasky.org>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
Message-ID: <20141016095111.6201afaf@ernst.home>

On Thu, 16 Oct 2014 09:36:31 +0200
Hans Petter Selasky <hps at selasky.org> wrote:

> On 10/16/14 08:48, gabor at zahemszky.hu wrote:
> >>> I tried to switch it to USB-modem mode, but none of the usb_quirks
> >>> worked. And with EJECT_HUAWEI, I got an error, too.
> >>>
> >>> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
> >>> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
> >>> #
> >>
> >> Did you load the u3g and usb_quirk modules first?
> >
> >
> > Yes. My method was:
> >
> > - first I plugged in the stick.
> > - Found, that nothing know about it.
> > - Pulled out
> > # kldload u3g
> > - plugged it second time
> > - nothing
> > - pulled out
> > # kldload usb_quirk
> > # man usb_quirk
> > - plugged the stick
> > - tried all of the u3g quirks, found in the manual and in the usbconfig
> > dump_quirk_names list
> > with the command:
> >
> > usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*
> >
> > one after the other. Actually I've just found, that there is a
> > remove_quirk subcommand, too.
> > Maybe I need to remove a quirk if it's not the correct one?
> >
> >>> Under Linux, with usb_modeswitch, I could switch it to modem, with the
> >>>
> >>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
> >>>
> >>>
> >>> string, and after it, it will be Vendor=12d1 ProdID=14cf. There are some
> >>> interesting information about this modem in this forum thread:
> >>>
> >>>
> >>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
> >>>
> >>> Is it possible, to use this modem under FreeBSD? And if yes, how?
> >>>
> >>
> >> Modeswitch is available under FreeBSD too. Check the ports
> >
> >
> > Hm, I didn't know about it, At the evening, I'll try it.
> >
> >
> >> collection. Although we prefer putting the quirks into the kernel.
> >
> > Isn't it a good idea to make it possible to add new quirks from userspace?
> 
> Not always, because then the dummy CD-ROMs will enumerate first.
> 

Yeah, but according to usb_quirk(4) that's exactly what that module
is supposed to make possible.

-- 
Gary Jennejohn

From gabor at zahemszky.hu  Thu Oct 16 08:09:16 2014
From: gabor at zahemszky.hu (gabor at zahemszky.hu)
Date: Thu, 16 Oct 2014 09:50:41 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <543F757F.3080008@selasky.org>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
Message-ID: <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>

2014-10-16 09:36 id?pontban Hans Petter Selasky ezt ?rta:
> On 10/16/14 08:48, gabor at zahemszky.hu wrote:
>>>> I tried to switch it to USB-modem mode, but none of the usb_quirks
>>>> worked. And with EJECT_HUAWEI, I got an error, too.
>>>>
>>>> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
>>>> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
>>>> #
>>>
>>> Did you load the u3g and usb_quirk modules first?
>>
>>
>> Yes. My method was:
>>
>> - first I plugged in the stick.
>> - Found, that nothing know about it.
>> - Pulled out
>> # kldload u3g
>> - plugged it second time
>> - nothing
>> - pulled out
>> # kldload usb_quirk
>> # man usb_quirk
>> - plugged the stick
>> - tried all of the u3g quirks, found in the manual and in the 
>> usbconfig
>> dump_quirk_names list
>> with the command:
>>
>> usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*
>>
>> one after the other. Actually I've just found, that there is a
>> remove_quirk subcommand, too.
>> Maybe I need to remove a quirk if it's not the correct one?
>>
>>>> Under Linux, with usb_modeswitch, I could switch it to modem, with 
>>>> the
>>>>
>>>> 
>>>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>>>>
>>>>
>>>> string, and after it, it will be Vendor=12d1 ProdID=14cf. There 
>>>> are some
>>>> interesting information about this modem in this forum thread:
>>>>
>>>>
>>>> 
>>>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
>>>>
>>>> Is it possible, to use this modem under FreeBSD? And if yes, how?
>>>>
>>>
>>> Modeswitch is available under FreeBSD too. Check the ports
>>
>>
>> Hm, I didn't know about it, At the evening, I'll try it.
>>
>>
>>> collection. Although we prefer putting the quirks into the kernel.
>>
>> Isn't it a good idea to make it possible to add new quirks from 
>> userspace?
>
> Not always, because then the dummy CD-ROMs will enumerate first.
>
> --HPS


Hi, I think you misunderstood my comment. I think that we need some 
trick:

- to tell the u3g driver to use a new quirk (UQ_MSC_NEW) ; that the 
hardware
with VendorID X and ProductID Y *will* need to switch with the next 
message:
ABC - where X and Y are known IDs, ABC is a known message, but ABC is 
not a
defined quirk in the  usb_quirk driver.

So I can tell the system, that the unknown K3772 modem - VendorID=12d1 
and
ProductID=12d1 - needs that message (borrowed from usb_modeswitch 
database)
"55534243123456780000000000000011062000000100000000000000000000"

- to tell the u3g driver, that a HW *will* arrive vith VID X PID Y, and
needs the quirk UQ_MSC_NEW

Thanks,

Gabor < Gabor at Zahemszky dot HU >

From hps at selasky.org  Thu Oct 16 08:18:40 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 16 Oct 2014 10:18:39 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
Message-ID: <543F7F5F.5070102@selasky.org>

On 10/16/14 09:50, gabor at zahemszky.hu wrote:
> 2014-10-16 09:36 id?pontban Hans Petter Selasky ezt ?rta:
>> On 10/16/14 08:48, gabor at zahemszky.hu wrote:
>>>>> I tried to switch it to USB-modem mode, but none of the usb_quirks
>>>>> worked. And with EJECT_HUAWEI, I got an error, too.
>>>>>
>>>>> # usbconfig -d ugen4.3 add_quirk UQ_MSC_EJECT_HUAWEI
>>>>> Adding quirk 'UQ_MSC_EJECT_HUAWEI' failed, continuing.
>>>>> #
>>>>
>>>> Did you load the u3g and usb_quirk modules first?
>>>
>>>
>>> Yes. My method was:
>>>
>>> - first I plugged in the stick.
>>> - Found, that nothing know about it.
>>> - Pulled out
>>> # kldload u3g
>>> - plugged it second time
>>> - nothing
>>> - pulled out
>>> # kldload usb_quirk
>>> # man usb_quirk
>>> - plugged the stick
>>> - tried all of the u3g quirks, found in the manual and in the usbconfig
>>> dump_quirk_names list
>>> with the command:
>>>
>>> usbconfig -d useg4.3 add_quirk UQ_MSC_EJECT_*
>>>
>>> one after the other. Actually I've just found, that there is a
>>> remove_quirk subcommand, too.
>>> Maybe I need to remove a quirk if it's not the correct one?
>>>
>>>>> Under Linux, with usb_modeswitch, I could switch it to modem, with the
>>>>>
>>>>>
>>>>> MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>>>>>
>>>>>
>>>>>
>>>>> string, and after it, it will be Vendor=12d1 ProdID=14cf. There are
>>>>> some
>>>>> interesting information about this modem in this forum thread:
>>>>>
>>>>>
>>>>>
>>>>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=1114
>>>>>
>>>>> Is it possible, to use this modem under FreeBSD? And if yes, how?
>>>>>
>>>>
>>>> Modeswitch is available under FreeBSD too. Check the ports
>>>
>>>
>>> Hm, I didn't know about it, At the evening, I'll try it.
>>>
>>>
>>>> collection. Although we prefer putting the quirks into the kernel.
>>>
>>> Isn't it a good idea to make it possible to add new quirks from
>>> userspace?
>>
>> Not always, because then the dummy CD-ROMs will enumerate first.
>>
>> --HPS
>
>
> Hi, I think you misunderstood my comment. I think that we need some trick:
>
> - to tell the u3g driver to use a new quirk (UQ_MSC_NEW) ; that the
> hardware
> with VendorID X and ProductID Y *will* need to switch with the next
> message:
> ABC - where X and Y are known IDs, ABC is a known message, but ABC is not a
> defined quirk in the  usb_quirk driver.
>
> So I can tell the system, that the unknown K3772 modem - VendorID=12d1 and
> ProductID=12d1 - needs that message (borrowed from usb_modeswitch database)
> "55534243123456780000000000000011062000000100000000000000000000"
>

Hi,

This quirk already exists.

Can you try:

kldunload usb_quirk
kldload usb_quirk
usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2

Then re-plug your device?

--HPS



From gabor at zahemszky.hu  Thu Oct 16 08:47:43 2014
From: gabor at zahemszky.hu (gabor at zahemszky.hu)
Date: Thu, 16 Oct 2014 10:47:39 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <543F7F5F.5070102@selasky.org>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
 <543F7F5F.5070102@selasky.org>
Message-ID: <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu>

>> So I can tell the system, that the unknown K3772 modem - 
>> VendorID=12d1 and
>> ProductID=12d1 - needs that message (borrowed from usb_modeswitch 
>> database)
>> "55534243123456780000000000000011062000000100000000000000000000"
>>
>
> Hi,
>
> This quirk already exists.
>
> Can you try:
>
> kldunload usb_quirk
> kldload usb_quirk
> usbconfig -d X.Y add_quirk UQ_MSC_EJECT_HUAWEISCSI2
>
> Then re-plug your device?

Hi,

actually I can only try it in a VirtualBOX VM. This machine
has 10.1-RC2. But I had two problems:

- something wrong is with the usb_quirk module:
# kldunload usb_quirk
kldunload: can't find file usb_quirk
# kldload usb_quirk
kldload: can't load usb_quirk: module already loaded or in kernel
# kldstat -v | fgrep quirk # ( generates nothing )

- By the way, neither man usb_quirks, nor usbconfig dump_quirk_names 
hasn't got
that UQ_MSC_EJECT_HUAWEISCSI2 name. And it's missing from the C-header 
file
/sys/dev/usb/quirk/usb_quirk.h, too. (Only EJECT_HUAWEI and 
EJECT_HUAWEISCSI exists.)

At the evening, I'll try this command on a real machine, with 10.0-p9, 
but I didn't
remember other HUAWEI quirks, that the two above.

(And my last question: are there any more detailed documentation about 
usbconfig,
than the manual? Actually I don't know what the different commands do, 
eg. maybe
with the add_dev_quirk_vplh, or do_request subcommands, I can create 
new quirks.)

Thanks,

Gabor < Gabor at Zahemszky dot HU >

From hps at selasky.org  Thu Oct 16 08:58:31 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 16 Oct 2014 10:58:30 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
 <543F7F5F.5070102@selasky.org>
 <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu>
Message-ID: <543F88B6.904@selasky.org>

Hi,

You need to run 11-curent, the quirk is not in 10-branch yet.

The following patch for 11-current should fix your device.

Hint: You can boot a 11-current kernel with 10-xxx userland!

Can you test the attached patch on 11-current, and report back?

--HPS

From bugzilla-noreply at freebsd.org  Thu Oct 16 22:54:01 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 16 Oct 2014 22:54:01 +0000
Subject: [Bug 188119] [ukbd] problems with multiple keyboards
In-Reply-To: <bug-188119-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-188119-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-188119-17-5jQM6ulJd5@https.bugs.freebsd.org/bugzilla/>

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

Gavin Atkinson <gavin at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Affects Only Me             |Affects Some People

-- 
You are receiving this mail because:
You are the assignee for the bug.

From gabor at zahemszky.hu  Fri Oct 17 09:27:00 2014
From: gabor at zahemszky.hu (gabor at zahemszky.hu)
Date: Fri, 17 Oct 2014 11:26:50 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <543F88B6.904@selasky.org>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
 <543F7F5F.5070102@selasky.org>
 <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu> <543F88B6.904@selasky.org>
Message-ID: <9bb5ca363a4e17e9f41b50b748316cdf@zahemszky.hu>

2014-10-16 10:58 id?pontban Hans Petter Selasky ezt ?rta:
> Hi,
>
> You need to run 11-curent, the quirk is not in 10-branch yet.
>
> The following patch for 11-current should fix your device.
>
> Hint: You can boot a 11-current kernel with 10-xxx userland!
>
> Can you test the attached patch on 11-current, and report back?

OK. I've upgraded to 11-CURRENT, patched in the ID-s.
Kldloaded the u3g module (and cannot load the usb_quirk module)
Here is the demsg output after plugging in the stick:

ugen0.2: <Vodafone Huawei> at usbus0
cdce0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 0/0, 
rev 1.10/1.01, addr 2> on usbus0
cdce0: faking MAC address
umass0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 0/0, 
rev 1.10/1.01, addr 2> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0000
ue0: <USB Ethernet> on cdce0
ue0: Ethernet address: 2a:35:81:05:00:00
umass0:2:0: Attached to scbus2
cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
cd1: <Vodafone CD ROM (Huawei) 2.31> Removable CD-ROM SCSI-2 device
cd1: 1.000MB/s transfers
cd1: cd present [65536 x 2048 byte records]
cd1: quirks=0x10<10YTE_ONLY>

Thanks,

Gabor < Gabor at Zahemszky dot HU >


From hps at selasky.org  Fri Oct 17 09:41:41 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Fri, 17 Oct 2014 11:41:41 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <9bb5ca363a4e17e9f41b50b748316cdf@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
 <543F7F5F.5070102@selasky.org>
 <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu> <543F88B6.904@selasky.org>
 <9bb5ca363a4e17e9f41b50b748316cdf@zahemszky.hu>
Message-ID: <5440E455.8030003@selasky.org>

On 10/17/14 11:26, gabor at zahemszky.hu wrote:
> 2014-10-16 10:58 id?pontban Hans Petter Selasky ezt ?rta:
>> Hi,
>>
>> You need to run 11-curent, the quirk is not in 10-branch yet.
>>
>> The following patch for 11-current should fix your device.
>>
>> Hint: You can boot a 11-current kernel with 10-xxx userland!
>>
>> Can you test the attached patch on 11-current, and report back?
>
> OK. I've upgraded to 11-CURRENT, patched in the ID-s.
> Kldloaded the u3g module (and cannot load the usb_quirk module)
> Here is the demsg output after plugging in the stick:
>
> ugen0.2: <Vodafone Huawei> at usbus0
> cdce0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 0/0, rev
> 1.10/1.01, addr 2> on usbus0
> cdce0: faking MAC address
> umass0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 0/0,
> rev 1.10/1.01, addr 2> on usbus0
> umass0: SCSI over Bulk-Only; quirks = 0x0000
> ue0: <USB Ethernet> on cdce0
> ue0: Ethernet address: 2a:35:81:05:00:00
> umass0:2:0: Attached to scbus2
> cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
> cd1: <Vodafone CD ROM (Huawei) 2.31> Removable CD-ROM SCSI-2 device
> cd1: 1.000MB/s transfers
> cd1: cd present [65536 x 2048 byte records]
> cd1: quirks=0x10<10YTE_ONLY>
>
> Thanks,
>
> Gabor < Gabor at Zahemszky dot HU >
>
>

Hi,

Can you show the output from "usbconfig -d X.Y dump_device_desc"?

We need to add the non-autoinstall disk ID to u3g aswell.

Thank you!

--HPS

From bugzilla-noreply at freebsd.org  Fri Oct 17 10:41:18 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 10:41:17 +0000
Subject: [Bug 156596] [ehci] Extremely high interrupt rate on ehci/uhci IRQ16
 80% cpu utilization on CPU0
In-Reply-To: <bug-156596-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-156596-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-156596-17-VqCJYwQchp@https.bugs.freebsd.org/bugzilla/>

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

proler at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |proler at gmail.com

--- Comment #13 from proler at gmail.com ---
Confirmed on Intel DH77KC, H77
FreeBSD 10.0-RELEASE

Problem starts when detaching-attaching hdmi cable

-- 
You are receiving this mail because:
You are the assignee for the bug.

From gabor at zahemszky.hu  Fri Oct 17 13:07:24 2014
From: gabor at zahemszky.hu (gabor at zahemszky.hu)
Date: Fri, 17 Oct 2014 15:07:14 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <5441007B.9090203@selasky.org>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
 <543F7F5F.5070102@selasky.org>
 <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu> <543F88B6.904@selasky.org>
 <9bb5ca363a4e17e9f41b50b748316cdf@zahemszky.hu>
 <5440E455.8030003@selasky.org>
 <e8fcff2367f06943de45e558766dba36@zahemszky.hu>
 <5441007B.9090203@selasky.org>
Message-ID: <cb3b66f667589b60bd3c56319d784eac@zahemszky.hu>

>>>> OK. I've upgraded to 11-CURRENT, patched in the ID-s.
>>>> Kldloaded the u3g module (and cannot load the usb_quirk module)
>>>> Here is the demsg output after plugging in the stick:
>>>>
>>>> ugen0.2: <Vodafone Huawei> at usbus0
>>>> cdce0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 
>>>> 0/0, rev
>>>> 1.10/1.01, addr 2> on usbus0
>>>> cdce0: faking MAC address
>>>> umass0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 
>>>> 0/0,
>>>> rev 1.10/1.01, addr 2> on usbus0
>>>> umass0: SCSI over Bulk-Only; quirks = 0x0000
>>>> ue0: <USB Ethernet> on cdce0
>>>> ue0: Ethernet address: 2a:35:81:05:00:00
>>>> umass0:2:0: Attached to scbus2
>>>> cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
>>>> cd1: <Vodafone CD ROM (Huawei) 2.31> Removable CD-ROM SCSI-2 
>>>> device
>>>> cd1: 1.000MB/s transfers
>>>> cd1: cd present [65536 x 2048 byte records]
>>>> cd1: quirks=0x10<10YTE_ONLY>
>>>>
>>>> Thanks,
>>>>
>>>> Gabor < Gabor at Zahemszky dot HU >
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> Can you show the output from "usbconfig -d X.Y dump_device_desc"?
>>>
>>> We need to add the non-autoinstall disk ID to u3g aswell.
>>>
>>> Thank you!
>>
>> Hi!
>>
>> The original ID is: 12d1:1526
>> The switched ID is: 12d1:14cf
>>
>> The dump:
>>
>> # usbconfig -d 0.2 dump_device_desc
>> ugen0.2: <Vodafone Mobile Broadband Huawei Vodafone Huawei> at 
>> usbus0,
>> cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
>>
>>   bLength = 0x0012
>>   bDescriptorType = 0x0001
>>   bcdUSB = 0x0110
>>   bDEviceClass = 0x0000
>>   bDeviceSubClass = 0x0000
>>   bDeviceProtocol = 0x00
>>   bMaxPacketSize0 = 0x0040
>>   idVendor = 0x12d1
>>   idProduct = 0x14cf
>>   bcdDevice = 0x0102
>>   iManufacturer = 0x0003 <Vodafone (Huawei)>
>>   iProduct = 0x0002 <Vodafone Mobile broadband (Huawei)>
>>   iSerialNumber = 0x0000  <no string>
>>   bNumConfigurations = 0x0001
>>
>> ====
>>
>> I have another question. Both ucom and u3g modules loaded, but I 
>> cannot
>> find /dev/ttyU* or /dev/cuaU* devices. What's missing?
>>
>> Bye,
>>
>> Gabor < Gabor at Zahemszky dot HU >
>>
>
> Can you test the attached patch. Revert the previous ones.
>
> cd sys/dev/usb/
> cat u3g.diff | patch
>
> compile new kernel and reboot.
>
> --HPS

Hi!

OK, updated. Now:

dmesg:

===

ugen0.2: <Vodafone huawei> at usbus0
ugen0.2: <Vodafone huawei> at usbus0 (disconnected)
ugen0.2: <Vodafone huawei> at usbus0
u3g0: <Vodafone Huawei Vodafone Mobile Broadband Huawei, class 0/0, rev 
1.10/1.02, addr2> on usbus0
u3g0: Found 3 ports.
umass0: SCSI over Bulk-Only; quirks = 0x0000
umass0:2:0: Attached to scbus0
cd1 at umass-sim0 bus 0 scbus2 target 0 lun 0
cd1: <Vodafone CD ROM (Huawei) 2.31> Removable CD-ROM SCSI-2 device
cd1: 1.000MB/s transfers
cd1: cd present [65536 x 2048 byte records]
cd1: quirks=0x10<10YTE_ONLY>

===
So, I've lost the cdc0 and ue0 devices, but got the u3g0 device. And we 
have three /dev/ttyU* and /dev/cucU* devices (and the .init and .lock 
devices to all of them).

And of course, I can connect to the device:
# cu -s 115200 -l /dev/cuaU0.0
Connected
atz
OK
ati
Manufacturer: Vodafone (Huawei)
Model: K3772
Revision: 21.157.40.00.11
IMEI: xxx
+GCAP: +CGSM,+DS,+ES

OK

Thanks,

Gabor < Gabor at Zahemszky dot HU >

From hps at selasky.org  Fri Oct 17 13:42:09 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Fri, 17 Oct 2014 15:42:08 +0200
Subject: u3g and Vodafone k3772 (not k3772z)
In-Reply-To: <cb3b66f667589b60bd3c56319d784eac@zahemszky.hu>
References: <c5c1344ad4a64cd91e769a0e0fd750aa@zahemszky.hu>
 <543F662E.2010801@bitfrost.no>
 <b02117a6904277a0a674ef618f8b98b0@zahemszky.hu>
 <543F757F.3080008@selasky.org>
 <32bbfea82744ca84ffa31c27917f3013@zahemszky.hu>
 <543F7F5F.5070102@selasky.org>
 <09454923d8518e4f1e2e7aab64e499ba@zahemszky.hu> <543F88B6.904@selasky.org>
 <9bb5ca363a4e17e9f41b50b748316cdf@zahemszky.hu>
 <5440E455.8030003@selasky.org>
 <e8fcff2367f06943de45e558766dba36@zahemszky.hu>
 <5441007B.9090203@selasky.org>
 <cb3b66f667589b60bd3c56319d784eac@zahemszky.hu>
Message-ID: <54411CB0.7090109@selasky.org>

> ===
> So, I've lost the cdc0 and ue0 devices, but got the u3g0 device. And we
> have three /dev/ttyU* and /dev/cucU* devices (and the .init and .lock
> devices to all of them).
>
> And of course, I can connect to the device:
> # cu -s 115200 -l /dev/cuaU0.0
> Connected
> atz
> OK
> ati
> Manufacturer: Vodafone (Huawei)
> Model: K3772
> Revision: 21.157.40.00.11
> IMEI: xxx
> +GCAP: +CGSM,+DS,+ES
>
> OK

Hi,

Here is the final patch:

https://svnweb.freebsd.org/changeset/base/273216

--HPS


From bugzilla-noreply at freebsd.org  Fri Oct 17 23:29:23 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 17 Oct 2014 23:29:21 +0000
Subject: [Bug 179376] xhci ehci irq storm
In-Reply-To: <bug-179376-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-179376-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-179376-17-d5FFKLO6qv@https.bugs.freebsd.org/bugzilla/>

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

Mark Linimon <linimon at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|amd64                       |usb
           Assignee|freebsd-amd64 at FreeBSD.org   |freebsd-usb at FreeBSD.org

--- Comment #7 from Mark Linimon <linimon at FreeBSD.org> ---
Reassign.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From dewayne.geraghty at heuristicsystems.com.au  Wed Oct 22 01:29:57 2014
From: dewayne.geraghty at heuristicsystems.com.au (Dewayne Geraghty)
Date: Wed, 22 Oct 2014 12:09:57 +1100
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob
 Lell
In-Reply-To: <54369F43.9010806@selasky.org>
References: <201410082347.s98NkjW3025396@fire.js.berklix.net>	<54362AE2.90501@selasky.org>
 <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>
 <54369F43.9010806@selasky.org>
Message-ID: <544703E5.7000007@heuristicsystems.com.au>


On 10/10/2014 1:44 AM, Hans Petter Selasky wrote:
> On 10/09/14 15:59, Oliver Pinter wrote:
>> On 10/9/14, Hans Petter Selasky <hps at selasky.org> wrote:
>>> Hi Julian,
>>>
>>> On 10/09/14 01:46, Julian H. Stacey wrote:
>>>> Hi Hans etc
>>>> "Julian H. Stacey" wrote:
>>>>> Hans Petter Selasky wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Can you test the following kernel patch and give some feedback:
>>>>>>
>>>>>> https://svnweb.freebsd.org/changeset/base/272733
>>>>
>>>> I'm now on latest current with src & sys/ GENERIC
>>>> /usr/src/.ctm_status    # src-cur 11645
>>>>
>>>> This time I downloaded your files properly
>>>> (last time I was severely distracted & made a silly mistake)
>>>>
>>>>>> After the patch you will get something like:
>>>>>> hw.usb.disable_enumeration: 0
>>>>>> dev.uhub.0.disable_enumeration: 0
>>>>>> dev.uhub.1.disable_enumeration: 0
>>>>>> ...
>>>>
>>>> sysctl -a | grep  enumeration
>>>>     hw.usb.disable_enumeration: 0
>>>>     dev.uhub.0.disable_enumeration: 0
>>>>     dev.uhub.1.disable_enumeration: 0
>>>>     dev.uhub.2.disable_enumeration: 0
>>>>     dev.uhub.3.disable_enumeration: 0
>>>>     dev.uhub.4.disable_enumeration: 0
>>>>
>>>> sysctl -d hw.usb.disable_enumeration
>>>>     hw.usb.disable_enumeration: Set to disable all USB device
>>>> enumeration.
>>>>
>>>> sysctl -d dev.uhub.4.disable_enumeration
>>>>     dev.uhub.4.disable_enumeration: Set to disable enumeration on
>>>> this USB
>>>> HUB.
>>>>
>>>> usbconfig
>>>> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH
>>>> (480Mbps)
>>>> pwr=SAVE (0mA)
>>>> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH
>>>> (480Mbps)
>>>> pwr=SAVE (0mA)
>>>> ugen0.2: <product 0x0020 vendor 0x8087> at usbus0, cfg=0 md=HOST
>>>> spd=HIGH
>>>> (480Mbps) pwr=SAVE (0mA)
>>>> ugen1.2: <product 0x0020 vendor 0x8087> at usbus1, cfg=0 md=HOST
>>>> spd=HIGH
>>>> (480Mbps) pwr=SAVE (0mA)
>>>> ugen0.3: <1.3M WebCam XPA2535XY> at usbus0, cfg=255 md=HOST spd=HIGH
>>>> (480Mbps) pwr=OFF (500mA)
>>>> ugen1.3: <Semi Tech PS2 Keyboard - PS2 Mouse Semi Tech> at usbus1,
>>>> cfg=0
>>>> md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
>>>> ugen1.4: <USB2.0 Hub vendor 0x05e3> at usbus1, cfg=0 md=HOST spd=HIGH
>>>> (480Mbps) pwr=SAVE (100mA)
>>>>
>>>
>>>>
>>>> Great ! Seems to work.
>>>>
>>>> (Though I need to read up on how major & minor of ugen relate to
>>>> the digit in eg 4.disable_enumeration)
>>>>
>>>>
>>>>>> which is also settable through /boot/loader.conf (tunable)
>>>>
>>>> Good,
>>>> I hope/presume loader.conf gets run before any USB, cos I recall
>>>> lecturer Karsten Nohl pointing out one could get BadUSB taking up
>>>> residence in USB controller chips inside a PC, ie for a built in
>>>> mouse or web cam, so one would need to turn off enumeration earlier
>>>> than when first external USB approaches to connect.
>>>
>>> Yes, if set by the loader.conf, you will only see the RootHUB after
>>> boot.
>>>
>>> To get devices back after enabling enumeration again, you will need to
>>> reset the HUBs:
>>>
>>> usbconfig -d X.1 reset
>>>
>>> For example.
>>>
>>> BTW: I've added some exceptions, that existing devices can be detached,
>>> suspend/resumed and reset while the enumeration is disabled.
>>
>> Can we somehow improve this change, to powering down the ports/hubs
>> which has the enumeration disabled?
>>
>
> Hi,
>
> I've added this as an orthogonal feature. Please test and report back:
>
> hw.usb.disable_enumeration: 0
> hw.usb.disable_port_power: 0
>
> dev.uhub.0.disable_enumeration: 0
> dev.uhub.0.disable_port_power: 0
>
> https://svnweb.freebsd.org/changeset/base/272822
>
> Thank you!
>
> --HPS
>
> _______________________________________________
> freebsd-usb at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
> To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
>
Hans,
Thank-you for these enhancements, as its good to have something in the
armoury to try to address this issue.

I applied the patch
https://lists.freebsd.org/pipermail/svn-src-head/2014-October/063443.html to
an updated 10.Stable overnight.  Disabling enumeration works as
described above except that, placing the following in loader.conf has no
effect? 
--- tail of /boot/loader.conf ---
# 20141022 Didn't work as expected
#dev.uhub.0.disable_enumeration="1"
#dev.uhub.1.disable_enumeration="1"
#dev.uhub.2.disable_enumeration="1"
#dev.uhub.3.disable_enumeration="1"
#dev.uhub.4.disable_enumeration="1"

# 20141022 Also didn't work
hw.usb.disable_enumeration="1"
--- end of /boot/loader.conf ---

I confirmed the setting was correctly read by loader, by interrupting
the boot and showing the variables.

But immediately after booting,
sysctl -a|grep enumer
hw.usb.disable_enumeration: 0
dev.uhub.0.disable_enumeration: 0
dev.uhub.1.disable_enumeration: 0
dev.uhub.2.disable_enumeration: 0
dev.uhub.3.disable_enumeration: 0
dev.uhub.4.disable_enumeration: 0

Any ideas why loader.conf settings weren't applied?  They are applied
via /etc/sysctl.conf, but by that stage, any harm has been done.

It was interesting doing "user testing" (ie dumb things).  Having a
mouse in hub-unit.endpoint=0.2
sysctl dev.uhub.0.disable_enumeration=1
usbconfig -d 0.2 power_off
provides an opportunity to make a fresh cup of tea...  ;)

Regards, Dewayne.

-- 
For the talkers: ?The superior man acts before he speaks, and afterwards speaks according to his action.?
For everyone else: ?Life is really simple, but we insist on making it complicated.?


From hps at selasky.org  Wed Oct 22 06:19:53 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 22 Oct 2014 08:19:55 +0200
Subject: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob
 Lell
In-Reply-To: <544703E5.7000007@heuristicsystems.com.au>
References: <201410082347.s98NkjW3025396@fire.js.berklix.net>	<54362AE2.90501@selasky.org>
 <CAPjTQNHbh40oeeuJnCk+iiKLOFO9TJU0Z13uRp6FawuUrmHvnw@mail.gmail.com>
 <54369F43.9010806@selasky.org> <544703E5.7000007@heuristicsystems.com.au>
Message-ID: <54474C8B.5020000@selasky.org>

On 10/22/14 03:09, Dewayne Geraghty wrote:
> Hans,
> Thank-you for these enhancements, as its good to have something in the
> armoury to try to address this issue.
>
> I applied the patch
> https://lists.freebsd.org/pipermail/svn-src-head/2014-October/063443.html  to
> an updated 10.Stable overnight.  Disabling enumeration works as
> described above except that, placing the following in loader.conf has no
> effect?
> --- tail of /boot/loader.conf ---
> # 20141022 Didn't work as expected
> #dev.uhub.0.disable_enumeration="1"
> #dev.uhub.1.disable_enumeration="1"
> #dev.uhub.2.disable_enumeration="1"
> #dev.uhub.3.disable_enumeration="1"
> #dev.uhub.4.disable_enumeration="1"
>
> # 20141022 Also didn't work
> hw.usb.disable_enumeration="1"
> --- end of /boot/loader.conf ---

Hi,

The /boot/loader.conf only works in -current, because in 10-stable 
SYSCTLs cannot be automatically loaded from TUNABLEs. You would need to 
add some TUNABLE() statements for that.

--HPS

From bugzilla-noreply at freebsd.org  Mon Oct 27 15:07:53 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 27 Oct 2014 15:07:53 +0000
Subject: [Bug 194633] New: FreeBSD 10.1-RC3 can't detect all available USB
 devices
Message-ID: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 194633
           Summary: FreeBSD 10.1-RC3 can't detect all available USB
                    devices
           Product: Base System
           Version: 10.1-RC2
          Hardware: i386
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: usb
          Assignee: freebsd-usb at FreeBSD.org
          Reporter: rff1917 at yahoo.com

The device is a portable MP3 player.

On FreeBSD 9.1, its internal memory is detected as da0 and the micro-SD card
extension is detected as da1. Both can be mounted read-write without any issue.

On FreeBSD 10.1-RC3, only the internal memory is detected and can be mounted.
No da1 is visible in /dev.


Following is the output of /var/log/messages on both systems:

ON 10.1-RC3
===========

Oct 27 16:17:55 pc1 kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
Oct 27 16:17:55 pc1 kernel: da0: <Intenso VideoShooter 0100> Removable Direct
Access SCSI-0 device 
Oct 27 16:17:55 pc1 kernel: da0: Serial Number K
Oct 27 16:17:55 pc1 kernel: da0: 40.000MB/s transfers
Oct 27 16:17:55 pc1 kernel: da0: 3748MB (7675904 512 byte sectors: 255H 63S/T
477C)
Oct 27 16:17:55 pc1 kernel: da0: quirks=0x2<NO_6_BYTE>

Oct 27 16:17:55 pc1 kernel: da1 at umass-sim0 bus 0 scbus2 target 0 lun 1
Oct 27 16:17:55 pc1 kernel: da1: <Intenso VideoShooter 0100> Removable Direct
Access SCSI-0 device 
Oct 27 16:17:55 pc1 kernel: da1: Serial Number K
Oct 27 16:17:55 pc1 kernel: da1: 40.000MB/s transfers
Oct 27 16:17:55 pc1 kernel: da1: 30335MB (62126080 512 byte sectors: 255H 63S/T
3867C)
Oct 27 16:17:55 pc1 kernel: da1: quirks=0x2<NO_6_BYTE>

Oct 27 16:17:55 pc1 kernel: da1 at umass-sim0 bus 0 scbus2 target 0 lun 1
Oct 27 16:17:55 pc1 kernel: da1: <Intenso VideoShooter 0100> s/n K detached
Oct 27 16:17:55 pc1 kernel: (da1:umass-sim0:0:0:1): Periph destroyed

WHEN POWERING OFF THE DEVICE

Oct 27 16:21:46 pc1 kernel: ugen3.2: <Actions> at usbus3 (disconnected)
Oct 27 16:21:46 pc1 kernel: umass0: at uhub3, port 3, addr 2 (disconnected)
Oct 27 16:21:46 pc1 kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
Oct 27 16:21:46 pc1 kernel: da0: <Intenso VideoShooter 0100> s/n K detached
Oct 27 16:21:46 pc1 kernel: (da0:umass-sim0:0:0:0): Periph destroyed


ON 9.1
======

Oct 27 16:30:48 pc1 kernel: ugen3.2: <Actions> at usbus3
Oct 27 16:30:48 pc1 kernel: umass0: <Mass Storage> on usbus3
Oct 27 16:30:48 pc1 kernel: umass0:  8070i (ATAPI) over Bulk-Only; quirks =
0x0000
Oct 27 16:30:48 pc1 kernel: umass0:2:0:-1: Attached to scbus2

Oct 27 16:30:48 pc1 kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
Oct 27 16:30:48 pc1 kernel: da0: <Intenso VideoShooter 0100> Removable Direct
Access SCSI-0 device 
Oct 27 16:30:48 pc1 kernel: da0: 40.000MB/s transfers
Oct 27 16:30:48 pc1 kernel: da0: 3748MB (7675904 512 byte sectors: 255H 63S/T
477C)

Oct 27 16:30:48 pc1 kernel: da1 at umass-sim0 bus 0 scbus2 target 0 lun 1
Oct 27 16:30:48 pc1 kernel: da1: <Intenso VideoShooter 0100> Removable Direct
Access SCSI-0 device 
Oct 27 16:30:48 pc1 kernel: da1: 40.000MB/s transfers
Oct 27 16:30:48 pc1 kernel: da1: 30335MB (62126080 512 byte sectors: 255H 63S/T
3867C)

WHEN POWERING OFF THE DEVICE

Oct 27 16:32:18 pc1 kernel: ugen3.2: <Actions> at usbus3 (disconnected)
Oct 27 16:32:18 pc1 kernel: umass0: at uhub3, port 3, addr 2 (disconnected)
Oct 27 16:32:18 pc1 kernel: (da0:umass-sim0:0:0:0): lost device - 0
outstanding, 1 refs
Oct 27 16:32:18 pc1 kernel: (da1:umass-sim0:0:0:1): lost device - 0
outstanding, 1 refs
Oct 27 16:32:18 pc1 kernel: (pass2:umass-sim0:0:0:0): passdevgonecb: devfs
entry is gone
Oct 27 16:32:18 pc1 kernel: (pass3:umass-sim0:0:0:1): passdevgonecb: devfs
entry is gone
Oct 27 16:32:18 pc1 kernel: (da1:umass-sim0:0:0:1): removing device entry
Oct 27 16:32:18 pc1 kernel: (da0:umass-sim0:0:0:0): removing device entry

-- 
You are receiving this mail because:
You are the assignee for the bug.

From nedmath at gmail.com  Tue Oct 28 03:03:15 2014
From: nedmath at gmail.com (Nidal Khalil)
Date: Mon, 27 Oct 2014 20:03:13 -0700
Subject: USB stack driver options for the receive side question
Message-ID: <CADoY-6if1KiLvQWTM89JL0GFOcmOUx7Gqg+9VVLEdaVyU-t58A@mail.gmail.com>

Hello All,
I am setting up usb to transfer 3 frames on the bulk read descriptor but
all I get is one frame transferred? Basically aframe = 1

However if I use .short_frames_ok = 1, then the transfer will pend till the
three frames are received. This code is part of a network driver
I would like to receive the one buffer it is the only one available and at
most three buffers at a time if the transfer is complete.
The one frame a time to respond to ping and three frame at time when the
transfer load is heavy.

Is this a limitation of FreeBSD.
I searched all the drivers in the 9.3 release and I can not find a driver
that is setup to receive multiple buffers?

Below is my sample code:

BWL_BULK_RD] = {

                .type      = UE_BULK,

                .endpoint  = UE_ADDR_ANY,

                .direction = UE_DIR_IN,

                .bufsize   = 2000 * HW_IN_PENDING_FRAMES,

                .flags     = {

                        .pipe_bof = 1, .short_xfer_ok = 1, .ext_buffer = 1

                },

                .callback  = dbus_usbos_recv_callback,

                .timeout   = 0,        /* no timeout */

                .frames    = HW_IN_PENDING_FRAMES

        },





static void

dbus_usbos_recv_callback(CALLBACK_ARGS)

{

        usbos_info_t *usbos_info = usbd_xfer_softc(xfer);

        struct bwl_rx_data *data;

        int actlen, sumlen, aframes, nframes, datalen, nr_frames;

        uint8 *buf;

        struct timespec tp;



        DBUSTRACE(("%s(): Enter \n", __FUNCTION__));

        usbd_xfer_status(xfer, &actlen, &sumlen, &aframes, &nframes);



        switch (USB_GET_STATE(xfer)) {



                case USB_ST_TRANSFERRED:

                        for (nr_frames = 0; nr_frames != aframes;
nr_frames++) {

                                FETCH_LIST_HEAD_ITEM(rx_q_lock, rx_q);

                                if (!data) {

                                        DBUSERR(("got xfer frame but the
rx_q till end ?? \n"));

                                        ASSERT(0);

                                }

                                usbd_xfer_frame_data(xfer, nr_frames,
(void**)&buf, &datalen);

                                kern_clock_gettime(curthread,
CLOCK_UPTIME_PRECISE, &tp);

                                mylog(&glog, "T %p: %d-%d:%u\n", buf,
datalen, tp.tv_sec, tp.tv_nsec);

                                if ((data->rxirb->buf != buf) ||
(data->rxirb->buf_len < datalen)) {

                                        DBUSERR(("the buff or data length
not match ?? \n"));

                                        ASSERT(0);

                                }

                                MUTEX_UNLOCK(usbos_info);

                                dbus_usbos_recv_complete(data, datalen,
DBUS_OK);

                                MUTEX_LOCK(usbos_info);

                        }

                        __transfered += nr_frames;

                        /* no break, FALLTHROUGH */



                case USB_ST_SETUP:

SET_UP_XFER:

                        nr_frames = 0;

                        mtx_lock(&usbos_info->rx_q_lock);

                        STAILQ_FOREACH(data, &usbos_info->rx_q, next) {

                                if (data->rxirb == NULL)

                                        break;

                                kern_clock_gettime(curthread,
CLOCK_UPTIME_PRECISE, &tp);

                                mylog(&glog, "S %p:%d-%d:%u\n",
data->rxirb->buf,

                                        data->rxirb->buf_len, tp.tv_sec,
tp.tv_nsec);

                                usbd_xfer_set_frame_data(xfer, nr_frames,

                                        data->rxirb->buf,
data->rxirb->buf_len);

                                ++nr_frames;

                                if (nr_frames >= BCMWL_HW_IN_PENDING_FRAMES)

                                        break; /* break out from
STAILQ_FOREACH */

                        }

                        mtx_unlock(&usbos_info->rx_q_lock);



                        if (nr_frames) {

                                usbd_xfer_set_frames(xfer, nr_frames);

                                usbd_transfer_submit(xfer);

                        } else {

                                printf("%s(): end of rx_q \n",
__FUNCTION__);

                        }

                        __setup += nr_frames;

                        break;



                default:

                        DBUSERR(("%s(): error = %s with %d bytes
transfered\n",

                                __FUNCTION__, usbd_errstr(error), actlen));



                        if (error == USB_ERR_STALLED || error ==
USB_ERR_IOERROR) {

                                printf("%s(): calling DBUS_STATE_DOWN for
%s\n",

                                        __FUNCTION__, usbd_errstr(error));

                                dbus_usbos_state_change(usbos_info,
DBUS_STATE_DOWN);

                        }



                        if ((error != USB_ERR_CANCELLED) && (error !=
USB_ERR_STALLED)) {

                                usbd_xfer_set_stall(xfer);

                                goto SET_UP_XFER;

                        } else {

                                /* return all rxirb in the queue */

                                MUTEX_UNLOCK(usbos_info);

                                mtx_lock(&usbos_info->rx_q_lock);

                                while ((data =
STAILQ_FIRST(&usbos_info->rx_q)) != NULL) {


STAILQ_REMOVE_HEAD(&usbos_info->rx_q, next);

                                        dbus_usbos_recv_complete(data, 0,
DBUS_ERR_RXFAIL);

                                }

                                STAILQ_INIT(&usbos_info->rx_q);

                                mtx_unlock(&usbos_info->rx_q_lock);

                                MUTEX_LOCK(usbos_info);

                        }



                        break;

        }



}

From hps at selasky.org  Tue Oct 28 06:38:45 2014
From: hps at selasky.org (Hans Petter Selasky)
Date: Tue, 28 Oct 2014 07:38:49 +0100
Subject: USB stack driver options for the receive side question
In-Reply-To: <CADoY-6if1KiLvQWTM89JL0GFOcmOUx7Gqg+9VVLEdaVyU-t58A@mail.gmail.com>
References: <CADoY-6if1KiLvQWTM89JL0GFOcmOUx7Gqg+9VVLEdaVyU-t58A@mail.gmail.com>
Message-ID: <544F39F9.3080205@selasky.org>

On 10/28/14 04:03, Nidal Khalil wrote:
> Hello All,
> I am setting up usb to transfer 3 frames on the bulk read descriptor but
> all I get is one frame transferred? Basically aframe = 1
>
> However if I use .short_frames_ok = 1, then the transfer will pend till the
> three frames are received. This code is part of a network driver
> I would like to receive the one buffer it is the only one available and at
> most three buffers at a time if the transfer is complete.
> The one frame a time to respond to ping and three frame at time when the
> transfer load is heavy.
>
> Is this a limitation of FreeBSD.
> I searched all the drivers in the 9.3 release and I can not find a driver
> that is setup to receive multiple buffers?
>
> Below is my sample code:
>

Hi,

The USB hardware drivers don't have a timeout on the multi-transfers. 
The only mechanism that is widely accepted is the so-called short packet 
termination mechanism, and that is enabled when "short_frames_ok = 0" 
and "short_xfer_ok = 1".

If the hardware can tell in advance the lengths of the IP-packets, then 
you can setup a multi-job to receive them, or if the hardware can be 
configured to pad with zero-length packets up to a configurable number, 
it will work too.

--HPS


From bugzilla-noreply at freebsd.org  Tue Oct 28 06:39:55 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 28 Oct 2014 06:39:55 +0000
Subject: [Bug 194633] FreeBSD 10.1-RC3 can't detect all available USB devices
In-Reply-To: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194633-17-myTVwgGK04@https.bugs.freebsd.org/bugzilla/>

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

Hans Petter Selasky <hselasky at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hselasky at FreeBSD.org

--- Comment #1 from Hans Petter Selasky <hselasky at FreeBSD.org> ---
Hi,

There are no big changes in the USB UMASS area. Possibly SCSI/CAM related.

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Tue Oct 28 16:08:20 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 28 Oct 2014 16:08:20 +0000
Subject: [Bug 194091] Add support for long range USB wireless adapter Alpha
 AWUS036NHRv2
In-Reply-To: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194091-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194091-17-As4t1HNXSg@https.bugs.freebsd.org/bugzilla/>

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

olivier at cochard.me changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Triage                |Issue Resolved
         Resolution|---                         |FIXED

--- Comment #3 from olivier at cochard.me ---
Fixed by commit 272410 and 272590.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Tue Oct 28 17:41:32 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 28 Oct 2014 17:41:32 +0000
Subject: [Bug 194633] FreeBSD 10.1-RC3 can't detect all available USB devices
In-Reply-To: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194633-17-bnMRTm9w0O@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #2 from rff1917 at yahoo.com ---
Do you have any suggestion what I could try? This is pretty much the only
regression I can see in 10.1 so far. And this device is the only USB device
that doesn't work properly.

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Tue Oct 28 20:29:02 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Tue, 28 Oct 2014 20:29:01 +0000
Subject: [Bug 194633] FreeBSD 10.1-RC3 can't detect all available USB devices
In-Reply-To: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>
References: <bug-194633-17@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-194633-17-UryLkyrEHr@https.bugs.freebsd.org/bugzilla/>

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

--- Comment #3 from Hans Petter Selasky <hselasky at FreeBSD.org> ---
Hi,

There are some options and commands that will give you more debugging output
from the CAM/SCSI layer. mav @ knows more about this.

--HPS

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Fri Oct 31 23:11:44 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Fri, 31 Oct 2014 23:11:43 +0000
Subject: [Bug 194727] New: uaudio device gets disconnected, and hangs usb
 until everything using /dev/mixer* is closed
Message-ID: <bug-194727-17@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 194727
           Summary: uaudio device gets disconnected, and hangs usb until
                    everything using /dev/mixer* is closed
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: usb
          Assignee: freebsd-usb at FreeBSD.org
          Reporter: tcberner at gmail.com

Hi

I'm using a pair of KEF X300A speakers, which get recognized by the uaudio
driver. 

Sporadically get: 
uaudio0: at uhub4, port 2, addr 3 (disconnected)
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204)
pcm0: Waiting for sound application to exit!
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204)
pcm0: Waiting for sound application to exit!
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204)
pcm0: Waiting for sound application to exit!
[... -- closing/killing the concerning the application]
pcm0: Waiting for sound application to exit!
pcm0: unregister: mixer busy
pcm0: Waiting for sound application to exit!
pcm0: unregister: mixer busy
[repeat at infinitum]



The usb-stack seems to be completly hung at this point (usbconfig&friends hang)
-- until I close everything else that has /dev/mixer* open. Then the device
seems to reattach and gets usable again.

-- 
You are receiving this mail because:
You are the assignee for the bug.