Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1153 > unrolled thread

e1000 driver

Back to article view | Back to comp.os.linux.networking

Contents

  e1000 driver Ralph Spitzner <rasp@spitzner.org> - 2012-03-09 10:15 +0100
    Re: e1000 driver Richard Kettlewell <rjk@greenend.org.uk> - 2012-03-09 10:07 +0000
    Re: e1000 driver Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-03-09 23:39 +0100
      Re: e1000 driver GangGreene <GangGreene@invalid.com> - 2012-03-09 20:01 -0500
        Re: e1000 driver Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-03-10 07:13 +0100
          Re: e1000 driver Ralph Spitzner <rasp@spitzner.org> - 2012-03-10 09:30 +0100
            Re: e1000 driver Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-10 15:02 +0000
      Re: e1000 driver Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-03-10 10:16 +0100
    Re: e1000 driver Ralph Spitzner <rasp@spitzner.org> - 2012-03-13 07:52 +0100
      Re: e1000 driver unruh <unruh@invalid.ca> - 2012-03-14 01:59 +0000
        Re: e1000 driver Ralph Spitzner <rasp@spitzner.org> - 2012-03-14 09:33 +0100
    Re: e1000 driver "J.B. Wood" <john.wood@nrl.navy.mil> - 2012-03-13 05:36 -0400
      Re: e1000 driver Rick Jones <rick.jones2@hp.com> - 2012-03-13 21:36 +0000

#1153 — e1000 driver

This may be the wrong group, feel free to shove me to another :-)

Since the latest 2.6.x and with the new 3.x.x Kernels I get
some really strange behaviour on an  82547EI card using the
e1000 driver.

Gateway has two cards one Realtek pointing at the cable-modem
and the gig pointing at the lan via a dlink Giga switch connected
to the Desktop (gigabit) and the printer (100mb) and sometimes friends
computers, all good so far.
(nice throughput, no errors)

Then, when I connect the Targa (el Cheapo) wifi router (100m)
for the netbook and phone it will take anywhere between 1 and 6
_Days_ until the connection to the gateway locks up producing
_this_ on the routers screen:

[16281.008328] ------------[ cut here ]------------
[16281.009020] WARNING: at net/sched/sch_generic.c:255 
dev_watchdog+0xb9/0x110()
[16281.009020] Hardware name: To Be Filled By O.E.M.
[16281.009020] NETDEV WATCHDOG: eth1 (e1000): transmit queue 0 timed out
[16281.009020] Modules linked in: p4_clockmod freq_table speedstep_lib 
dvb_ttpci budget_av tda10023 stv0297 budget_core dvb_core i915 
drm_kms_helper saa7146_vv saa7146 cfbcopyarea video ttpci_eeprom e1000 
snd_intel8x0 8139too snd_ac97_codec ac97_bus backlight cfbimgblt 
cfbfillrect intel_agp intel_gtt [last unloaded: dvb_ttpci]
[16281.009020] Pid: 0, comm: swapper/0 Tainted: G        W 
3.2.2-spitzner.org #3
[16281.009020] Call Trace:
[16281.009020]  [<c102dfde>] warn_slowpath_common+0x65/0x7a
[16281.009020]  [<c139c5c4>] ? dev_watchdog+0xb9/0x110
[16281.009020]  [<c102e057>] warn_slowpath_fmt+0x26/0x2a
[16281.009020]  [<c139c5c4>] dev_watchdog+0xb9/0x110
[16281.009020]  [<c1037b38>] run_timer_softirq+0x156/0x1f9
[16281.009020]  [<c139c50b>] ? netif_tx_unlock+0x3e/0x3e
[16281.009020]  [<c1032b37>] __do_softirq+0x93/0x130
[16281.009020]  [<c1032aa4>] ? local_bh_enable+0xa/0xa
[16281.009020]  <IRQ>  [<c1032d31>] ? irq_exit+0x35/0x84
[16281.009020]  [<c10153bd>] ? smp_apic_timer_interrupt+0x5e/0x6c
[16281.009459]  [<c149fc32>] ? apic_timer_interrupt+0x2a/0x30
[16281.009879]  [<c13400d8>] ? videobuf_read_stream+0xe7/0x238
[16281.010040]  [<c1007532>] ? default_idle+0x52/0x81
[16281.010040]  [<c10017d3>] ? cpu_idle+0x52/0x73
[16281.010040]  [<c148f844>] ? rest_init+0x58/0x5a
[16281.010040]  [<c17296ca>] ? start_kernel+0x2b8/0x2bd
[16281.010040]  [<c17290b0>] ? i386_start_kernel+0xb0/0xb7
[16281.010040] ---[ end trace 4eaa2a86a8e2da24 ]---

