It gets even weirder!
This is with the UPS attached
[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 1 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 ugen 0 input 2.0 051d.0002
Back-UPS RS 900G FW:879.L4 .I USB FW:L4
Now also note that the USB3 key with the smartos-live image is not
detected!
It only seems to be detected if I plug it in AFTER the host has booted
but not if it is present at boot. (As grub did load the kernel +
boot_archive from it)
Here I switched back to everything behind the hub on a USB2 port. But I
remembered to unplug and replug the USB3 key on the USB3 port it was not
detecting... and poof it appeared!
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 1 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 3 hub 2.0 1a40.0101 USB 2.0 Hub
7 hubd 4 hub 1.1 058f.9254 Generic USB Hub
8 usb_mid 3 device 2.0 046d.c52b USB Receiver
9 usb_mid 4 device 1.1 10d5.55a2 2Port
KVMSwitcher
a ugen 1 input 2.0 051d.0002
Back-UPS RS 900G FW:879.L4 .I USB FW:L4
b scsa2usb 0 storage 3.0 0781.5583 Ultra Fit
Notice aboce the Ultra Fit was not detected, I just unplugged and
replugged it into the same port :/
I'm going back to the working setup now but I can play some more this
weekend.
Perhaps you have some specific things you want me to try by then.
Regards
Jorge
On 2016-11-21 18:20, Jorge Schrauwen wrote:
Here is the data with the USB1 hub connected to a USB2 port:
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 1.1 058f.9254 Generic USB
Hub
4 hubd 1 hub 2.0 8087.07db No Product
String
5 usb_mid 0 device 2.0 046d.c52b USB Receiver
6 hubd 2 hub 2.0 0557.7000 No Product
String
7 usb_mid 1 device 1.1 10d5.55a2 2Port
KVMSwitcher
8 usb_mid 2 device 1.1 0557.2419 No Product
String
The 2nd dump is definitely something that did not happen before
because I joggled the USB ports a lot before I got the USB2 hub.
Regards
Jorge
On 2016-11-21 18:12, Jorge Schrauwen wrote:
Well now,
I just plugged the UPS into the USB2 port after unplugging the hub...
and the thing panics again!
So it was probably not the USB1 Hub on the KVM.
I'll get you the dump from earlier and the new one later tonight, will
grab dinner now.
I can do some more testing but probably not until the weekend.
Regards
Jorge
On 2016-11-21 16:46, Robert Mustacchi wrote:
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
