I just tried if there is a difference when the device is on and has booted Android: there isn't. Same problem.

This is from another run, during which I didn't open chrome://settings.

[ 2030.204556] usb 2-1: new high-speed USB device number 78 using xhci_hcd
[ 2088.981167] usb 2-1: new high-speed USB device number 36 using xhci_hcd
[ 2109.501771] usb 2-1: new high-speed USB device number 61 using xhci_hcd
[ 2127.429285] usb 2-1: new high-speed USB device number 74 using xhci_hcd
[ 2143.628042] usb 2-1: new high-speed USB device number 79 using xhci_hcd
[ 2158.962440] usb 2-1: new high-speed USB device number 80 using xhci_hcd
[ 2174.512961] usb 2-1: new high-speed USB device number 82 using xhci_hcd
[ 2189.815340] usb 2-1: new high-speed USB device number 83 using xhci_hcd
[ 2190.009682] usb 2-1: New USB device found, idVendor=04e8, idProduct=6860
[ 2190.009695] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2190.009702] usb 2-1: Product: SAMSUNG_Android
[ 2190.009709] usb 2-1: Manufacturer: SAMSUNG

It's clear to me that chrome://settings would've stalled if I tried. For some reason the page is blocked while Chrome does this lengthy USB dance.

Just another minor point. After Chrome finished its lengthy dance without being interrupted by opening chrome://settings, doing so afterwards still stalls the page, but only briefly, for 1-2 seconds.

[ 2552.290774] usb 2-1: new high-speed USB device number 95 using xhci_hcd
[ 2552.650943] usb 2-1: new high-speed USB device number 96 using xhci_hcd
[ 2553.131053] usb 2-1: new high-speed USB device number 97 using xhci_hcd
[ 2553.261346] usb 2-1: New USB device found, idVendor=04e8, idProduct=6860
[ 2553.261350] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2553.261353] usb 2-1: Product: SAMSUNG_Android
[ 2553.261355] usb 2-1: Manufacturer: SAMSUNG

Weird. I fail to see how a phone that's off can affect the system. How can a phone that's "off" be seen by the Linux machine as a new device?

