[17836.573120] usb 1-1: new full-speed USB device number 23 using xhci_hcd
[17836.744255] usb 1-1: New USB device found, idVendor=0403, idProduct=6001
[17836.744279] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17836.744296] usb 1-1: Product: USB <-> Serial Cable
[17836.744309] usb 1-1: Manufacturer: FTDI
[17836.744320] usb 1-1: SerialNumber: FT0DJR9C
[17836.744457] audit: type=1400 audit(1473021160.654:5955): avc:  denied  { write } for  pid=28 comm="kdevtmpfs" name="001" dev="devtmpfs" ino=9237 scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
[17836.744513] audit: type=1400 audit(1473021160.654:5956): avc:  denied  { add_name } for  pid=28 comm="kdevtmpfs" name="023" scontext=u:r:kernel:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=1
[17836.748575] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
[17836.748759] usb 1-1: Detected FT232RL
[17836.748776] usb 1-1: Number of endpoints 2
[17836.748792] usb 1-1: Endpoint 1 MaxPacketSize 64
[17836.748807] usb 1-1: Endpoint 2 MaxPacketSize 64
[17836.748822] usb 1-1: Setting MaxPacketSize 64
[17836.749184] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB1

I have the same hang with a Keyspan and all the 3 or 4 serial extensions I've tried. 

Confirmed. 

evtest show the keyboard is sending events to the kernel.
No messages in UI.last.

Grant, do you know who will have some insight?

Charlie, can you take a look?

On OS X El Capitan w/ Chrome Canary 53.0.2785.116 (64-bit), whenever I update Chrome Canary my USB mouse (logitech) freezes and is unusable until I unplug it and plug it back in. This only started happening lately with the work on WebUSB.

Looks like I can't edit my comment, the version of Canary that I'm running is actually 55.0.2873.4 canary (64-bit).

That's really interesting but probably a separate bug. Can you file a new issue with the model of your mouse as well?

Same on CrOS 54.0.2840.43 beta (64-bit). Freezes at chrome.serial.connect() call. Also it seems that WebUSB (navigator.usb API) stoped detecting USB devices in this build. Possibly these things have something in common.

OK, I've opened up the USB mouse freezing issue on Chrome updates here: https://bugs.chromium.org/p/chromium/issues/detail?id=652128

Sorry: I somehow missed this one until just now. I just got back from vacation, but can take a look later this week.

Confirmed.  This breaks kiosk apps with serial support that are connected to ELO Touchscreens via USB.

App hangs while launching (chrome.serial.connect) and shows a white screen.  Unplugging the touchscreen and plugging it back in is a workaround, app loads normally after that.

What platform is this happening on?

Pixel 2

Jean-Marc

We're seeing this on the Asus Chromebox CN60 (Panther).

Ah, crap. Assigning this one back to reillyg@: I wrote the enumeration code on Windows and Mac, but haven't done any work on CrOS. reillyg@, did you write that implementation?

I can reproduce this on my Samus. Working on getting live logs from the machine so I can see exactly where the freeze happens.

Thanks!

You're not off the hook yet Charlie. It looks like the hang is happening in AttemptRead(). I'm investigating why this read() isn't returning immediately with EAGAIN since the file descriptor should have been opened non-blocking.

Sorry, I forgot who had added AttemptRead(). Anyways, here's a patch that fixes it to work on Chrome OS: https://codereview.chromium.org/2494513002

Phew - I saw your first message and thought to myself, "Did I do that?!". Glad I'm not losing my mind :-)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0366454d38a76aba066b183f2f8132a15e26b385

commit 0366454d38a76aba066b183f2f8132a15e26b385
Author: reillyg <reillyg@chromium.org>
Date: Wed Nov 09 20:41:02 2016

Explicitly put serial port fd in non-blocking mode on Chrome OS.

On Chrome OS the serial port is opened by the permission broker service,
which does not open the file descriptor in non-blocking mode. Chrome
should thus explicitly put the file descriptor in this mode to match the
flags set on other platforms.

Since r408467 we have relied on the file being in non-blocking mode to
test for data available as soon as it is open.

