Red Hat Bugzilla – Bug 155263
using io_ti makes kernel hang
Last modified: 2007-11-30 17:07:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Description of problem:
Using the module ti_io for the Inside Out Networks Edgeport/4 multi-RS232 USB adapter in all the latest kernels for RedHat 3, for x86-64, the kernel hangs when doing something simple as "echo ATZ > /dev/ttyUSB0". Using Minicom to connect to the /dev/ttyUSB* ports also makes the kernel hang.
When I use the latest kernel (as advised by Greg Kroah), which is 2.4.30 at this moment, it DOES work.
Version-Release number of selected component (if applicable):
kernel-2.4.21-27 kernel-2.4.21-27.0.2, kernel-2.4.21-31
Steps to Reproduce:
1. Connect an Inside Out Networks Edgeport/4 USB multi-serial adapter
2. Connect some serial device (external modem in my case) to it
3. check if the io_ti module has loaded
4. communicate over one of the /dev/ttyUSB[0-3] ports to the serial device
Actual Results: Computer (kernel) crashes, no response anymore whatsoever.
Expected Results: Minicom should have let me do "atz" and the external modem should have responded with "OK".
This does work with the 2.4.30 kernel.
The io_edgeport module does nothing. The io_ti module twice discovers 2 ports:
usbserial.c: USB Serial support registered for Edgeport TI 1 port adapter
usbserial.c: USB Serial support registered for Edgeport TI 2 port adapter
usbserial.c: Edgeport TI 2 port adapter converter detected
usbserial.c: Edgeport TI 2 port adapter converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
usbserial.c: Edgeport TI 2 port adapter converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
usbserial.c: Edgeport TI 2 port adapter converter detected
usbserial.c: Edgeport TI 2 port adapter converter now attached to ttyUSB2 (or usb/tts/2 for devfs)
usbserial.c: Edgeport TI 2 port adapter converter now attached to ttyUSB3 (or usb/tts/3 for devfs)
io_ti.c: Edgeport USB Serial Driver v0.2
The io_edgeport only gives:
usbserial.c: USB Serial support registered for Edgeport 1 port adapter
usbserial.c: USB Serial support registered for Edgeport 2 port adapter
usbserial.c: USB Serial support registered for Edgeport 4 port adapter
usbserial.c: USB Serial support registered for Edgeport 8 port adapter
io_edgeport.c: Edgeport USB Serial Driver v2.3
but doesn't let me communicate via /dev/ttyUSB[0-3].
Hello, Gerben. I'm confused by this bug report, because you've indicated
that this problem no longer exists with the U5 beta kernel. Should I just
move this bug into MODIFIED state and notate when we already fixed the bug?
This is specific to io_ti, so I need more data. First, we have to determine
if this is a hang or oops. Requestor, please reproduce this with the system's
console in text mode (with minicom running from a remote login); let us know what
the last messages are and if keyboard works after the hang (can NumLock be
Gerben, please ignore my comment #2. Pete has clarified that the 2.4.30
refers to the upstream kernel (not the RHEL3 2.4.21-30.EL kernel as I had
I booted the machine and started minicom from a remote login. The display still
showed the usual login prompt, no extra messages. No key on the keyboard works,
crtl-alt-del doesn't do anything and NumLock doesn't work either.
Thanks, that clears things. Please add "nmi_watchdog=1" to the kernel
parameters in /boot/grub/grub.conf. The documentation claims that it's on
by default, but let's be sure. Also, is this a USB keyboard or PS/2 keyboard?
If the NMI oopser fails, the next step would be to load usbserial with "debug"
parameter (from /etc/modprobe.conf, with "options usbserial debug=1"). Beware
that it produces a lot of output to the console, but it may be necessary to
do "echo 8 > /proc/sys/kernel/printk" to see it.
I added the nmi_watchdog=1 to the kernel but only that didn't give extra info.
Using debug=1 did:
usbserial.c: serial_write_room - port 0
usbserial.c: serial_post_one - port 244 user 0 count -268376018
Oh, and I use a USB keyboard because this system doesn't have PS/2 ports. But
even without this keyboard the system hangs when I use the /dev/ttyUSB* ports,
that is, the network immediately stops working after doing something relating to
the io_ti serial ports.
Can anyone tell me if this bug is still open / active ?
I have to install and deliver my test machine soon so I won't able to quickly
try stuff out with the Edgeport box. The machine which needs the fix is in
production at a customer now, so I can't test there.
The bug is open, but its prospects are dim without possiblity for experimentation.
There is no difference between 2.4.30 and 2.4.21-31.EL which would account for
io_ti working with Marcelo kernel. So, the only thing we know is that someone
overwrites struct usb_serial_port with garbage.
I have another dual Opteron with RHEL3, kernel 2.4.20-31.0.1smp and it also
hangs when doing something like echo "atz" > /dev/ttyUSB0.
Got any ideas on what to try? I'll have this machine for about a week.
I have been getting kernel hangs similar to this using /dev/ttyUSB0.
All systems hanging are dual Opteron.
It hangs 100% of the time as soon as write() is called on:
2.4.21-20.ELsmp x86_64 (RHEL 3 Update 3)
2.4.21-32.ELsmp x86_64 (RHEL 3 Update 5)
It works fine on:
2.4.20-20.8smp i686 (RH80 Psyche)
2.4.21-20.ELsmp i686 (RHEL 3 Update 3)
2.6.9-11.ELsmp x86_64 (RHEL 4 Update 1)
My usb to serial device is:
Products, Cables, USB to Serial (9-pin)
The software reading/writing to /dev/ttyUSB0 is our own dongle code.
The bug title is misleading. Using a usb to serial adapter on an smp x86_64 in
RHEL 3 crashes when the serial port ttyUSBx is accessed.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.