On Tue, Jun 26, 2018 at 12:10:56PM +0200, Timur Krist?f wrote:
> On Tue, 2018-06-26 at 11:29 +0300, Heikki Krogerus wrote:
> > On Mon, Jun 25, 2018 at 01:09:32PM +0200, Timur Krist?f wrote:
> > > On Mon, 2018-06-25 at 13:11 +0300, Heikki Krogerus wrote:
> > > > +Mika
> > > >
> > > > On Fri, Jun 22, 2018 at 10:12:10AM +0200, Timur Krist?f wrote:
> > > > > Hi,
> > > > >
> > > > > I have a Dell XPS 13 9370, which has just Type-C ports.
> > > > > Currently
> > > > > running kernel 4.17.2. I found that plugging in a powered USB
> > > > > hub
> > > > > into
> > > > > the Type-C port does not work.
> > > > >
> > > > > Please let me know if this isn't the correct place to report
> > > > > this
> > > > > problem. Not sure if this is a Dell-specific issue or a Linux-
> > > > > specific
> > > > > issue, so I'm also CCing Mario from Dell.
> > > > >
> > > > > The following test cases were tried:
> > > > >
> > > > > 1. When I plug in the hub to the laptop, and then plug in the
> > > > > peripherals, it works as expected. (This is OK.)
> > > > >
> > > > > 2. But when I plug peripherals into the hub, and then plug it
> > > > > into
> > > > > the
> > > > > laptop, it takes at least 10-30 seconds to detect them. (Until
> > > > > then
> > > > > they don't show up in lsusb.)
> > > > >
> > > > > 3. If the hub is powered and power is connected to the hub
> > > > > before
> > > > > plugging it in, it is not detected at all. Sometimes it is
> > > > > detected
> > > > > after being plugged in for a very long time, but not always.
> > > > >
> > > > > I tried with various different configurations:
> > > > >
> > > > > A. Dell USB Type-C to Type-A adapter with a Speedlink USB 2.0
> > > > > hub.
> > > > >
> > > > > B. Same Dell C-to-A adapter with the built-in USB 2.0 hub of a
> > > > > Dell
> > > > > P2414H monitor.
> > > > >
> > > > > C. Qoltec USB Type-C to USB 3.0 hub
> > > > >
> > > > > All of these exhibited the same behaviour. When the hub was
> > > > > powered
> > > > > before plugging it in, then they were not recognized at all,
> > > > > when
> > > > > unpowered they were recognized in ~ 30 seconds (which is still
> > > > > too
> > > > > long
> > > > > though).
> > > > >
> > > > > Note that the USB 2.0 hubs both worked correctly with other
> > > > > machines
> > > > > which just had a USB-A port. When plugged into a USB-A port,
> > > > > all
> > > > > the
> > > > > connected peripherals were immediately detected as soon as the
> > > > > hub
> > > > > was
> > > > > plugged in.
> > > > >
> > > > > What might be the issue here? How can I help debug this
> > > > > further?
> > > >
> > > > This could be a problem with the Thunderbolt controller. Mika, do
> > > > you
> > > > know if there are any known problems when using self powered USB
> > > > hubs?
> > > >
> > >
> > > The issue also happens with the non-Thunderbolt USB Type-C port, at
> > > least on this laptop.
> >
> > Ah, ic. XPS 9360 has two thunderbolt ports and a standard-A port on
> > the other side. I can see that the standard-A port has been replaced
> > with the USB Type-C port on XPS 9370.
> >
>
> 9360 (2017 model) has two USB 3.0 Type-A ports and one Thunderbolt 3
> Type-C (with 2 PCI-E lanes).
>
> 9370 (2018 model) has one USB 3.1 Type-C, and two Thunderbolt 3 Type-C
> ports (with 4 PCI-E lanes). No Type-A ports. This is what I've got.
>
> > Are you able to test if the problem can been seen also in Windows?
>
> I don't have Windows with this machine (it came with Ubuntu). But I
> guess I could try with an evaluation version of Windows, if that is
> helpful.
It would help confirm if this is a firmware related bug or not.
One thing I forgot to ask you. Do you see any messages in your syslog
when the problem happens, and is there any difference in the syslog
messages when compared to the situation where the hub is enumerated
normally?
Can you send the dmesg output after you have plugged the powered and
non-powered hubs:
% dmesg > <output file name>
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
