From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461) Description of problem: Running kernel 2.4.18-5 on an HP netserver 2000lpr. When system is connected to live traffic (40Mb/s), kernel displays message - kernel: NETDEV WATCHDOG: eth2: transmit timed out kernel: eth2: Transmit timed out, status 00000000, resetting... kernel: ec811 35466011 3543c811 354a8811 35445011 36da2011 36db7011 3543c011 36ee3011 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Install kernel 2.4.18-5 2.Install Adaptec DURAlan (Quartet66)NIC and starfire drivers 3.Connect to traffic of about 60Mb/s Additional info:
you are aware that kernel 2.4.18-18.7.x is released as erratum ?
Yes I am, but does this resolve this issue specifically? The reason I ask is because I am running a firewall (Checkpoint NG FP3) on it and they only support kernel 2.4.18-5.
I may I have found a solution to my current problem. It requires that I recompile the kernel but I only have the rpm and no source files. I can't seem to find the source files for the 2.4.18-5 kernel anywhere. Is it possible for you to forward the source files to me. I would really appreciate it. Thank you
Install the kernel-source package, and that will give you source code.
The source RPM are no longer being distributed, I talked to customer support and I was asked to ask for it here. So could you please send me the kernel- source package for 2.4.18-5 or point me to where I can retrieve this package. Thanks for your time.
The "kernel-source" RPM is distinctly different from the source RPM (or SRPM). The kernel source code is the only source code that is distributed with all other RPMs. The same place you got your kernel, you get the kernel-source RPM. Are you saying this is unavailable also? Because that is very strange. (it is normal for the SRPM to be distributed separately, but not the kernel-source RPM)
Low priority; starfire is (for better or worse) not very popular, therefore other bugs are more pressing.
The patch I'm attaching should solve the problem -- which is a race between start_tx() and intr_handler() in updating the (unprotected and useless) tx_full flag. It also fixes a potential memory corruption problem on interface shutdown, when the Rx DMA engine is not turned off and can overwrite random memory. -Ion [starfire driver maintainer] P.S. I found this report accidentally in bugzilla, while searching for some other problem of my own. Cc:'ing me would have been helpful...
Created attachment 89114 [details] minimal patch for the starfire network driver
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/