Teensy3 makes Arduino development environment hang

Status
Not open for further replies.
L

lisper

Member
I have some code running on my Teensy3 that causes the Arduino development environment to hang to the point where I have to force-quit it to recover. I am still in the process of debugging this, but I thought I'd go ahead and post this just in case someone else has seen a similar problem and can save me some time.

Some characteristics of the bug:

1. It's a Heisenbug. Adding diagnostics changes the point at which the bug manifests itself.

2. It's not random. When the bug manifests itself it is 100% reproducible.

3. Under certain circumstances, the bug can manifest itself during a call to delay(), i.e. I can run this code:

Serial.println("foo");
delay(1000);
Serial.println("baz");

and I will get "foo" but not "baz".

4. It's not the linker problem reported yesterday by Bill Greiman (at least I don't think so -- I applied Bill's fix to my mk20dx128.ld file and nothing changed).

5. It's not caused by anything the teensy outputs on its USB serial port. I can run the code looking at the raw output from /dev/cu.usbmodem12341 (piped through hexdump so I can see everything) and there is no output after the point at which the bug is triggered.

6. I can't reproduce it with a simple sketch (yet). The bug only manifested itself once I was very deep into the development process for some very complicated code. Up to that point everything had been working flawlessly. I have no idea how I would go about reproducing the bug without all that hairy code.

This is a contender for weirdest-bug-I-have-ever-seen, and that's saying something.
 
It's a Heisenbug. Adding diagnostics changes the point at which the bug manifests itself.
Click to expand...
If it was an Arduino I'd say you've run out of SRAM. The Teensy3 has 16kB which is still not infinite so I'd still suggest that you check how much SRAM you have free. Do you have lots of strings or large arrays?

Pete
 
Can a complex sketch, but otherwise one not depending on special extra hardware, reproduce this hang? If so, maybe it's worthwhile to post the code?

Also, since you wrote "force-quit", I'm guessing this is a Mac? Details about which OS and version are affected would be good too. Each OS implements USB differently, and Apple as updated/rewritten their communications class driver at least twice since 10.5.
 
Yeah, sorry, this is a Macbook Pro running Snow Leopard.

Running out of RAM is a possibility but why would that make the development environment hang?

I will try to collect the code and post a self-contained way to reproduce the problem, but I won't be able to do it until tomorrow.
 
I have seen this problem on a Windows 7 computer. Any changes to the print statements can make the bug go away.

Adding a Serial.flush() before the problem can make it go away.

I also can't isolate it in a simple example.
 
I think there is some odd behavior with Teensy3 usb serial on some platforms.
I could not get the simplest serial program to output data.

The program I tried is just an arduino-less modified blink program:

#include "WProgram.h"

#ifdef USB_SERIAL
usb_serial_class Serial;
#endif

int main(void)
{
// To use Teensy 3.0 without Arduino, simply put your code here.
// For example:

pinMode(13, OUTPUT);
Serial.begin(9600);
while (1) {
digitalWrite(13, HIGH);
Serial.println("HIGH");
delay(1000);
digitalWrite(13, LOW);
Serial.println("LOW");
delay(1000);
}
}

I have tried this program on few different combinations.

Teensy3 with Windows XP with putty
This combination works fine. HIGH LOW get printed once per second.

But I could not get it working on my Ubuntu 64 box running 12.10. I tried putty, minicom, and gtkterm. All these terminal programs seem to hang - which is likely the same issue with Arduino.
I thought it must be some problem with my linux box, so I tried teensy3 with my raspberry pi. Same problem.

Both the ubuntu and the pi have the following for lsusb:
Bus 001 Device 026: ID 16c0:0483 VOTI Teensyduino Serial
(Full lsusb -v follows at end of post)

Next I tried running my Arduino Mega with the same program on my linux box.
It works fine.

So for some reason, Teensy and Ubuntu, or Teensy and Pi don't quite get along.


lsusb -v returns:

Bus 001 Device 026: ID 16c0:0483 VOTI Teensyduino Serial
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x16c0 VOTI
idProduct 0x0483 Teensyduino Serial
bcdDevice 1.00
iManufacturer 1 Teensyduino
iProduct 2 USB Serial
iSerial 3 12345
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 1
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 64
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
 
Just to make sure I wasn't doing something foolish, I tried the simple sketch below:
/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.

This example code is in the public domain.
*/

// Pin 13 has an LED connected on most Arduino boards.
// Pin 11 hes the LED on Teensy 2.0
// Pin 6 hes the LED on Teensy++ 2.0
// give it a name:
int led = 13;

// the setup routine runs once when you press reset:
void setup() {
// initialize the digital pin as an output.
Serial.begin(9600);
pinMode(led, OUTPUT);
}

// the loop routine runs over and over again forever:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
Serial.println("HIGH");
delay(200); // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
Serial.println("LOW");
delay(1000); // wait for a second
}

Basically the same thing.
Build and load on Teensy using Ubuntu and putty - fails to work.
Build and load on Mega using Ubuntu and putty - HIGH LOW gets printed.
Move Teensy3 over to my XP laptop with putty - works.

Stumped.
 
I'm on a 64 bit RHEL6.3 clone. I tried your last example and no problem whatsoever. I tried both Tools -> Serial Monitor from the Arduino IDE, and minicom, with no problem. It's not clear to me why you say "the development environment" hangs if you are using putty at runtime. Can you clarify when you start your serial program? Before or after you download the program? And one other question: which driver is in use for the particular USB port you are using on the linux machine? Is it USB2 or USB3? And is it compiled into the kernel or is it a loadable module? I have a method to the madness of my questions and can explain if the answers indicate I might be on to something.

Clarification: contrary to the comments, but true to the actual code, the blink is 1/5 second on and 1 second off.
 
I think I've figured out what is making the dev environment hang. Something is making my teensy code crash (still haven't figured out what, but it seems to be a run-of-the-mill heap corruption problem). When that happens, if I try to send a character to the (now crashed) teensy through the serial console that is what causes the Arduino environment to hang. I'm guessing that the dev environment is waiting for some kind of handshake that the crashed teensy is no longer providing.
 
OK, I've got this 100% figured out now. It wasn't heap corruption. I was nuking the stack. Here's a self-contained sketch that will reproduce the problem:

Code: 
void foo(int* x) {
  Serial.println("Hello world");
  x[2]=0; // Blast the stack
  Serial.println("Still alive");
  delay(10);  // Wait for I/O to finish
  Serial.println("Still alive, but not for long");
}

void baz() {
  int x[1];
  foo(x);
}

void setup() {
  Serial.begin(0);
  while (!Serial.available()) delay(1); // Wait for a keypress
  baz();
  Serial.println("Dead!");
}

void loop() {}

This will print "Hello world" and "Still alive" and then hang. While it's hung, if you try typing something into the serial console, the IDE will hang.
 
Lisper,
Glad you found your problem - clearly different that what I am experiencing.

fnj,
Re: "the development environment hangs"
I can either use the serial monitor in arduino or use putty to monitor serial input. If I use the serial monitor in arduino with teensy on my Ubuntu 12.04 box, the Arduino development environment hangs. I have to kill it and restart it to get it working again.
If I use putty, putty just stops working.

Serial program (putty, minicom, etc.) is started after program is downloaded. I think it pretty much has to, otherwise /dev/ttyACM0 is not available and the serial programs would fail to start.

The USB driver is the cdc_acm driver. This is true for both the mega board and the teensy. I am plugged into a USB2 port.

Some extra info:
dmesg when arduino mega is inserted:

[67213.572749] usb 1-1.4: new full-speed USB device number 6 using ehci_hcd
[67213.667504] usb 1-1.4: New USB device found, idVendor=2341, idProduct=0042
[67213.667509] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[67213.667511] usb 1-1.4: Manufacturer: Arduino (www.arduino.cc)
[67213.667514] usb 1-1.4: SerialNumber: 7493430303035121C1D2
[67213.667984] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device