Any idea WTF is going on there, anyone ?
(and why the swapper is tainted all of a sudden)
Ok, it might just be hardware going bad, but it coincides
with newer kernels....

regards
	-rasp

-- 
RTMPDump & ffmpeg are your friends..
     -icke

[toc] | [next] | [standalone]

#1154

Ralph Spitzner <rasp@spitzner.org> writes:
> [16281.009020] Pid: 0, comm: swapper/0 Tainted: G        W 3.2.2-spitzner.org #3
[...]
> (and why the swapper is tainted all of a sudden)

Tainting doesn't apply to the swapper, it applies to the whole kernel.
The 'G' means no proprietary modules have been loaded, the 'W'
corresonds to a warning having been issued.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1155

Ralph Spitzner wrote:
> This may be the wrong group, feel free to shove me to another :-)
>
[snip]

Happens here too from time to time. Different hardware, but same symptoms.
I left a rant in just this newsgroup some time ago..

see: 
http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/ec4e94e05cf3f220?hl=de

Have not got any idea what may be the cause. Could be the hardware, 
too... My mainboard is getting old...

[toc] | [prev] | [next] | [standalone]

#1157

On Fri, 09 Mar 2012 23:39:05 +0100, Johann Klammer wrote:

> Ralph Spitzner wrote:
>> This may be the wrong group, feel free to shove me to another :-)
>>
> [snip]
> 
> Happens here too from time to time. Different hardware, but same
> symptoms.
> I left a rant in just this newsgroup some time ago..
> 
> see:
> http://groups.google.com/group/comp.os.linux.networking/browse_thread/
thread/ec4e94e05cf3f220?hl=de
> 
> Have not got any idea what may be the cause. Could be the hardware,
> too... My mainboard is getting old...

It may be due to the realtek.  I had the same problems when I was using a 
realtek wireless card, Asus N13 PCIE in a desktop machine. It caused the 
wireless access point to puke and disrupted the entire lan network. Three 
different wireless access points would go down after a few hours to 2 
days.  Could not keep the wireless working or lan working. I would have 
to reboot the wireless access point to get the lan going again.

What was weird it would take down the wireless access point(s) dlink 
linksys and a belkin within 48 hours of connecting the desktop that had 
the realtek in it. After I changed from the asus (realtek) to a netgear 
wireless adapter (altheros) everything was fine and I have not had a 
failure since I removed the realtek wireless card and placed it into the 
garbage bin.

YMMV

[toc] | [prev] | [next] | [standalone]

#1158

GangGreene wrote:
[snip]
> It may be due to the realtek.  I had the same problems when I was using a
> realtek wireless card, Asus N13 PCIE in a desktop machine. It caused the
> wireless access point to puke and disrupted the entire lan network. Three
> different wireless access points would go down after a few hours to 2
> days.  Could not keep the wireless working or lan working. I would have
> to reboot the wireless access point to get the lan going again.
[snip]

It was neither realtek nor wireless... It is a via-rhine wired network 
card on my box and an intel e1000(also wired, I think) on the original 
posters'. I still suspect EMI or voltage regulator issues.

[toc] | [prev] | [next] | [standalone]

#1159

Johann Klammer wrote:
[...]
> It was neither realtek nor wireless... It is a via-rhine wired network
> card on my box and an intel e1000(also wired, I think) on the original
> posters'. I still suspect EMI or voltage regulator issues.
>

Well, I just ordered a Realtek Gig card to replace the 100m one, so
I can change Interfaces 'round, having the e1000 facing the DSL side.
See what happens when the e1000 gets the myriad of useless ARP requests
my cable modem forwards :-P
(As this is the server/gateway/firewall a decicated DSL router [SoC]
is not really an option here)

