[lkml]   [2000]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectrocketport pci question... it stopped working after 250 days uptime

Hello Kernel people,

I am not subscribed to the kernel mailing list, so please cc responses to me.

We have several linux boxes useing 8 port rocketport pci multiport serial
cards. Earlier last week 3 of them stopped working within a 24 hour period.
These three boxes had similar uptimes (since their last kernel rebuild); 249
days, 248 days, 250 days. Comparing the logs of each box, we saw that each
box's rocketport stopped working after aproximately 248 days 16 hours uptime.

The rocketports are used both for dialin and also to simply take in streams of
data from an audio encoder. The simptoms from dialin were that mgetty could
not initialize the modems (function mg_init_data timed out when waiting for a
read from the tty). The simptoms from the data stream were simply that no
data stream came in... a simple cat on /dev/ttyR0 did not dump any data.

The problem was bypassed by warmbooting (simply running shutdown -r now) the

The hardware are intel pentium pro and intel pentium 2 cpus using brand name
motherboards (tyan). The rocketport cards are "Comtrol RocketPort 8 Oct (rev
4)". They are all running kernel version 2.2.14, with the stock rocketport
driver that comes with it. One of the boxes had the rocketport driver
compiled as a module... unloading and reloading the module had no effect on
the problem.

Checking to see if this bug had been corrected in later versions I compared
the changes in the rocketport code (/usr/src/linux/drivers/char/rocket.c) in
2.2.14 with 2.2.17... the latter only had 2 additional lines calling
wake_up_interruptible(). The 2.2.14 kernel lists the rocketport driver
version as 1.14c. However, comparing it with the 1.14 kernel at it does not appear to match, though some parts are
similar I am not clear where they matched and where they forked. Regardless I
saw no mention of a bug like this being corrected in the HISTORY file that was
with version 1.22 from sourceforge.

I spent a couple hours looking through the rocketport code in the kernel and
could not see where this bug may be caused (I have some background with C but
not much with hacking the kernel). I am not even sure if the bug is with the
hardware, the rocketport driver, or possibly someplace else in the kernel
(doubtful I imagine).

So, my questions are:

- has anyone heard of such a bug before?

- does anyone have any suggestions to find/correct the bug?

- We have another box with the rocketport cards which we exprect to reach
this time limit in the next 48 hours (Dec 1st EST)... what kind of
debugging/analysis could I do to help track where the problem might be?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:49    [W:0.054 / U:5.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site