dmesg when teensy is inserted:

[67290.809750] usb 1-1.4: new full-speed USB device number 7 using ehci_hcd
[67290.903505] usb 1-1.4: New USB device found, idVendor=16c0, idProduct=0483
[67290.903509] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[67290.903512] usb 1-1.4: Product: USB Serial
[67290.903514] usb 1-1.4: Manufacturer: Teensyduino
[67290.903517] usb 1-1.4: SerialNumber: 12345
[67290.903933] cdc_acm 1-1.4:1.0: This device cannot do calls on its own. It is not a modem.
[67290.903997] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device

oddly I get the "This device cannot do calls on its own ... " with Teensy.
Not sure what that means.

Thanks a lot for trying the program on Redhat 64. At least it does not appear to be a 64 bit problem which was something I was pondering. I'm going to try installing Ubuntu 12.10 on another box I have here just to verify that it is not some incompatibility with my motherboard (but not sure how that could be otherwise my arduino Mega should fail as well.)

Re: the 1 second thing - yeah, I change the timing each time I change the program just to make sure that the new program is loaded. Without serial working the only indicator I have is the flashing light. :)


Rob
 
RobM, thanks for the info. Just to add to the saga, I'm pretty bummed right now. I just had my ENTIRE 64 BIT RHEL6.3 SYSTEM with 12GB of apps running freeze up solid while running the Arduino IDE. No mouse, keyboard dead, no disk activity, power button wouldn't shut down gracefully which means ACPI was dead, system could still be pinged but no ssh could log in remotely to try to save it. It's too much of a coincidence to overlook. To be fair, this has happened (very rarely) in the past in completely different scenarios. There is an idea in my mind that OpenJDK (which Arduino uses) is capable of doing that which should be impossible for any app - lock up an entire professional OS.

I had to do a hard power off to recover and reboot by holding the power switch down for five seconds.
 
Bummer.

More to the saga.

I installed Ubuntu 12.10 on another computer, booted, tried to run the same program with Teensy and it failed with the same problem.

So I decided to try a completely different distribution - I went with CentOS, booted, and lo and behold it worked. So it is something quirky with Ubuntu 12.10 and Teensy and the usb serial driver.

dmesg on CentOS produces exactly the same results including the
"This device cannot do calls on its own..." so that is just a red herring.
 
The message "This device cannot do calls on its own..." is a filter that is in there where something decides that NetworkManager cannot use the device as a mobile broadband connection.

The message of mine that got lost was just saying I believe you are going to see freeze-ups sooner or later, no matter what distro you use. CentOS is an excellent one, same codebase as the distro I use, but I have seen freezeups on it.
 
Last edited:
Here's the message that disappeared.

RobM, thanks for the info. Just to add to the saga, I'm pretty bummed right now. I just had my ENTIRE 64 BIT RHEL6.3 SYSTEM with 12GB of apps running freeze up solid while running the Arduino IDE. No mouse, keyboard dead, no disk activity, power button wouldn't shut down gracefully which means ACPI was dead, system could still be pinged but no ssh could log in remotely to try to save it. It's too much of a coincidence to overlook. To be fair, this has happened (very rarely) in the past in completely different scenarios. There is an idea in my mind that OpenJDK (which Arduino uses) is capable of doing that which should be impossible for any app - lock up an entire professional OS.

I had to do a hard power off to recover and reboot by holding the power switch down for five seconds.
 
I believe there are 2 very different things going on here.

The IDE lockup on Macos makes sense. It's probably a bug in librxtx, not properly handling the case where the device stops accepting new data. That rxtx library has a long history of bugs, especially on macos. Why the entire process locks up, when only 1 thread ought to be impacted, is a *very* good question. Maybe a java bug? I just don't know. If anyone wants to really go after this, I'll help, but getting patches accepted to the rxtx library is a nightmare (not to mention the rxtx code itself).

