Baud rate switches cause driver hangs in the kernel.

William_McGovern · July 11, 2011, 9:22pm

I am using the Plugable USB->RS232 with driver version 1.40 on Mac OS X Snow Leopard 10.6.7 on an Intel Macbook Pro (Core i5 processor ) and have been experiencing driver hangs when switching baud rates on the external device.

I have a device that uses a serial console and boots at 115,200 baud and then later switches to 9600 baud (unfortunate behavior, but it is what it is at the moment). I am using the common minicom utility to monitor the serial console through the via the plugable driver.

The plugable device and driver work perfectly as long as I don’t try to switch baud rates (by terminating the connection with minicom and then reconnect using the new baud rate). When I switch the baud rate from 115200 to 9600 the Plugable driver hangs in the kernel and requires a hard power cycle of the system (Macbook Pro) to recover.

Any ideas on how to work around or fix this issue?

Lampros_Chaidas · July 11, 2011, 11:29pm

Hi William!

Thanks for posting and sorry to hear you’ve been having trouble with our Plugable USB to RS-232 adapter!

First, we tested the adapter with ZTerm. We’re trying to follow the same steps, this is our setup:
Macbook Core Duo running Mac OS X 10.6.7, the other side is running Win 7 Pro. On each side there is a Plugable USB to Serial Adapter, in the middle a null-modem cable.

Connect to the Win 7 computer at 9600 baud. No problem.
On both sides changed rate to 115200 baud. No problem.

