On 11/21/16 7:05 , Jorge Schrauwen wrote:
> USB3 Key: works fine if plugged in USB3 port!
> 
> I moved to back to the USB2 port and I plugged in the 2 devices that
> were in the hub into the 2 USB3 ports but the box creating a dump now :s
> 
> Do you want me to send you the dump?

Yes, please that'd be very useful.

Also the output from the kernel there is also quite useful. The being
unable to get the devices to transition is quite useful in understanding
what happened, though there are some confusing messages. I'm a bit
surprised that we saw the slot disabling fail -- another thing to look into.

Thanks,
Robert

> On 2016-11-21 15:57, Jorge Schrauwen wrote:
>> https://gist.github.com/sjorge/b7fb9113468ae538c84dd8df3b6dc92e
>>
>> I noticed on the console that it complains about not being able to
>> bring online some of the USB stuff.
>> I also included the dmesg snippet from the time.
>>
>> It did seem to detect the USB key so I will see if I can get that to
>> work and leave the kb in the hub connecto to usb2
>>
>> On 2016-11-20 20:04, Robert Mustacchi wrote:
>>> On 11/20/16 1:29 , Jorge Schrauwen wrote:
>>>>
>>>> On 2016-11-19 17:11, Robert Mustacchi wrote:
>>>>> On 11/19/16 5:14 , Jorge Schrauwen wrote:
>>>>>> I just upgrade one of my compute nodes.
>>>>>> No crashes yet, but nothing plugged into the USB3 ports is working.
>>>>>> I tried a USB-keyboard and a USB3 Drive.
>>>>>>
>>>>>> [root@mantle ~]# mdb -ke '::prtusb'
>>>>>> INDEX   DRIVER      INST  NODE          GEN  VID.PID     PRODUCT
>>>>>> 1       xhci        0     pci15d9,813   3.0  0000.0000   No Product
>>>>>> String
>>>>>> 2       ehci        0     pci8086,7270  2.0  0000.0000   No Product
>>>>>> String
>>>>>> 3       hubd        0     hub           2.0  8087.07db   No Product
>>>>>> String
>>>>>> 4       hubd        2     hub           2.0  0557.7000   No Product
>>>>>> String
>>>>>> 5       usb_mid     2     device        1.1  0557.2419   No Product
>>>>>> String
>>>>>> 6       hubd        1     hub           2.0  1a40.0101   USB 2.0 Hub
>>>>>> 7       scsa2usb    0     storage       2.1  0781.5583   Ultra Fit
>>>>>> 8       ugen        1     input         2.0  051d.0002
>>>>>> Back-UPS RS 900G FW:879.L4 .I USB FW:L4
>>>>>> 9       hubd        4     hub           1.1  058f.9254   Generic
>>>>>> USB Hub
>>>>>> a       usb_mid     3     device        2.0  046d.c52b   USB Receiver
>>>>>> b       usb_mid     4     device        1.1  10d5.55a2   2Port
>>>>>> KVMSwitcher
>>>>>> [root@mantle ~]# prtconf -dD | grep -i xhci
>>>>>>             pci15d9,813 (pciex1912,14) [Renesas Technology Corp.
>>>>>> uPD720201 USB 3.0 Host Controller], instance #0 (driver name: xhci)
>>>>>
>>>>> Hmm, one of the Renesas controllers, not one we've seen yet. Also
>>>>> one of
>>>>> the ones more often reported to be troublesome.
>>>>>
>>>>> If you have the time, can you please plug things back into USB 3
>>>>> ports,
>>>>> reboot, and then run the following:
>>>>>
>>>>> /usr/lib/xhci/xhci_portsc -v
>>>>>
>>>>> Along with the mdb -ke '::prtusb'. Could you also check if there's
>>>>> anything got logged about that?
>>>>
>>>> I added everything to a gist for easier reading:
>>>> https://gist.github.com/sjorge/47cb7f5e14b335c3c3c382dd3daf4e4f
>>>>
>>>> This is with the boot USB plugged into the first USB3 port (it always
>>>> works at boot, even before the xhci work)
>>>> The small USB2 hub with my keyboard (KVM) and UPS plugged in
>>>> attached to
>>>> the second USB3 port.
>>>
>>> Thanks for the additional information. It looks like one of your ports
>>>  is stuck trying to transition in the device state machine.
>>> Unfortunately
>>> it's a bit hard to get a mapping between the virtual ports on the
>>> controller and the physical ports on the machine.
>>>
>>> I'm not entirely sure why it would be stuck in that state, from the
>>> spec
>>> it makes it sound like it's supposed to transition that way on its own
>>> without any intervention from the host.
>>>
>>> It does look like we detected one of the devices, but for some reason
>>> that fact didn't make it to the kernel per se. Would it be possible for
>>> you to run cfgadm -al in both cases?
>>>
>>> Sorry I don't have a more immediate answer for what's happening here.
>>>  I'm not sure yet what's different about your setup from others --
>>> though
>>> more likely than not there's some driver bug at the root of it all.
>>>
>>> Robert
>>>
>> 
>> 


-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com

Reply via email to