But I'm still wondering why there is a 'Watchdog' that does essentially
nothing else as would happen if it weren't there ;-|
Shouldn't it at least be able to reset the card ?
(TCP itself should then re-request whatever was missing)

	-rasp


-- 
RTMPDump & ffmpeg are your friends..
     -icke

[toc] | [prev] | [next] | [standalone]

#1161

On Sat, 2012-03-10, Ralph Spitzner wrote:
> Johann Klammer wrote:
...
> But I'm still wondering why there is a 'Watchdog' that does essentially
> nothing else as would happen if it weren't there ;-|
> Shouldn't it at least be able to reset the card ?
> (TCP itself should then re-request whatever was missing)

Watchdogs work that way. They detect conditions which would only occur
if there's a software bug or hardware error. The right thing to do in
such a rare and unforseen situation is not to try to patch things up,
but to fail noisily.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#1160

Hello,

Johann Klammer a écrit :
> 
> Happens here too from time to time. Different hardware, but same symptoms.

I had a similar message twice recently :

------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:219 dev_watchdog+0xc8/0x13b()
NETDEV WATCHDOG: eth1 (ne2k-pci): transmit timed out
Modules linked in: ipt_ULOG act_police cls_u32 sch_ingress ppp_deflate
zlib_defl
               ate zlib_inflate bsd_comp ppp_async crc_ccitt ppp_generic
slhc ip6t_REJECT ip6ta
                            ble_filter ip6_tables xt_state ipt_REDIRECT
xt_multiport ipt_REJECT xt_limit xt_
                                          tcpudp iptable_mangle
iptable_nat iptable_filter ip_tables x_tables psmouse apm

nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv6 nf_conntrack_ipv4
nf_conntr
               ack ipv6 ne2k_pci 8390 3c59x mii
Pid: 0, comm: swapper Not tainted 2.6.27.61-p3 #1
 [<c0115fa1>] warn_slowpath+0x5a/0x7b
 [<c0112bd3>] enqueue_task_fair+0x19/0x41
 [<c0112070>] enqueue_task+0x3f/0x4a
 [<c0112160>] activate_task+0x1c/0x20
 [<c01122ff>] __wake_up_common+0x2d/0x52
 [<c0111bd9>] place_entity+0x7c/0xca
 [<c0112bd3>] enqueue_task_fair+0x19/0x41
 [<c0112070>] enqueue_task+0x3f/0x4a
 [<c01ca038>] strlcpy+0x11/0x3d
 [<c02463c7>] dev_watchdog+0xc8/0x13b
 [<c01262a4>] ktime_get_ts+0x1d/0x3f
 [<c011c508>] run_timer_softirq+0x124/0x16c
 [<c02462ff>] dev_watchdog+0x0/0x13b
 [<c01199a1>] __do_softirq+0x38/0x78
 [<c0119a03>] do_softirq+0x22/0x26
 [<c0119ab9>] irq_exit+0x25/0x55
 [<c0104de2>] do_IRQ+0x4d/0x5f
 [<c010385f>] common_interrupt+0x23/0x28
 [<c0107377>] default_idle+0x25/0x38
 [<c01028d8>] cpu_idle+0x41/0x5d
 =======================
---[ end trace 0901e6cba4f12be8 ]---
eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=819.
eth1: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=424.
(and so on, until I unplugged and re-plugged the ethernet cable)

eth1 is a Realtek RTL8029 PCI connected to a DSL modem with a 10Mbit/s
half duplex interface.

Weirdly, after unplugging and re-plugging the ethernet cable, the
interface was operational again.

The first time happened 54 days after moving the system to a new
hardware but keeping the same 2.6.27.49 kernel which had run fine for 7
months on the old hardware. The previous card was a 3Com 3C509 ISA. The
second time happened 4 days after upgrading the kernel to 2.6.27.51.

[toc] | [prev] | [next] | [standalone]

#1164

If I connect the onboard Intel to the Cable-Modem the system
goes completely nuts.

