[Bug 194226] USB does not work early in the boot process when 60/64 emulation support is enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194226 --- Comment #1 from ne...@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. ___ 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
XHCI device probe inconsistency
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 = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x 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=0x2NO_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=0x2NO_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=0x2NO_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=0x2NO_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=0x2NO_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=0x2NO_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=0x2NO_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=0x2NO_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@pci0:0:20:0: class=0x0c0330
Re: Panic in usb_unref_device
On 3 Oct 2014, at 21:18, Hans Petter Selasky h...@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=revisionrevision=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 ___ 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: BadUSB - On Accessories that Turn Evil, by Karsten Nohl + Jakob Lell
Hi Hans Petter Selasky wrote: On 10/06/14 22:30, Poul-Henning Kamp wrote: In message 201410061956.s96ju8s3089...@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. ___ 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