Then we tried the same with minicom. No problems so far.
This is what our configuration options look like when running sudo minicom -s
!](https://sslproxy.getsatisfaction.com/sslproxy/SWhAdDNLMG5zdGFuVGlWenmLbJDGd3CABhjZermgcystANA4T6nd0pzV0fSzBRRGOd17A4b8ZLwi6-HESbXI0v7O0kDNIs0OVBs8WzoMHMXq1rbTmP-h5pRlptMIhpMQq1fub3Y1RsXzqkYGKjJ5E_ZL8yRj2IDUwUAqwF7iffk=.png)](http://s3.amazonaws.com/satisfaction-production/s3_images/533284/mac--minicom_settings.png)

What are the configuration options you are using? Are they any different?

What is the output of the command ioreg -c IOSerialBSDClient | grep usb on your system ?

Regards,
Lampros

William_McGovern · July 12, 2011, 1:14am

Wow… fast reply

The configuration I have is follows:

The target system with the serial console is basically a headless Linux server system that has serial console redirection enabled in the BIOS and Linux configured for a serial port console (via /dev/ttyS0). I have a restriction right now that the serial serial console redirection in the BIOS and is fixed at 115200 baud and so all the BIOS output goes out to the serial port. The Linux environment is configured for 9600 baud (I know, I know… don’t ask why and so during the boot the console output from the server switches from 115200 to 9600 baud.

When I see that the boot has reached the point where I know it has switched to 9600 baud, I switch minicom to 9600 baud and I get a non-interruptible hang.

Here are the settings for minicom:

Serial Device: /dev/tty.usbserial
Lockfile Location: /tmp
Callin Program:
Callout Program:
Bps/Par/Bits: 115200 8N1
Hardware Flow Control: No
Software Flow Control: No

I’ve also reproduced this hang behavior using the “screen” program with these commands:

screen /dev/tty.usbserial 115200

screen /dev/tty.usbserial 9600

I don’t have access to the system to get the ioreg output at the moment but I’ll send it out first thing tomorrow.

Thanks again for the fast response!

~ Will

Lampros_Chaidas · July 12, 2011, 4:48pm

Hi William!

Thanks for the very detailed reply!

The settings we have used in the screenshot above, are based on the output of the ioreg -c IOSerialBSDClient | grep usb command. So far, we haven’t seen any crashes or any other instability. It would be worth trying to use the output of that command in your minicom settings and see if it makes a difference.

The BIOS setting that you use - does it affect the whole system or is it solely for the BIOS itself? On that note, can you give us the make/model of the main board (or even better a link to the manual so we can study it)

And of course we have to ask: Will it cause problems if you switch the Linux system to 115200 baud ? :)

Could you also try the same thing with ZTerm? as ZTerm doesn’t require manual configuration, maybe the settings make a difference?

One more thing - on the Mac, when you go to ‘System Preferences’->‘Network’->click on the ‘+’ sign on the bottom left, and then on the ‘Select the interface and enter a name for the new Service’ click on ‘Interface’ – you should be seeing the ‘USB-Serial Controller D’ there. Should look something like this:
!](https://sslproxy.getsatisfaction.com/sslproxy/SWhAdDNLMG5zdGFuVGlWenar5LbrtG5uQdJhvnMZ-SujIWTcSz2OAdpzYOSIMvO56Zhm0f0u-QoY3HCrYL6aA5BB43r5R2Fy7ETVo5aiIDE=.png)](http://plugable.com/wp-content/uploads/2011/06/22.png)
Is that entry there?

Once we have this information we can suggest next steps!

Regards,
Lampros

William_McGovern · July 13, 2011, 1:40am

Here is the output of ioreg:

Here was the full output for the device:

| | | ±o USB-Serial Controller D@fd130000
| | | ±o IOUSBCompositeDriver
| | | ±o IOUSBInterface@0
| | | ±o com_prolific_driver_PL2303
| | | {
| | | “IOClass” = “IOSerialBSDClient”
| | | “CFBundleIdentifier” = “com.apple.iokit.IOSerialFamily”
| | | “IOProviderClass” = “IOSerialStreamSync”
| | | “IOTTYBaseName” = “usbserial”
| | | “IOSerialBSDClientType” = “IORS232SerialStream”
| | | “IOProbeScore” = 1000
| | | “IOCalloutDevice” = “/dev/cu.usbserial”
| | | “IODialinDevice” = “/dev/tty.usbserial”
| | | “IOMatchCategory” = “IODefaultMatchCategory”
| | | “IOTTYDevice” = “usbserial”
| | | “IOResourceMatch” = “IOBSD”
| | | “IOGeneralInterest” = “IOCommand is not serializable”
| | | “IOTTYSuffix” = “”
| | | }

The BIOS setting only affects the output of BIOS up until the operating system boot loader takes control, at which time it switches to 9600 baud and all the OS console boot messages get spewed out at 9600.

Afraid I cannot identify the motherboard because it is a custom board with customized BIOS. There are limitations in our setup that require that the OS run with 9600 baud, but currently the BIOS is fixed at 115200. Quite annoying

I checked the System Preferences and yes, “the USB-Serial Controller D” entry exists in the pulldown you highlight and also in the left sidebar with the other network interfaces listed (AirPort, etc.).

!](https://sslproxy.getsatisfaction.com/sslproxy/SWhAdDNLMG5zdGFuVGlWenmLbJDGd3CABhjZermgcystANA4T6nd0pzV0fSzBRRGOd17A4b8ZLwi6-HESbXI0mfcGfs3xaW8CqYtCEZXRMJ2IMv7QKvt4wZk5RFlCyxF3R8L5A7_Jzrhx67mMybbCLXLXMXcgDbv6OcCzlNrnM_Vng3HFf7buPJpo1mJqyXT.png)](http://s3.amazonaws.com/satisfaction-production/s3_images/534416/Screen_shot_2011-07-12_at_6.18.49_PM.png)

Lampros_Chaidas · July 13, 2011, 5:56pm

Hi Will!

Again thanks for all the detailed information. We have a couple of questions and a couple of things to try:

Did you ever previously have a different USB to Serial adapter ? If yes, were the previous drivers uninstalled ?
Could you get us the logs of the kernel panic? Please zip them up and send them to support@plugable.com . They are located under /Library/Logs/DiagnosticReports

Between changing the baud rate - can you try to unload and reload the Prolific kernel extension?

This is what we’re thinking:

Connect at 115200 for the BIOS using Minicom
Exit Minicom, (make sure it’s not running in the background),
Type the following to unload the kext:
sudo kextunload /System/Library/Extensions/ProlificUsbSerial.kext
Then reload it with:
sudo kextload /System/Library/Extensions/ProlificUsbSerial.kext
Start Minicom, change the baud rate to 9600 and connect - does the problem persists?

Thank you for your patience while we’re trying to figure this out!

Regards,
Lampros

William_McGovern · July 19, 2011, 12:34am

Hi Lampros,

Sorry for the delay getting back to you. When I get the hang it does not panic the kernel… just hangs the process. I just tried something interesting which seems to give a very similar kind of hang. I did this with no device plugged into the adapter:

$ echo “hello” > /dev/tty.usbserial

I then try to start minicom in a separate shell and it hangs on init. Here is the sample I got from Activity Monitor of minicom in a hung state:

Sampling process 8550 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols…
Analysis of sampling minicom (pid 8550) every 1 millisecond
Process: minicom [8550]
Path: /opt/local/bin/minicom
Load Address: 0x100000000
Identifier: minicom
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: bash [8531]

Date/Time: 2011-07-18 17:22:35.846 -0700
OS Version: Mac OS X 10.6.8 (10K540)
Report Version: 7

Call graph:
2629 Thread_192217 DispatchQueue_1: com.apple.main-thread (serial)
2629 start
2629 main
2629 open_term
2629 open

Total number in stack (recursive counted multiple, when >=5):

Sort by top of stack, same collapsed (when >= 5):
open 2629

Binary Images:
0x100000000 - 0x100024fe7 +minicom (??? - ???) /opt/local/bin/minicom
0x100033000 - 0x10003cfef +libintl.8.dylib (10.1.0 - compatibility 10.0.0) /opt/local/lib/libintl.8.dylib
0x100042000 - 0x10013efef +libiconv.2.dylib (8.0.0 - compatibility 8.0.0) /opt/local/lib/libiconv.2.dylib
0x10014b000 - 0x100192fe7 +libncurses.5.dylib (5.0.0 - compatibility 5.0.0) /opt/local/lib/libncurses.5.dylib
0x7fff5fc00000 - 0x7fff5fc3bdef dyld (132.1 - ???) /usr/lib/dyld
0x7fff80fff000 - 0x7fff811bdfff libicucore.A.dylib (40.0.0 - compatibility 1.0.0) /usr/lib/libicucore.A.dylib
0x7fff83981000 - 0x7fff83985ff7 libmathCommon.A.dylib (315.0.0 - compatibility 1.0.0) /usr/lib/system/libmathCommon.A.dylib
0x7fff83986000 - 0x7fff83afdfe7 com.apple.CoreFoundation (6.6.5 - 550.43) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff84305000 - 0x7fff844c6fef libSystem.B.dylib (125.2.11 - compatibility 1.0.0) /usr/lib/libSystem.B.dylib
0x7fff85eb8000 - 0x7fff85f04fff libauto.dylib (??? - ???) /usr/lib/libauto.dylib
0x7fff86bcf000 - 0x7fff86c85ff7 libobjc.A.dylib (227.0.0 - compatibility 1.0.0) /usr/lib/libobjc.A.dylib
0x7fff87f83000 - 0x7fff87f94ff7 libz.1.dylib (1.2.3 - compatibility 1.0.0) /usr/lib/libz.1.dylib
0x7fff88705000 - 0x7fff88782fef libstdc++.6.dylib (7.9.0 - compatibility 7.0.0) /usr/lib/libstdc++.6.dylib
0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib (??? - ???) /usr/lib/libSystem.B.dylib
Sample analysis of process 8550 written to file /dev/stdout

I then tried to unload the driver but looks like a reference was still being held:

$ sudo kextunload /System/Library/Extensions/ProlificUsbSerial.kext
Password:
(kernel) Can’t unload kext com.prolific.driver.PL2303; classes have instances:
(kernel) Kext com.prolific.driver.PL2303 class PL2303SerialDriverBase has 1 instance.
(kernel) Kext com.prolific.driver.PL2303 class com_prolific_driver_PL2303 has 1 instance.
Failed to unload com.prolific.driver.PL2303 - (libkern/kext) kext is in use or retained (cannot unload).

Interestingly enough, this caused the hung minicom process to terminate. But the driver is still loaded and in a hung state.

I also saw this in the system logs as well during my kext load/unload:

7/18/11 5:31:36 PM kernel USBF: 32237. 69 AppleUSBHubPort: Port 4 of Hub at 0xfa100000 about to terminate a busy device (USB-Serial Controller D) after waiting 10 seconds
7/18/11 5:31:51 PM kernel USB-Serial Controller D::terminate(kIOServiceSynchronous) timeout

Hopefully that gives you some more information to go on

~ Will

Lampros_Chaidas · July 20, 2011, 7:06pm

Hi Will,

Thank you for your reply and sorry it took so long to reply to you. We did some research and have some interesting findings which will hopefully help (Our apologies in advance - unfortunately this post will be rather long) :

Indeed we tried the:
echo "hello" \> /dev/tty.usbserial
And trying to start minicom on another terminal window caused it to freeze upon loading, specifically this is what it displays (let us know if you see the same thing)

LANG/ja   
LANG/ko   
LANG/ru

and nothing else.

Trying to stop the echo "hello" \> /dev/tty.usbserial proved to be really hard. (Again let us know your experiences on this). By closing the Terminal Window (by clicking the red X button) proved to be almost catastrophic. After that we could see the minicom process hanging and even doing a kill -9 644 (where 644 the process id of minicom) would not help.

Indeed at this point only a restart helped. Unloading and reloading the prolific text didn’t help either.

However we also tried this: (after restarting of course)
Run the echo "hello" \> /dev/tty.usbserial but with the adapter connected to a null modem to another adapter. Once we started HyperTerminal on the other side and “connected”, immediately control was returned to us in the terminal window where we typed the echo "hello" \> /dev/tty.usbserial . We conclude that it seems that echo will freeze the terminal window and will not relinquish control of the device until the system is restarted or until it gets a response from the other side.

We moved on to test the screen commands:
screen /dev/tty.usbserial 115200
We then exited screen without the proper Ctrl+A Ctrl+\ method - instead we just closed the terminal window.
On a new window starting minicom resulted in: (again please let us know if you’re getting different things)

LANG/ja   
LANG/ko   
LANG/ru   
Lockfile is stale. Overriding it..   
minicom: cannot open /dev/tty.usbserial: Resource busy

Same thing by trying to restart screen:
Cannot open line '/dev/tty.usbserial' for R/W: Resource busy
By typing top we could see that the ‘screen’ process was still running with id 172. We proceeded to kill it kill 172 and tried minicom again - minicom worked without any problem.

So our conclusion so far is, that it seems to be of great importance how the previous programs are terminated. Minicom for example has a ‘eXit and reset…X’ option, which will cause minicom to close and reset the device.

Screen has the Ctrl+A Ctrl+\ method.
So at this point, our only guess is that the program was not previously exited in the expected way. Please let us know if we are wrong in our assumption and we will gladly continue to investigate, although at this point we aren’t sure if we are actually going to find a solution.

Can you confirm our findings?

Thank you so much for your patience through this troubleshooting progress - however if this is becoming too much, we can of course offer a refund.

Regards,
Lampros