The Linux system crash is likely something completely different. The sad news is a complete system lockup must be a kernel bug or computer hardware problem. I'm running Ubuntu 12.04 64 bit here and I've never seen this lockup. I might try setting up a 12.10 machine for testing, but with all the changes happening in Unity & Gnome 3, I'm reluctant to mess with my working 12.04 system running Gnome panel and other "classic" gnome stuff that works the way I expect.

The "This device cannot do calls on its own..." kernel message is merely based on parsing a couple bits from one of the USB descriptors. In Teensy, I set those bits to indicate the Teensy USB Serial is not a traditional modem. Both Linux and Macos have a long history of mistaking Teensy (and lots of other devices) as modems to trying to run middleware that interferes with Arduino and other software you would want to use.

Some time ago, I (and many others) had a lengthy exchange with Apple regarding their network configuration dialog automatically appearing when USB CDC-ACM protocol devices are used. When the user plugs in a modem, obviously you want that dialog to appear. But for a Teensy or Arduino or other similar board, getting the network settings dialog is confusing. I brought up Linux's "cannot do calls on its own" message, which somehow drew a couple Linux activists and the kernel developers into the conversation. Apple has been sympathetic to the usability issue, but several people with Apple insisted they would not allow any avoidance of the modem config that was not strictly compliant with the published USB standards. Much heated discussion about the USB communication class standard occurred. Ultimately it was agreed the Linux kernel developers' interpretation was correct, that a certain bit in the device's data could be relied upon to know if the device is not a modem. Apple added a patch to 10.7.2 to avoid showing that modem config if the descriptor bits are set a certain way.

Redhat's Gnome Modem Manager also has a long and buggy history of interfering with Teensy and LOTS of other USB devices. As you can see in the udev rule comments, those issues are largely in the past since Ubuntu 10. Over the years, I exchanged several emails with the guy at Redhat who wrote the modem manager.... and he always seemed to lose or forget about these problems every time he updated the code. Finally, so many bugs piled up on Redhat's bug tracker that he redesigned the modem manager to be much more cautious and to check for a ID_MM_DEVICE_IGNORE environment variable from udev.

It's still not clear (at least to me) if the modem manager takes that kernel info into account, but honestly, since things started working reasonably well around 2010 I haven't really looked.

Anyway, the thing to remember about the "This device cannot do calls on its own..." is it's merely based on the value of bit in one of the descriptors used to detect the device.
 
I have confirmed that the usb serial does not seem to work on Ubuntu 12.10 on two different computers, but Arduino Mega does work on these same computers.
I have tested Teensy3 on CentOS, Mint, and Redhat EL - these all seem to work. I will give Ubuntu 12.04 a try when I get home tonight. If it works on 12.04 I will downgrade my 12.10 development machine to 12.04. I probably should have never ventured into the Unity world anyways. :)

Note that I don't experience complete Arduino lockup, rather the device /dev/ttyACM0 is failing to open (on Ubuntu 12.10 and Teensy) which causes a problem with the Arduino Serial Monitor (effectively a lockup.) I agree that this issue is very different than fnj's issue. It sort of seemed the same from the original poster's remarks but further investigation led to the divergent paths.

Rob
 
I am running (x)ubuntu 12.10 64 bit and it is working fine with a teensy3. I had to deinstall the modemmanager package. I saw some strange entries in the system log "try nokia modem..... try modem...."
Joerg
 
mercapto said:
I am running (x)ubuntu 12.10 64 bit and it is working fine with a teensy3. I had to deinstall the modemmanager package. I saw some strange entries in the system log "try nokia modem..... try modem...."
Joerg
Click to expand...

Thanks mercapto, much appreciated. I will give that a try when I get home tonight.

Rob
 