(It's a tablet.) It's only off insofar that it's not on. When it's
plugged into USB, the device boots into the bootloader to show the
battery gauge. In that state it identifies itself just as if it had
booted into Android. (And as I mentioned, the same effect occurs when
it's actually booted into Android.)

We can look at chrome://profiler to see what function is locking up the UI thread for so long.

Click "Group by" and select "Exec thread" and then sort the first table (CrBrowserMain) by "Avg run time" and attach a screenshot.

I had a bit of trouble to reproduce it reliably yesterday, so I reverted to the guaranteed way, which is how I first noticed it.

1. Delete profile
2. Plug-in device
3. Open Chrome
4. Go to chrome://settings

If I read the results correctly, it stalled for 15 seconds. It can be 1-2 minutes easily.

Deleted: 1.png 76.1 KB

	1.png 76.1 KB View Download

That wasn't as helpful as I'd hoped. It's definitely getting stuck processing a WebUI message but the profiler can't tell us which one.

I've come to the conclusion that this is not caused by Chrome. It's a
problem with the USB port itself or perhaps a kernel bug. You could
argue that Chrome stalling on the problem, rather than ignoring it, is
still a bug.

It would be nice to know what Chrome is waiting for when the system stalls. The UI thread shouldn't ever get locked up like that. We are probably calling into some OS API that is normally fast but blocks in this case. You may be able to figure it out by attaching strace to the browser process and watching what system call it is in when the UI freezes.

I've catched it. It didn't want to reproduce again, even with the way described in #7.

Until at some point adb disconnected (unrelated to Chrome, which was closed). I noticed dmesg filling up with the same messages, and tried #7 again.

The time is seconds for each call or line.

     0.000055 readlink("/sys/devices/pci0000:00/0000:00:14.0/usb2", 0x7fff46cb1510, 1024) = -1 EINVAL (Invalid argument)
     0.000051 stat("/sys/devices/pci0000:00/0000:00:14.0/usb2/uevent", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
     0.000061 open("/sys/devices/pci0000:00/0000:00:14.0/usb2/uevent", O_RDONLY|O_CLOEXEC) = 142
     0.000049 fstat(142, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
     0.000042 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9d30890000
     0.000042 read(142, "MAJOR=189\nMINOR=128\nDEVNAME=bus/"..., 4096) = 126
     0.000090 read(142, "", 4096)       = 0
     0.000052 close(142)                = 0
     0.000043 munmap(0x7f9d30890000, 4096) = 0
     0.000051 open("/sys/bus/usb/devices/usb2/busnum", O_RDONLY) = 142
     0.000062 fstat(142, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
     0.000046 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9d30890000
     0.000048 read(142, "2\n", 4096)    = 2
     0.000054 close(142)                = 0
     0.000042 munmap(0x7f9d30890000, 4096) = 0
     0.000048 open("/sys/bus/usb/devices/usb2/devnum", O_RDONLY) = 142
     0.000060 fstat(142, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
     0.000045 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9d30890000
     0.000049 read(142, "1\n", 4096)    = 2
     0.000051 close(142)                = 0
     0.000042 munmap(0x7f9d30890000, 4096) = 0
     0.000049 open("/sys/bus/usb/devices/usb2/speed", O_RDONLY) = 142
     0.000058 fstat(142, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
     0.000046 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9d30890000
     0.000044 read(142, "480\n", 4096)  = 4
     0.000972 close(142)                = 0
     0.000067 munmap(0x7f9d30890000, 4096) = 0
     0.000054 open("/sys/bus/usb/devices/usb2/descriptors", O_RDONLY) = 142
     0.000069 read(142, "\22\1\0\2\t\0\1@k\35\2\0\26\3\3\2\1\1\t\2\31\0\1\1\0\340\0\t\4\0\0\1"..., 1024) = 43
   166.560231 close(142)                = 0
     0.000079 readlink("/sys/devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0", 0x7fff46cb1510, 1024) = -1 EINVAL (Invalid argument)
     0.000066 stat("/sys/devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0/uevent", {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
     0.000066 open("/sys/devices/pci0000:00/0000:00:14.0/usb2/2-0:1.0/uevent", O_RDONLY|O_CLOEXEC) = 85
     0.000049 fstat(85, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
     0.000031 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9d30890000
     0.000039 read(85, "DEVTYPE=usb_interface\nDRIVER=hub"..., 4096) = 138
     0.000068 read(85, "", 4096)        = 0
     0.000031 close(85)                 = 0
     0.000028 munmap(0x7f9d30890000, 4096) = 0

Now it shows that close() took more than 2 minutes, but I'm not sure it's the culprit as the console displayed this when it stalled.

              read(142,

So it might actually be read(). 

Actually it appears to be the close() call as it already reported the time on the read() call. This is the exact output when it stalled.

     0.000054 open("/sys/bus/usb/devices/usb2/descriptors", O_RDONLY) = 142
     0.000069 read(142, 

Can you see if this is reproducible with Chrome 53.0.2751.0 or higher? Taking a close look at libusb it looks like it tries to perform an initial enumeration of devices when it is initialized, which we did on the UI thread prior to that version. Now we don't use libusb on Linux at all and reading that file happens on the FILE thread as it is supposed to.

Would this also reproduce (or not) in Chromium? I'd rather try a
continuous build than switch channels. (Do you know the commit?)

This should reproduce in Chromium. The commit is dee7c4ac95c2a2c73fe5c636906a7245951905fc.

I'll try when it occurs again, which it will eventually.

(Adding for myself.)

https://chromium.googlesource.com/chromium/src/+/dee7c4ac95c2a2c73fe5c636906a7245951905fc

It works. I tried both and 396554 again to verify.

396554: STALL
396562: OK
396554: STALL

Thank you for testing. Marking this issue as fixed.

Got a new USB issue. (Unrelated, I think.)

https://bugs.chromium.org/p/chromium/issues/detail?id=671140