BUG= 644017 

Review-Url: https://codereview.chromium.org/2494513002
Cr-Commit-Position: refs/heads/master@{#431026}

[modify] https://crrev.com/0366454d38a76aba066b183f2f8132a15e26b385/device/serial/serial_io_handler.cc
[modify] https://crrev.com/0366454d38a76aba066b183f2f8132a15e26b385/device/serial/serial_io_handler_posix.cc
[modify] https://crrev.com/0366454d38a76aba066b183f2f8132a15e26b385/device/serial/serial_io_handler_posix.h

This is a low-risk patch to merge to M-55.

TPMs want a merge to M-54 as well.

[Automated comment] Request affecting a post-stable build (M54), manual review required.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7bc4382e2f3885ae85ea398de2e0d4013b0d2348

commit 7bc4382e2f3885ae85ea398de2e0d4013b0d2348
Author: Reilly Grant <reillyg@chromium.org>
Date: Thu Nov 10 20:18:13 2016

Explicitly put serial port fd in non-blocking mode on Chrome OS.

On Chrome OS the serial port is opened by the permission broker service,
which does not open the file descriptor in non-blocking mode. Chrome
should thus explicitly put the file descriptor in this mode to match the
flags set on other platforms.

Since r408467 we have relied on the file being in non-blocking mode to
test for data available as soon as it is open.

BUG= 644017 

Review-Url: https://codereview.chromium.org/2494513002
Cr-Commit-Position: refs/heads/master@{#431026}
(cherry picked from commit 0366454d38a76aba066b183f2f8132a15e26b385)

Review URL: https://codereview.chromium.org/2494663003 .

Cr-Commit-Position: refs/branch-heads/2883@{#524}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/7bc4382e2f3885ae85ea398de2e0d4013b0d2348/device/serial/serial_io_handler.cc
[modify] https://crrev.com/7bc4382e2f3885ae85ea398de2e0d4013b0d2348/device/serial/serial_io_handler_posix.cc
[modify] https://crrev.com/7bc4382e2f3885ae85ea398de2e0d4013b0d2348/device/serial/serial_io_handler_posix.h

 Issue 664375  has been merged into this issue.

in some chromeos device for example Acer C720, v54 is already stable.
Can i expect the fix will be delivered in very next update?

This change is being reviewed for merge to M-54. If it is approved it will be in the next update.

all right. thank you reillyg.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/47054374b745e35b7a33e80fd61eea6cb7897d06

commit 47054374b745e35b7a33e80fd61eea6cb7897d06
Author: Reilly Grant <reillyg@chromium.org>
Date: Mon Nov 14 15:58:08 2016

Explicitly put serial port fd in non-blocking mode on Chrome OS.

On Chrome OS the serial port is opened by the permission broker service,
which does not open the file descriptor in non-blocking mode. Chrome
should thus explicitly put the file descriptor in this mode to match the
flags set on other platforms.

Since r408467 we have relied on the file being in non-blocking mode to
test for data available as soon as it is open.

BUG= 644017 

Review-Url: https://codereview.chromium.org/2494513002
Cr-Commit-Position: refs/heads/master@{#431026}
(cherry picked from commit 0366454d38a76aba066b183f2f8132a15e26b385)

Review URL: https://codereview.chromium.org/2501613002 .

Cr-Commit-Position: refs/branch-heads/2840@{#834}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/47054374b745e35b7a33e80fd61eea6cb7897d06/device/serial/serial_io_handler.cc
[modify] https://crrev.com/47054374b745e35b7a33e80fd61eea6cb7897d06/device/serial/serial_io_handler_posix.cc
[modify] https://crrev.com/47054374b745e35b7a33e80fd61eea6cb7897d06/device/serial/serial_io_handler_posix.h

I know we're not suppose to write "me to" messages but...

We have numerous digital signage players out in the field, and they have stopped working. This has severely disrupted out company and our customers. 

It boggles the mind to see that this bug was reported in September 4th, and yet the Chromium development team still propogated it to the "Stable" branch two months later?!?

What definition of 'stable' are you using?

 Issue 664847  has been merged into this issue.