An excellent explanation, Paul. I'm going to stick my neck out and say I've seen rxtx lock up both OS X and Windows XP solid as well as linux. I agree fully that rxtx is trouble, but I'm not willing to make them the fundamental goat. All they are doing is calling system drivers for the serial ports, and those drivers should not have such such a gaping vulnerability. OTOH, I've been around long enough to know that serial ports are an absolute bear to work with. Bottom line: the system is unequivocally at fault for letting itself be deadlocked in entirety by a userland app, but the customer sees a frozen system following the use of that userland app, and guess who he blames? Heh, I've been on both sides of this one.

True story: you can screw any linux system if you open any serial port with hardware handshake enabled; the connected device at some point fails to hardware handshake for whatever reason; you have outgoing data queued that cannot be sent because the device won't accept it; and you then kill the process. You end up with a zombie process that won't die and has the serial port tied up, and a serial port which is stuck in limbo. The server remains running just fine, but you need to use that port. So sorry. The only way to get it back is a reboot. Not cool at all on a mission critical customer-facing server.

A savvy designer who sees that hardware handshake on a serial port has been specified/implemented since time immemorial as having INFINITE timeout just shakes his head at the craziness, but there's nothing an app can do; it's in the system.

That's just an aside, of course. What I'm going to move to, and recommend for anyone, is to have a modest dedicated system just to run the rxtx program (i.e., the Arduino environment). This can be a VERY modest box. You could even run the Arduino environment via networked X protocol transparently on your "real" computer. This way, you don't have every piece of data that belongs to your life at risk every time you reach for that reset button or power switch, and you won't have a very heavy duty system taking forever to reboot and restore your whole set of umpteen apps open and doing what they were doing when rudely interrupted.
 
*sigh* I had hoped the Gnome Modem Manager problems would stay in the past. The ENV{ID_MM_DEVICE_IGNORE}="1" stuff in the udev rule was supposed to be a permanent fix for the modem manager interference. Given its tremendous number of bugs over the years, I wouldn't be surprised if they've redesigned it yet again, reintroducing all the old problems yet another time!
 
Teensy 2.0 has serial emulation when you select a non-serial option from the Tools > USB Type menu. I'm working on adding that to Teensy 3.0 right now... I've got it basically working now and I intend to release beta8 very soon.

When using the serial emulation, the rxtx library is not used at all. The serial emulation lets you still use Serial.print() to the Arduino Serial Monitor.
 
mercapto said:
I am running (x)ubuntu 12.10 64 bit and it is working fine with a teensy3. I had to deinstall the modemmanager package. I saw some strange entries in the system log "try nokia modem..... try modem...."
Joerg
Click to expand...

Many thanks Joerg - that solved my problem.
 
I have found this thread only after tearing my hair off and finding the solution on my own. The catch is that you have to unplug and plug the device after disabling modem-manager, because the MM apparently managed to hose the port somehow. It's broken on Ubuntu Precise and Quantal, while Lucid works normally.
 
I'm running Ubuntu 12.04 LTS (64-bit), and I think I am seeing something similar to this.

Everything has been working fine for awhile, but I've been working on a sketch that uses serial. When I run my bug-ridden sketch the tty_ACM0 seems to get locked. After awhile my computer crashed. It could get a remote ssh login prompt but couldn't log in. Unplugging does not release it.

