Bug 67966
| Summary: | (NET 3C59X) Transmit timeouts on eth0 on Dell Inspiron 3500 laptop | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Diego Novillo <dnovillo> |
| Component: | kernel | Assignee: | Jeff Garzik <jgarzik> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | CC: | gowdy, peterm |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-30 15:39:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Diego Novillo
2002-07-04 21:27:35 UTC
>$ lsmod
>Module Size Used by Tainted: P
>cisco_ipsec 364128 0
Does this still happen without binary only modules loaded ?
Yup. I removed the cisco module, restarted the network and 2 hours later I got the exact same timeout. Some more data that may be relevant. I got a new error today that froze evolution's IMAP connections: Jul 10 09:35:03 frodo dhcpcd[1139]: sendto: Socket operation on non-socket Jul 10 09:35:03 frodo dhcpcd[1139]: sendto: Socket operation on non-socket Jul 10 09:35:03 frodo dhcpcd[1139]: dhcpStop: ioctl SIOCSIFADDR: Inappropriate ioctl for device Jul 10 09:35:03 frodo dhcpcd[1139]: dhcpStop: ioctl SIOCSIFFLAGS: Inappropriate ioctl for device The strange thing is that this only happens when I have the laptop plugged in the office (ie, no VPN modules loaded). This never happens at home, where I'm always connected via the VPN running on top of my ADSL provider. This new error doesn't seem to kill dhcpd, it merely confuses clients that have open connections. I get that too once in a while; it actually is a bug in the dhcp server where it gives you a new, different!! ip while you're still using the old one.... As for the 3c59x bug: please try the kernel at http://people.redhat.com/arjanv/testkernels it has a nasty 3c59x bug fixed... The new kernel failed again, unfortunately. Five minutes after rebooting the system. I was downloading the SRPM for the kernel when it happened. Strangely, the download kept going for a while longer and then froze with a new 'NETDEV WATCHDOG: eth0: transmit timed out' message. I can consistently bring the connection down by trying to download the SRPM from your webpage. The only difference between my home and office network is that in the office I'm on a 100Mbit network. Could this be a hardware problem? But this never happened with 7.2 nor when the machine was running Windows 2000. Arjan, I'm also seeing the dhcpcd problem on my Dell Latitude C600, with the mini-PCI 3c556 ethernet 00:10.0 Ethernet controller: 3Com Corporation 3c556 Hurricane CardBus (rev 10) which also uses the 3c59x driver. I don't think it's a server issue; my DHCP server hasn't changed since my laptop was running 7.2, which worked fine. I have a bit more information in my /var/log/messages, perhaps because I'm invoking dhcpcd with -d: Jul 27 03:12:01 prospero dhcpcd[1884]: sendto: Socket operation on non-socket Jul 27 03:12:01 prospero dhcpcd[1884]: sendto: Socket operation on non-socket Jul 27 03:12:01 prospero dhcpcd[1884]: dhcpStop: ioctl SIOCSIFADDR: Inappropriate ioctl for device Jul 27 03:12:01 prospero dhcpcd[1884]: dhcpStop: ioctl SIOCSIFFLAGS: Inappropriate ioctl for device Jul 27 03:12:01 prospero dhcpcd: MAC address = 00:01:03:82:da:a0 dhcpcd: your IP address = 192.168.64.100 Jul 27 03:12:03 prospero dhcpcd: MAC address = 00:01:03:82:da:a0 dhcpcd: your IP address = 192.168.64.100 dhcpcd: MAC address = 00:01:03:82:da:a0 dhcpcd: your IP address = 192.168.64.101 Jul 27 03:12:04 prospero logger: upping... Where .100 was my old IP address, and .101 is a new and different IP address. "upping" is my ifup-local script telling me it's been invoked. Why would dhcp get an IP address three times? Anyway, I'm going to try your test kernel and see if it works better for me. Nope, I still get the dhcp timeout with your 2.4.18-5e kernel. To clarify, I'm not seeing Diego's other problem. For a long time I've seen the DHCP problem. Eventually I noticed that I had two dhcpcd processes running on my Dell Latitude C400 processes after a suspend/resume cycle. This only happens at work and I'm using the TruMobile 1150 802.11b card both at work and home. At home I've configured by DHCP server to always give my MAC address the same IP number so perhaps that is why I don't see this at home. If I killed both processes and did "ifup eth0" things were happy. Anyway, in reading other bug reports I concluded that starting dhcp somehow depends on RH modifications to the hotplug scripts. I had been using the latest version from linux-hotplug.sf.net rather than the RH ones. So earlier this week I reverted to the RH version and now I no longer get two processes starting (or one not exiting, I never actually tested that). However, now I get the same old problem with my IP address changing while running. I have the same messages in my logs; Oct 3 05:20:07 antonia apmd[827]: Normal Resume after 00:14:54 (100% 2:00) AC power Oct 3 05:20:18 antonia dhcpcd[24376]: dhcpStart: ioctl SIOCSIFFLAGS: Device or resource busy Oct 3 05:20:28 antonia cardmgr[936]: executing: './network check eth0' Oct 3 05:20:28 antonia cardmgr[936]: executing: './network stop eth0' Oct 3 05:20:29 antonia cardmgr[936]: executing: 'modprobe -r orinoco_cs' Oct 3 05:20:29 antonia /etc/hotplug/net.agent: NET unregister event not supported Oct 3 05:20:33 antonia cardmgr[936]: socket 1: Intersil PRISM2 11 Mbps Wireless Adapter Oct 3 05:20:33 antonia cardmgr[936]: executing: 'modprobe orinoco_cs' Oct 3 05:20:33 antonia cardmgr[936]: executing: './network start eth0' Oct 3 05:20:33 antonia /etc/hotplug/net.agent: invoke ifup eth0 Oct 3 05:20:33 antonia kernel: eth0: New link status: Connected (0001) Oct 3 05:20:37 antonia dhcpcd[24524]: DHCP_NAK server response received: requested address not available Oct 3 05:51:01 antonia dhcpcd[24528]: sendto: Socket operation on non-socket Oct 3 05:51:01 antonia dhcpcd[24528]: sendto: Socket operation on non-socket Oct 3 05:51:01 antonia dhcpcd[24528]: dhcpStop: ioctl SIOCSIFADDR: Inappropriate ioctl for device Oct 3 05:51:01 antonia dhcpcd[24528]: dhcpStop: ioctl SIOCSIFFLAGS: Inappropriate ioctl for device So at 05:30:37 I received one IP address and then for some reason at 05:51:01 I got a new one; bash-2.05a# ls -l dhcpcd-eth0.info* -rw-r--r-- 1 root root 501 Oct 3 05:51 dhcpcd-eth0.info -rw-r--r-- 1 root root 501 Oct 3 05:20 dhcpcd-eth0.info.old As you can see the process ID of the dhcpcd is the same now. At least with the linux-hotplug.sf.net version of the hotplug scripts I had a (not very nice) workaround. Perhaps I should go back to that. I see if the same problem occurs later today (I usually run a lot of x-windows from other machines so if my IP number changes I could loose a lot of time). Not sure if this is a kernel issue though... I'm running 2.4.20-20.7 and dhcpcd is 1.3.22pl1-7. FYI, I don't think I've ever had this problem under RHL9. 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/ |