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 | mhw@WittsEnd.com /\/\|=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!