Mar 25 10:22:40 linuxoc mtp-probe: bus: 5, device: 11 was not an MTP device
Mar 25 10:23:07 linuxoc kernel: [ 400.929248] usb 5-3: USB disconnect, device number 11
Mar 25 10:23:08 linuxoc kernel: [ 401.568100] usb 5-3: new full speed USB device number 12 using ohci_hcd
Mar 25 10:23:08 linuxoc mtp-probe: checking bus 5, device 12: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-3"
Mar 25 10:23:08 linuxoc mtp-probe: bus: 5, device: 12 was not an MTP device
Mar 25 10:23:08 linuxoc kernel: [ 401.735335] generic-usb 0003:16C0:0478.0008: hidraw3: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:13.0-3/input0
Mar 25 10:23:08 linuxoc kernel: [ 402.225071] usb 5-3: USB disconnect, device number 12
Mar 25 10:23:09 linuxoc kernel: [ 402.856086] usb 5-3: new full speed USB device number 13 using ohci_hcd
Mar 25 10:23:09 linuxoc mtp-probe: checking bus 5, device 13: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-3"
Mar 25 10:23:09 linuxoc kernel: [ 403.037141] cdc_acm 5-3:1.0: This device cannot do calls on its own. It is not a modem.
Mar 25 10:23:09 linuxoc kernel: [ 403.037184] cdc_acm 5-3:1.0: ttyACM0: USB ACM device
Mar 25 10:23:09 linuxoc mtp-probe: bus: 5, device: 13 was not an MTP device
Mar 25 10:23:19 linuxoc kernel: [ 413.080804] usb 5-3: USB disconnect, device number 13
Mar 25 10:23:20 linuxoc kernel: [ 413.740087] usb 5-3: new full speed USB device number 14 using ohci_hcd
Mar 25 10:23:20 linuxoc mtp-probe: checking bus 5, device 14: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-3"
Mar 25 10:23:20 linuxoc kernel: [ 413.906701] generic-usb 0003:16C0:0478.0009: hidraw3: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:13.0-3/input0
Mar 25 10:23:20 linuxoc mtp-probe: bus: 5, device: 14 was not an MTP device
Mar 25 10:23:21 linuxoc kernel: [ 414.533095] usb 5-3: USB disconnect, device number 14
Mar 25 10:23:21 linuxoc kernel: [ 415.168097] usb 5-3: new full speed USB device number 15 using ohci_hcd
Mar 25 10:23:22 linuxoc mtp-probe: checking bus 5, device 15: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-3"
Mar 25 10:23:22 linuxoc kernel: [ 415.344561] cdc_acm 5-3:1.0: This device cannot do calls on its own. It is not a modem.
Mar 25 10:23:22 linuxoc kernel: [ 415.344607] cdc_acm 5-3:1.0: ttyACM1: USB ACM device
Mar 25 10:23:22 linuxoc mtp-probe: bus: 5, device: 15 was not an MTP device
Mar 25 10:23:22 linuxoc modem-manager[998]: <info> (ttyACM1) opening serial port...
Mar 25 10:23:25 linuxoc kernel: [ 418.889211] usb 5-3: USB disconnect, device number 15
Mar 25 10:23:25 linuxoc modem-manager[998]: <info> (ttyACM1) closing serial port...
Mar 25 10:23:25 linuxoc modem-manager[998]: <info> (ttyACM1) serial port closed
Mar 25 10:23:26 linuxoc kernel: [ 419.516092] usb 5-3: new full speed USB device number 16 using ohci_hcd
Mar 25 10:23:26 linuxoc mtp-probe: checking bus 5, device 16: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-3"
Mar 25 10:23:26 linuxoc kernel: [ 419.682898] generic-usb 0003:16C0:0478.000A: hidraw3: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:13.0-3/input0
Mar 25 10:23:26 linuxoc mtp-probe: bus: 5, device: 16 was not an MTP device
Mar 25 10:23:27 linuxoc kernel: [ 420.305396] usb 5-3: USB disconnect, device number 16
Mar 25 10:23:27 linuxoc kernel: [ 420.936089] usb 5-3: new full speed USB device number 17 using ohci_hcd
Mar 25 10:23:27 linuxoc mtp-probe: checking bus 5, device 17: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-3"
Mar 25 10:23:27 linuxoc kernel: [ 421.112683] cdc_acm 5-3:1.0: This device cannot do calls on its own. It is not a modem.
Mar 25 10:23:27 linuxoc kernel: [ 421.112729] cdc_acm 5-3:1.0: ttyACM1: USB ACM device
Mar 25 10:23:27 linuxoc mtp-probe: bus: 5, device: 17 was not an MTP device
Click to expand...
 
Status
Not open for further replies.
Back
Top