Interface doesn't accept assigned IP's from DHCPCD,
log file shows 'link-up', 'link down','link up'.....
Also dhcpcd is setting the MTU from 1500 to 576 and vice
versa continuously.

Also sometimes on manual 'ifconfig' the ifconfig gets zombied and
never returns.

I think I'll just have to take down the onboard LAN in the
bios and get one more card :-(


	-rasp



-- 
RTMPDump & ffmpeg are your friends..
     -icke

[toc] | [prev] | [next] | [standalone]

#1167

On 2012-03-13, Ralph Spitzner <rasp@spitzner.org> wrote:
> If I connect the onboard Intel to the Cable-Modem the system
> goes completely nuts.
>
> Interface doesn't accept assigned IP's from DHCPCD,
> log file shows 'link-up', 'link down','link up'.....
> Also dhcpcd is setting the MTU from 1500 to 576 and vice
> versa continuously.

If you really want help, you will have to give more information.
What is the content of /etc/sysconfig/network-scripts/ifcfg-eth0?
If you do lsmod|grep e100
what do you get? 
Are you sure you want dhcp? Which client are you using?


>
> Also sometimes on manual 'ifconfig' the ifconfig gets zombied and
> never returns.
>
> I think I'll just have to take down the onboard LAN in the
> bios and get one more card :-(

It could be a defective onboard card. 
>
>
> 	-rasp
>
>
>

[toc] | [prev] | [next] | [standalone]

#1168

unruh wrote:
> On 2012-03-13, Ralph Spitzner<rasp@spitzner.org>  wrote:

> If you really want help, you will have to give more information.
> What is the content of /etc/sysconfig/network-scripts/ifcfg-eth0?

Nothing, since it doesn't exist :-)

> If you do lsmod|grep e100
> what do you get?

Nothing either, its an e1000

> Are you sure you want dhcp? Which client are you using?

Stock from Slackware ->
dhcpcd 5.2.11
Copyright (c) 2006-2011 Roy Marples

And yes since I tried swapping the interface I have to use
DHCP since there's no other way to obtain an IP address
from my cable modem.

(LAN 1 card, static IP's or dhcp for guests,
DSL dhcp from provider)

I don't know if you read my original post, in there
you'll find what I was on about.


> It could be a defective onboard card.

It is.
Yesterday the system started freezing randomly, then
I finally got the icing :
'Bios checksum error, please insert blabla to restore'

And no, it doesn't restore anything, following the guidelines
in the Manual :-(

So the board is F***ED :-(

SNAFU
	-rasp



-- 
RTMPDump & ffmpeg are your friends..
     -icke

[toc] | [prev] | [next] | [standalone]

#1165

On 03/09/2012 04:15 AM, Ralph Spitzner wrote:
> This may be the wrong group, feel free to shove me to another :-)
>
> Since the latest 2.6.x and with the new 3.x.x Kernels I get
> some really strange behaviour on an 82547EI card using the
> e1000 driver.
>

Hello, and I've encountered difficulties on occasion with the e1000e 
(not the e1000) when using Fedora or CentOS on certain platforms with 
multiple ethX ports.  Sometimes a particular port will just stop 
accepting/sending traffic while the other ports remain OK.  Doing an 
ifconfig on the problem ethX usually shows a bunch of frame errors. 
Rebooting the system usually restores operation (at least for a time). 
Sincerely,


-- 
J. B. Wood	            e-mail: arl_123234@hotmail.com

[toc] | [prev] | [next] | [standalone]

#1166

J.B. Wood <john.wood@nrl.navy.mil> wrote:

> Hello, and I've encountered difficulties on occasion with the e1000e
> (not the e1000) when using Fedora or CentOS on certain platforms
> with multiple ethX ports.  Sometimes a particular port will just
> stop accepting/sending traffic while the other ports remain OK.
> Doing an ifconfig on the problem ethX usually shows a bunch of frame
> errors.  Rebooting the system usually restores operation (at least
> for a time).  Sincerely,

Are you already aware of Linux's rather strong view of implementing
the weak end-system model and its effects when multiple NICs are
connected to the same broadcast domain?  Wouldn't explain frame
errors, but your description made me want to ask.

rick jones
code 4040 LCP&FD in a previous life...
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web