Problem attaching USB keyboard
Hi everyone, the following problem occurs on the amd64 version of FreeBSD 9.2-RC4, FreeBSD-9.2-PRERELEASE-20130831-r255108, FreeBSD-10.0-ALPHA2, and FreeBSD-10.0-CURRENT-20130907-r255342. I simply can't use my keyboard (Lenovo Prefered Pro USB). I used the FreeBSD memstick ISO to install the system. I had no problems using the keyboard within the memstick version (bsdinstall, and so on). But on the installed copy of FreeBSD I get the following error when I try to attach the keyboard: usb_alloc_device: device init 2 failed (USB_ERR_IOERROR, ignored) ugen0.2: Unknown at usbus0 (disconnected) hub_reattach_port: could not allocate new device I had to set debug.acpi.disabled to hostres on all version, in order to boot the system. [1] This error does not occur on 9.1-RELEASE. Mainboard: Intel DQ87PG (Keyboard is connected via the USB 2.0 port) RAM: 32 GB [1] http://www.freebsd.org/releases/9.0R/errata.html ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Problem attaching USB keyboard
The USB controller is provided by the Intel Q87 Express Chipset of the Intel DQ87PG mainboard. On Sun, 22 Sep 2013 17:10:55 +0200 Hans Petter Selasky hans.petter.sela...@bitfrost.no wrote: Hi, What PCI USB controllers are on this computer? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Problem attaching USB keyboard
On Mon, 23 Sep 2013 08:09:25 +0200 Hans Petter Selasky h...@bitfrost.no wrote: hw.usb.xhci.xhci_port_route=-1 Works. Thank you. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/186811: Intel NUC Haswell Generation USB 3 support (solution attached)
Number: 186811
Category: usb
Synopsis: Intel NUC Haswell Generation USB 3 support (solution attached)
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Sun Feb 16 09:20:00 UTC 2014
Closed-Date:
Last-Modified:
Originator: Philipp Maechler
Release:9.2-RELEASE / 10.0-RELEASE
Organization:
Environment:
FreeBSD x.tontaube.ch 10.0-RELEASE FreeBSD 10.0-RELEASE #6 r261922M: Sat Feb 15
19:30:32 CET 2014 r...@x.tontaube.ch:/usr/obj/usr/src/sys/GENERIC amd64
Description:
I bought a Intel Nuc D34010WYK [0]. It has a QS77 Chipset with a Intel Panther
Point USB Controller (as far as I can say).
The problem was, that a connected external harddisk case (it has a JMicron
USB2Sata bridge JMicron JMS539 [1]) or even a simple usb 3 memory stick, it was
always connected at highspeed (usb2) instead of superspeed (usb3) (see
usbconfig in [2]). Of course, the attached harddisk drives only appeared to
have only 40MB/s transfer rates instead of 400MB/s.
[0] http://www.intel.com/content/www/us/en/nuc/nuc-kit-d34010wyk.html
[1] http://www.jmicron.com/Product_JMS539.htm JMicron USB2Sata bridge (in a
Raidsonic Icybox IB-3640SU3 together with a JMB321 SATA port multiplier)
[2]
faked output out of my head, if you need an exactly output I will provide after
a reboot from a 10.0-RELEASE memory stick:
[root@x ~]# 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)
ugen1.2: product 0x8000 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.6: USB to ATAATAPI Bridge JMicron at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (8mA)# - PROBLEM
ugen0.7: USB to ATAATAPI Bridge JMicron at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=ON (8mA)# - PROBLEM
How-To-Repeat:
Attach any USB 3 mass storage (maybe any device) to a Intel Nuc D34010WYK.
Below 9.2-RELEASE and 10.0-RELEASE, the device will only appear as a HIGH-speed
device (usb2) instead of a SUPER-speed device (usb3). (e.g. output dmesg or
usbconfig)
Fix:
By accident I found this commit:
http://lists.freebsd.org/pipermail/svn-src-stable-9/2012-November/003213.html
I then realized, that the pci dev id on my intel nuc is 0x9c318086 instead of
0x8c318086. In a fast hack I added the same code for this id in a 10.0-RELEASE
Generic kernel [3] and the problem was solved [4], the devices are now
correctly routed to xhci and have superspeed support.
I hope this pr helps to integrate the solution to FreeBSD, but I think the
patch is not finished yet (maybe you would change the descriptions etc, as my
knowledge of hardware naming is limited I'm not able to do). But as it doesn't
change much, I'd define it as production-ready.
Philipp
[3]
[root@x /usr/src]# svn diff sys/dev/usb/controller/xhci_pci.c
Index: sys/dev/usb/controller/xhci_pci.c
===
--- sys/dev/usb/controller/xhci_pci.c (revision 261922)
+++ sys/dev/usb/controller/xhci_pci.c (working copy)
@@ -106,6 +106,8 @@
return (Intel Panther Point USB 3.0 controller);
case 0x8c318086:
return (Intel Lynx Point USB 3.0 controller);
+ case 0x9c318086:
+ return (Intel Panther Point USB 3.0 controller);
default:
break;
@@ -239,6 +241,7 @@
switch (pci_get_devid(self)) {
case 0x1e318086:/* Panther Point */
case 0x8c318086:/* Lynx Point */
+ case 0x9c318086:/* Panther Point */
sc-sc_port_route = xhci_pci_port_route;
break;
default:
[4]
[root@x /usr/src]# 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)
ugen1.2: product 0x8000 vendor 0x8087 at usbus1, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.6: USB to ATAATAPI Bridge JMicron at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=ON (2mA) # - perfect
ugen0.7: USB to ATAATAPI Bridge JMicron at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=ON (2mA) # - perfect
Patch attached with submission follows:
--- sys/dev/usb/controller/xhci_pci.c 2014-02-16 10:09:07.597292623 +0100
+++ sys/dev/usb/controller/xhci_pci.c.new 2014-02-16 10:09:00.400292742
+0100
@@ -24,7 +24,7 @@
*/
#include sys/cdefs.h
-__FBSDID($FreeBSD: releng/10.0/sys/dev/usb/controller/xhci_pci.c 255768
2013-09-21 21:40:57Z hselasky $);
+__FBSDID($FreeBSD: release/10.0.0/sys/dev/usb/controller/xhci_pci.c 255768
2013-09-21 21:40:57Z hselasky $);
#include sys/stdint.h
#include sys/stddef.h
@@ -106,6 +106,8
External USB Harddisk ZFS boot problem
Good evening, I have a problem and a manual an nasty work around, and like to have some hints how/where to digg deeper. FreeBSD 10.2 (GENERIC freshly installed) and root zfs pool on a external usb harddisk drive. I try to boot from this zfs pool. More details about the hardware further down. This zfs pool is a zfs send/receive copy of a working zfs boot setup (but it was before an 10.1 - note to myself: never change 2 things at the same time [duplicate]) The new harddisk is setup properly (boot-loader etc) and also the zpool cache file is correctly up-to-date and the bootfs property is set. What happens is that the boot loader works fine, then it loads the kernel and the kernel starts. At this time, the drive switch off and the kernel loads further and starts to wait for root an usbus0 and usbus1 Unsuccessful boot timeline: If I just leave it go, the drive turns on, and as soon as I read "da0 at umass xy" it turns off again and the system starts to throw some errors [1] I don't know what happens at this point, I even suspect a (firmware) crash of the drive (but how to proof? and why doesn't this happen when I connect the disk to an powered up system?). After some time, the disk powers on again (probably by some kind of watchdog) and then the prompt asking for the rootfs appears. Shortly after da0 appears again. I can then specify the zfs:zroot as root fs and it will be recognized and found, because it starts init. But then the hostid line appears and after that it doesn't continue at all (why?) Workaround: However, if I disconnect the drive after the kernel loading turns it off the first time and reconnect it immediately, the drive immediately switch on after connecting and is ready for the rootfs loaded instantly and the system boots up fine. (I stretched the time for the workaround a little bit with hw.usb.timings.extra_power_up_time set to 5000 instead of 20). Details about Hardware see [2]. UFS usb boot works fine (at least from an usb stick loaded with the FreeBSD 10.2 release). Also a patch to correctly route the device to xhci instead of ehci didn't solve the boot problem. I tried: * adding a powered usb hub to exclude power issues * changed order of usb keyboard and usb drive on the 4 ports * played around with all hw.usb.timings options (increased them one by one to 10'000 or all togher by factor 50 * enabled usb verbose outputs for boot, enabled kernel verbose output I'm wondering if you can give me any hints for tracing the problem further, as the workaround is a manual intervention (not sexy at all as it is also for a remote nas). What hints do you have? What information do you need? Please keep in mind, the system is able to boot with the workaround, so it is working at some point. Please specify if you think about the issue about why the drive is powering down again or about not booting properly after mounting the rootfs. Some additional outputs below [3]. I very appreciate any kind of link, hint or even if you like a video of a slowed-down boot (setting console to "vidconsole,comconsole" and serial_speed to 3200 ;-) ) With best regards, Philipp [1] The drive get recognized by kernel and shutdowns again (see MOMENT of power OFF) umass1: on usbus1 umass1: SCSI over Bulk-Only; quirks = 0xc101 umass1:1:1:-1: Attached to scbus1 da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: Fixed Direct Access SPC-4 SCSI device da1: Serial Number NA820YR2 da1: 40.000MB/s transfers da1: 3815447MB (7814037167 512 byte sectors: 255H 63S/T 486401C) da1: quirks=0x2 === MOMENT OF POWER OFF === (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 be ae 00 00 00 01 00 00 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 be ae 00 00 00 01 00 00 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 be ae 00 00 00 01 00 00 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 be ae 00 00 00 01 00 00 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Retrying command (da1:umass-sim1:1:0:0): READ(16). CDB: 88 00 00 00 00 01 d1 c0 be ae 00 00 00 01 00 00 (da1:umass-sim1:1:0:0): CAM status: CCB request completed with an error (da1:umass-sim1:1:0:0): Error 5, Retries exhausted (this lines are from a dmesg outboot after a successfull usb stick ufs boot) [2] Intel NUC with a Samsung 4TB Drive connected - fully configured there will be 2 drives in a mirror zpool. Adding a powered usb3 hub didn't help - so probably no power issue. [3] some outputs after a successfull boot with the workaround and both disks connected (ok, I already patched the kernel at
