Sharron,
I hope you don't mind, but I've added the Linux Kernel developers
list to the Cc on this list in a effort to get this patch integrated into
the 2.4 kernel. The patch has been languishing for months, now, in
spite of several requests to Marcello.
I also just found out that I had been bounced (again) from the mail
lists at vger (probably an outage at my MX server, again) so I had to
resubscribe. I see from the archives that I missed a couple of Computone
problem reports a while back, as well. All this same problem. :-(
On Tue, Jun 08, 2004 at 01:19:50PM +0200, Sharon wrote:
> Hi,
> I am trying to get a PCI Computone Intellport II card working on Linux 9.0
> (2.4.20-8).
The lastest kernel for RedHat 9 is 2.4.20-31.9. I would
strongly recommend upgrading. There are probably security issues
that need to be addressed.
> I use modprobe ip2 irq=0 io=1 and the board flashes green.
First recommendation. Please do not set irq=0. That places
that board (your first and, maybe, only board) in polling mode. Polling
mode is not well tested, especially with PCI cards (io=1) and may
have some timing problems over and above the known problem. I don't
personally use it. It's really a hold over from old days when the
IRQ subsystem in that driver didn't work very well (before I took over
as maintainer and long before it was included in the kernel source tree).
> When I insert the entries into /etc/inittab and execute init q.
> I get Oops errors. ( if you need the exact error I will copy it for you)
> Do you know if there is a patch that I can load to correct this error? If so
> where do I get it from and how do I load it?
Yes, there is a patch. I've sent it to Marcello several times
now at several of his E-Mail addresses. I don't know if any of them
are still good or if he's just so swamped that he hasn't been able to
look at it. This is a known problem on fast CPU boards. I can go into
a lot of technical details but the bottom line is that the problem has
been known about for a long time. I've sent a patch to everyone reporting
the problem and not a single person has reported any problem with the
patch and several people reported that the Oops error was solved. The
problem only occurs on fast CPUs (>400 MHz and aggravated by SMP)
because of the speed of the CPU in relation to the speed of the processor
on the Computone board itself creating a timing condition and busy board
deadlock condition. The original fix for that problem is what's causing
the Oopps on even faster CPU's.
For some really strange reason, that I've never been able to
ascertain, the Opps problem seems to show up on RedHat kernels but
rarely (I've never seen it) on vanilla kernel.org kernels. What is
the causal agent, there, that's aggravating the problem, I don't know.
Since I haven't been able to catch Marcello's attention, in spite
of my being the official maintainer of this driver, I'm spamming the kernel
mailing list with the patch(s) in the faint hope of catching someone's
attention.
Attached to this message are two flavors of the patch for this
problem. The patch "linux-2.4.22.diff" actually patches the RedHat
2.4.20 kernel sources (all flavors) perfectly. I've checked it against
2.4.20-30.9 and it patched cleanly with no fuzz or offsets. Please try
that. Just cd into the kernel source directory and apply it with a
"patch -p1 < .../linux-2.4.22.diff" and then rebuild your custom kernel.
The other patch, patch-2.4.26ct.diff, is the diff against the
2.4.26 kernel source tree. Will someone PLEASE integrate this into the
sources or at least tell me why they can't? I've been requesting this
since the 2.4.22 sources, and it still hasn't been integrated and I
haven't heard a peep about why or why not. I can only assume that
the direct E-Mail messages never got read.
> I would also like to know how I can change the device names to be preceded
> with 00. In other words I require that they get sorted as
> F000,F001,F002,F003,F004 .. F010,F011 and not F0,F1,F10,F11
> ...F2,F22,F23....etc because the device names are not sorted numerically
> correctly with the physical positions on the 16 port Clusters.
If you are not using devfs, you can do this with a simple shell
script renaming the files in /dev/ttyF*. If you are using devfs, I would
recommend strongly against it. With devfs, you would be better off
creating symlinks from somewhere else. That being said, I usually
advise against people "prettying things up" like this. In this particular
case, it makes no difference, since the names are just strings (with
devfs, they are actually in the source code, though). I've seen people
make the mistake of doing this with IP addresses and getting royally
burned when they discover that 010.000.000.001 != 10.0.0.1 and is really
8.0.0.1 (010 is octal and equal to 8 decimal). It certainly shouldn't
do any harm to rename the character device files in /dev to whatever
convention you desire.
> Thanks
> Sharon
Sorry for the problem. Let me know how the patch works out!
Thanks!
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!