e1000-devel Mailing List for Formerly Intel Ethernet Drivers

Ronciak, John wrote:
> These:
>      rx_no_buffer_count: 8083597
>      rx_missed_errors: 52373
> 
> are aproblem.  It means that the HW isn't being serviced fast enough.
> Try things with turning all interrupt moderation off.  This will make
> the interrupt rate go up significantly but let see what it does to the
> queueing.  The missed packets should go away with this.

I also suggest that reducing the number of interrupts might have hurt you in this case:

 >> First we noticed the cards were generating 8k irq/sec,
 >> thought the limiting
 >> causes this, so I fiddled with the irq limits, and set it to:
 >> e1000 TxIntDelay=25,25,25 TxAbsIntDelay=256,256,256
 >> RxIntDelay=64,64,64
 >> RxAbsIntDelay=256,256,256

I would suggest leaving these settings along and *only* playing with 'itr'. The default 
'itr' value for that driver is 8000, and increasing it might help. We have seen good 
results with values over 20000 and even setting it to unlimited (itr=0) might help in 
case your system can handle it (and it's definately good for latency, whereas setting 
*IntDelay parameters are not).

quick question: are you running with tso on or off? That (having tso on) might expose 
you to a tc/qdisc kernel bug that we recently uncovered, where the kernel is not 
accounting for tso packets properly.

Cheers,

Auke


> 
> Cheers,
> John
> -----------------------------------------------------------
> "Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety.", Benjamin
> Franklin 1755 
> 
> 
>> -----Original Message-----
>> From: e10...@li... 
>> [mailto:e10...@li...] On Behalf 
>> Of peter gervai
>> Sent: Tuesday, October 31, 2006 10:15 AM
>> To: e10...@li...
>> Subject: [E1000-devel] Transmit queueing,resulting high 
>> latency and speed drops
>>
>>
>> Hello,
>>
>> I have been investigating this one for weeks now, yesterday I 
>> thought I've
>> finally figured it out, seems I was wrong, so here it comes, 
>> final try, emailing
>> the developers. :)
>>
>> Kernel is vanilla 2.6.17.11 SMP. [I hope it's not something 
>> fixed in kernel in
>> the meantime... :-/]
>>
>> Driver is  7.0.33-k2-NAPI
>>
>> The server is an intel etherepress based board, strong cpus, 
>> plenty of memory,
>> etc. Contains 4 cards, of which two is relevant:
>> 03:02.0 Ethernet controller: Intel Corporation 82545GM 
>> Gigabit Ethernet
>> Controller (rev 04)
>> 06:01.0 Ethernet controller: Intel Corporation 82541GI/PI 
>> Gigabit Ethernet
>> Controller (rev 05)
>>
>> First one is an external PCI-X:133Mhz:64bit, other is 
>> integrated onboard, lspci
>> thinks it is the same speed, e1000 drivr thinks
>>  e1000: 0000:06:01.0: e1000_probe: (PCI:66MHz:32-bit)
>>
>> The traffic goes through these cards, mainly in the first and 
>> out the second
>> (200mbps) and slightly less traffic the other way (70mbps).
>>
>> When traffic reaches approx. 32000 packets/sec (I fear it 
>> might be 32768
>> pkts/sec which is always a bad omen) the first card starts to 
>> queue outgoing
>> traffic (while the second card does not). The queueing is 
>> visible in the linux
>> queueing:
>>
>> qdisc tbf 8007: dev eth0 rate 1000Mbit burst 32750b/8 mpu 0b 
>> lat 20.0ms 
>>  Sent 22893578821 bytes 68342382 pkt (dropped 1, overlimits 
>> 61 requeues 299611) 
>>  rate 85935Kbit 32380pps backlog 0b 449p requeues 299611 
>> qdisc tbf 8005: dev eth1 rate 1000Mbit burst 32750b/8 mpu 0b 
>> lat 20.0ms 
>>  Sent 681354341621 bytes 937627172 pkt (dropped 12523, 
>> overlimits 127208
>> requeues 1853808) 
>>  rate 227450Kbit 34288pps backlog 0b 0p requeues 1853808 
>>
>> (tbf was selected only to be able to measure the traffic, 
>> rate is same as link
>> capacity to prevent overlimits; the queueing happens with 
>> pfifo_fast too.)
>>
>> First we noticed the cards were generating 8k irq/sec, 
>> thought the limiting
>> causes this, so I fiddled with the irq limits, and set it to:
>> e1000 TxIntDelay=25,25,25 TxAbsIntDelay=256,256,256 
>> RxIntDelay=64,64,64
>> RxAbsIntDelay=256,256,256
>>
>> This reduced interrupt rate to 2k-5k, but it still queues at 
>> the same rate.
>>
>> I do not belive it's a hardware issue (can't think of any 
>> which would cause
>> this) but I cannot further come up with ideas what could 
>> cause the packets to
>> queue up.
>>
>> The stats doesn't tell me anything helpful either:
>> # ethtool -S eth0
>> NIC statistics:
>>      rx_packets: 1212685382
>>      tx_packets: 938711270
>>      rx_bytes: 750835435
>>      tx_bytes: 3250721930
>>      rx_errors: 0
>>      tx_errors: 0
>>      tx_dropped: 0
>>      multicast: 0
>>      collisions: 0
>>      rx_length_errors: 0
>>      rx_over_errors: 0
>>      rx_crc_errors: 0
>>      rx_frame_errors: 0
>>      rx_no_buffer_count: 8083597
>>      rx_missed_errors: 52373
>>      tx_aborted_errors: 0
>>      tx_carrier_errors: 0
>>      tx_fifo_errors: 0
>>      tx_heartbeat_errors: 0
>>      tx_window_errors: 0
>>      tx_abort_late_coll: 0
>>      tx_deferred_ok: 3991825
>>      tx_single_coll_ok: 0
>>      tx_multi_coll_ok: 0
>>      tx_timeout_count: 0
>>      rx_long_length_errors: 0
>>      rx_short_length_errors: 0
>>      rx_align_errors: 0
>>      tx_tcp_seg_good: 4
>>      tx_tcp_seg_failed: 0
>>      rx_flow_control_xon: 0
>>      rx_flow_control_xoff: 141102752
>>      tx_flow_control_xon: 129374
>>      tx_flow_control_xoff: 143188
>>      rx_long_byte_count: 825384556267
>>      rx_csum_offload_good: 1208095761
>>      rx_csum_offload_errors: 37281
>>      rx_header_split: 0
>>      alloc_rx_buff_failed: 0
>>
>> So I'm clueless here. Any help would be very much 
>> appreciated. Emailing me
>> personally or CC'ing would be appreciated either. I can 
>> naturally provide eprom
>> dumps, lspci -vv's or anything long, if it helps. 
>>
>> Thanks,
>> Peter
>>
>>
>>
>> --------------------------------------------------------------
>> -----------
>> Using Tomcat but need to do more? Need to support web 
>> services, security?
>> Get stuff done quickly with pre-integrated technology to make 
>> your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on 
>> Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
> dat=121642
> _______________________________________________
> E1000-devel mailing list
> E10...@li...
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> E1000-devel mailing list
> E10...@li...
> https://lists.sourceforge.net/lists/listinfo/e1000-devel

e10...@li... wrote:
> Hello,
>=20
> I have been investigating this one for weeks now, yesterday I
> thought I've finally figured it out, seems I was wrong, so
> here it comes, final try, emailing the developers. :)
>=20
> Kernel is vanilla 2.6.17.11 SMP. [I hope it's not something
> fixed in kernel in the meantime... :-/]
>=20
> Driver is  7.0.33-k2-NAPI

This is one of those where we might have fixed this in the driver
already.  In any case the 7.3.15 driver has a new statistic having to do
with the number of times we've paused and restarted the tx queue.

Please try to use the newest driver from our sourceforge site and see if
it helps.

=20
> The server is an intel etherepress based board, strong cpus,
> plenty of memory, etc. Contains 4 cards, of which two is relevant:
> 03:02.0 Ethernet controller: Intel Corporation 82545GM
> Gigabit Ethernet Controller (rev 04) 06:01.0 Ethernet
> controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller
> (rev 05)=20
>=20
> First one is an external PCI-X:133Mhz:64bit, other is
> integrated onboard, lspci thinks it is the same speed, e1000 drivr
>  thinks e1000: 0000:06:01.0: e1000_probe: (PCI:66MHz:32-bit)
>=20
> The traffic goes through these cards, mainly in the first and
> out the second
> (200mbps) and slightly less traffic the other way (70mbps).
>=20
> When traffic reaches approx. 32000 packets/sec (I fear it
> might be 32768 pkts/sec which is always a bad omen) the first
> card starts to queue outgoing traffic (while the second card
> does not). The queueing is visible in the linux
> queueing:

Yeah, 32000 pps still shouldn't be any concern for our hardware.
=20
> qdisc tbf 8007: dev eth0 rate 1000Mbit burst 32750b/8 mpu 0b
> lat 20.0ms  Sent 22893578821 bytes 68342382 pkt (dropped 1,
> overlimits 61 requeues 299611)  rate 85935Kbit 32380pps
> backlog 0b 449p requeues 299611 qdisc tbf 8005: dev eth1 rate
> 1000Mbit burst 32750b/8 mpu 0b lat 20.0ms  Sent 681354341621
> bytes 937627172 pkt (dropped 12523, overlimits 127208
> requeues 1853808)  rate 227450Kbit 34288pps backlog 0b 0p requeues
> 1853808=20

I worry about the rates mentioned here, but I'll take your word for it.

> (tbf was selected only to be able to measure the traffic,
> rate is same as link capacity to prevent overlimits; the
> queueing happens with pfifo_fast too.)
>=20
> First we noticed the cards were generating 8k irq/sec,
> thought the limiting causes this, so I fiddled with the irq limits,
> and set it to: e1000 TxIntDelay=3D25,25,25 TxAbsIntDelay=3D256,256,256
> RxIntDelay=3D64,64,64 RxAbsIntDelay=3D256,256,256

Actually the ITR (InterruptThrottleRate) is what is limiting the
interrupts here.  If you wanted to see what your xxDelay parameters
really did load the module with InterruptThrottleRate=3D0,0,0

> This reduced interrupt rate to 2k-5k, but it still queues at
> the same rate.

So maybe we need more interrupts per second, but see below.

=20
> I do not belive it's a hardware issue (can't think of any
> which would cause
> this) but I cannot further come up with ideas what could
> cause the packets to queue up.
=20
> The stats doesn't tell me anything helpful either:
> # ethtool -S eth0
> NIC statistics:
>      rx_packets: 1212685382
>      tx_packets: 938711270
>      rx_bytes: 750835435
>      tx_bytes: 3250721930
>      rx_no_buffer_count: 8083597
>      rx_missed_errors: 52373
>      tx_deferred_ok: 3991825
>      tx_tcp_seg_good: 4
>      rx_flow_control_xon: 0
>      rx_flow_control_xoff: 141102752
>      tx_flow_control_xon: 129374
>      tx_flow_control_xoff: 143188
>      rx_long_byte_count: 825384556267
>      rx_csum_offload_good: 1208095761
>      rx_csum_offload_errors: 37281

Several things are very telling here.
1) you're getting rx_no_buffer_count errors, which means software didn't
have any descriptors ready for hardware to DMA into. =3D=3D> solution:
increase RxDescriptors using ethtool
2) the second bit is that rx_missed shows that only some portion of the
packets in 1) were dropped, so you proobably only need to increase rx
descriptors a little bit.
3) flow control:
RX: As the rx fifo fills up due to 1) a flow control pause is sent to
the link partner (tx flow)
TX: This interface is receiving a *lot* of flow control from its link
partner, indicating the other end can't keep up with what this adapter
is transmitting.  This causes the TX unit to pause, causing the driver
to stop the queue, causing pfifo_fast to queue.  What is this machine
connected to on this interface eth0?

The cost per RX packet is probably high enough with NAPI enabled that it
is taking the driver too long to return free buffers to the hardware.

Lots of rx checksum offload errors too, ick.

> So I'm clueless here. Any help would be very much
> appreciated. Emailing me personally or CC'ing would be
> appreciated either. I can naturally provide eprom dumps,
> lspci -vv's or anything long, if it helps.

Jesse

These:
     rx_no_buffer_count: 8083597
     rx_missed_errors: 52373

are aproblem.  It means that the HW isn't being serviced fast enough.
Try things with turning all interrupt moderation off.  This will make
the interrupt rate go up significantly but let see what it does to the
queueing.  The missed packets should go away with this.

Cheers,
John
-----------------------------------------------------------
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.", Benjamin
Franklin 1755=20


> -----Original Message-----
> From: e10...@li...=20
> [mailto:e10...@li...] On Behalf=20
> Of peter gervai
> Sent: Tuesday, October 31, 2006 10:15 AM
> To: e10...@li...
> Subject: [E1000-devel] Transmit queueing,resulting high=20
> latency and speed drops
>=20
>=20
> Hello,
>=20
> I have been investigating this one for weeks now, yesterday I=20
> thought I've
> finally figured it out, seems I was wrong, so here it comes,=20
> final try, emailing
> the developers. :)
>=20
> Kernel is vanilla 2.6.17.11 SMP. [I hope it's not something=20
> fixed in kernel in
> the meantime... :-/]
>=20
> Driver is  7.0.33-k2-NAPI
>=20
> The server is an intel etherepress based board, strong cpus,=20
> plenty of memory,
> etc. Contains 4 cards, of which two is relevant:
> 03:02.0 Ethernet controller: Intel Corporation 82545GM=20
> Gigabit Ethernet
> Controller (rev 04)
> 06:01.0 Ethernet controller: Intel Corporation 82541GI/PI=20
> Gigabit Ethernet
> Controller (rev 05)
>=20
> First one is an external PCI-X:133Mhz:64bit, other is=20
> integrated onboard, lspci
> thinks it is the same speed, e1000 drivr thinks
>  e1000: 0000:06:01.0: e1000_probe: (PCI:66MHz:32-bit)
>=20
> The traffic goes through these cards, mainly in the first and=20
> out the second
> (200mbps) and slightly less traffic the other way (70mbps).
>=20
> When traffic reaches approx. 32000 packets/sec (I fear it=20
> might be 32768
> pkts/sec which is always a bad omen) the first card starts to=20
> queue outgoing
> traffic (while the second card does not). The queueing is=20
> visible in the linux
> queueing:
>=20
> qdisc tbf 8007: dev eth0 rate 1000Mbit burst 32750b/8 mpu 0b=20
> lat 20.0ms=20
>  Sent 22893578821 bytes 68342382 pkt (dropped 1, overlimits=20
> 61 requeues 299611)=20
>  rate 85935Kbit 32380pps backlog 0b 449p requeues 299611=20
> qdisc tbf 8005: dev eth1 rate 1000Mbit burst 32750b/8 mpu 0b=20
> lat 20.0ms=20
>  Sent 681354341621 bytes 937627172 pkt (dropped 12523,=20
> overlimits 127208
> requeues 1853808)=20
>  rate 227450Kbit 34288pps backlog 0b 0p requeues 1853808=20
>=20
> (tbf was selected only to be able to measure the traffic,=20
> rate is same as link
> capacity to prevent overlimits; the queueing happens with=20
> pfifo_fast too.)
>=20
> First we noticed the cards were generating 8k irq/sec,=20
> thought the limiting
> causes this, so I fiddled with the irq limits, and set it to:
> e1000 TxIntDelay=3D25,25,25 TxAbsIntDelay=3D256,256,256=20
> RxIntDelay=3D64,64,64
> RxAbsIntDelay=3D256,256,256
>=20
> This reduced interrupt rate to 2k-5k, but it still queues at=20
> the same rate.
>=20
> I do not belive it's a hardware issue (can't think of any=20
> which would cause
> this) but I cannot further come up with ideas what could=20
> cause the packets to
> queue up.
>=20
> The stats doesn't tell me anything helpful either:
> # ethtool -S eth0
> NIC statistics:
>      rx_packets: 1212685382
>      tx_packets: 938711270
>      rx_bytes: 750835435
>      tx_bytes: 3250721930
>      rx_errors: 0
>      tx_errors: 0
>      tx_dropped: 0
>      multicast: 0
>      collisions: 0
>      rx_length_errors: 0
>      rx_over_errors: 0
>      rx_crc_errors: 0
>      rx_frame_errors: 0
>      rx_no_buffer_count: 8083597
>      rx_missed_errors: 52373
>      tx_aborted_errors: 0
>      tx_carrier_errors: 0
>      tx_fifo_errors: 0
>      tx_heartbeat_errors: 0
>      tx_window_errors: 0
>      tx_abort_late_coll: 0
>      tx_deferred_ok: 3991825
>      tx_single_coll_ok: 0
>      tx_multi_coll_ok: 0
>      tx_timeout_count: 0
>      rx_long_length_errors: 0
>      rx_short_length_errors: 0
>      rx_align_errors: 0
>      tx_tcp_seg_good: 4
>      tx_tcp_seg_failed: 0
>      rx_flow_control_xon: 0
>      rx_flow_control_xoff: 141102752
>      tx_flow_control_xon: 129374
>      tx_flow_control_xoff: 143188
>      rx_long_byte_count: 825384556267
>      rx_csum_offload_good: 1208095761
>      rx_csum_offload_errors: 37281
>      rx_header_split: 0
>      alloc_rx_buff_failed: 0
>=20
> So I'm clueless here. Any help would be very much=20
> appreciated. Emailing me
> personally or CC'ing would be appreciated either. I can=20
> naturally provide eprom
> dumps, lspci -vv's or anything long, if it helps.=20
>=20
> Thanks,
> Peter
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
_______________________________________________
E1000-devel mailing list
E10...@li...
https://lists.sourceforge.net/lists/listinfo/e1000-devel

Hello,

I have been investigating this one for weeks now, yesterday I thought I've
finally figured it out, seems I was wrong, so here it comes, final try, emailing
the developers. :)

Kernel is vanilla 2.6.17.11 SMP. [I hope it's not something fixed in kernel in
the meantime... :-/]

Driver is  7.0.33-k2-NAPI

The server is an intel etherepress based board, strong cpus, plenty of memory,
etc. Contains 4 cards, of which two is relevant:
03:02.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet
Controller (rev 04)
06:01.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet
Controller (rev 05)

First one is an external PCI-X:133Mhz:64bit, other is integrated onboard, lspci
thinks it is the same speed, e1000 drivr thinks
 e1000: 0000:06:01.0: e1000_probe: (PCI:66MHz:32-bit)

The traffic goes through these cards, mainly in the first and out the second
(200mbps) and slightly less traffic the other way (70mbps).

When traffic reaches approx. 32000 packets/sec (I fear it might be 32768
pkts/sec which is always a bad omen) the first card starts to queue outgoing
traffic (while the second card does not). The queueing is visible in the linux
queueing:

qdisc tbf 8007: dev eth0 rate 1000Mbit burst 32750b/8 mpu 0b lat 20.0ms 
 Sent 22893578821 bytes 68342382 pkt (dropped 1, overlimits 61 requeues 299611) 
 rate 85935Kbit 32380pps backlog 0b 449p requeues 299611 
qdisc tbf 8005: dev eth1 rate 1000Mbit burst 32750b/8 mpu 0b lat 20.0ms 
 Sent 681354341621 bytes 937627172 pkt (dropped 12523, overlimits 127208
requeues 1853808) 
 rate 227450Kbit 34288pps backlog 0b 0p requeues 1853808 

(tbf was selected only to be able to measure the traffic, rate is same as link
capacity to prevent overlimits; the queueing happens with pfifo_fast too.)

First we noticed the cards were generating 8k irq/sec, thought the limiting
causes this, so I fiddled with the irq limits, and set it to:
e1000 TxIntDelay=25,25,25 TxAbsIntDelay=256,256,256 RxIntDelay=64,64,64
RxAbsIntDelay=256,256,256

This reduced interrupt rate to 2k-5k, but it still queues at the same rate.

I do not belive it's a hardware issue (can't think of any which would cause
this) but I cannot further come up with ideas what could cause the packets to
queue up.

The stats doesn't tell me anything helpful either:
# ethtool -S eth0
NIC statistics:
     rx_packets: 1212685382
     tx_packets: 938711270
     rx_bytes: 750835435
     tx_bytes: 3250721930
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 0
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 8083597
     rx_missed_errors: 52373
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 3991825
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 4
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 141102752
     tx_flow_control_xon: 129374
     tx_flow_control_xoff: 143188
     rx_long_byte_count: 825384556267
     rx_csum_offload_good: 1208095761
     rx_csum_offload_errors: 37281
     rx_header_split: 0
     alloc_rx_buff_failed: 0

So I'm clueless here. Any help would be very much appreciated. Emailing me
personally or CC'ing would be appreciated either. I can naturally provide eprom
dumps, lspci -vv's or anything long, if it helps. 

Thanks,
Peter

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<img alt="" src="cid:par...@di..." height="278"
 width="686"><br>
She has had surgery and will soon.<br>
That doesn't mean that you.<br>
The product or its brand?<br>
Wasn't that your answer? The business or its brand? Brands logically
precede businesses and products. They always have the brand in the back
of their minds when they innovate. The other being that Joy is just a
great person, sharp as a tack, enthusiastic, and funny.<br>
com Breast Cancer GuideSite.<br>
Names can be brainstormed. Brands logically precede businesses and
products. The lessons of lean manufacturing offer many opportunities for
improving the underlying software supply chain that every business
depends upon today. Brands must be organically grown. In order to use
the ActiveX Print Control with the HTML Interactive viewer, perform the
steps outlined in this knowledge base article.<br>
The lessons of lean manufacturing offer many opportunities for improving
the underlying software supply chain that every business depends upon
today.<br>
I also have lots of headphones for testing, so I'm pretty sensitive to
audio quality.<br>
Brands must be organically grown. How could I have breast cancer?<br>
The principles of Lean Thinking offer practical, measurable ways to use
the Rational solution to transform software delivery processes. Possibly
the result was in its "top news" box but I'm guessing, from the words
that appear in this search result, that it was a sponsor or other
advertising block.<br>
<br>
</body>
</html>

Brian McNally wrote:
> Whoops, what I meant to say was that I removed the module with `modprobe 
> -r`. My other comments about the new module not making a difference 
> still stand though. Any thoughts?

then we're getting into the next stage of debugging where we need more data:

* full `dmesg`, with the "TX unit hang" messages
* `ethtool -e ethX`
* try turning tso off: `ethtool -K ethX tso off` and let us know if the problem goes away
* describe what kind of data/magnitude is passing over the interface when the problem occurs

Cheers,

Auke

e10...@li... wrote:
> Whoops, what I meant to say was that I removed the module
> with `modprobe -r`. My other comments about the new module
> not making a difference still stand though. Any thoughts?

Okay, you're getting tx hangs, it sounds like you got the 7.3.15tdhdump
driver running, but it made no difference right?

What does your dmesg show after getting some hangs?  This "dump" driver
you're running should output a ton of stuff if the NIC hangs.  You can
see how many you've gotten with ethtool -S

You may need to do dmesg -s99999 > file after getting a tx hang because
the dump is huge.

Did you mention which motherboard you're using (model and p/n if you
have it), and/or dmidecode output would be good.  Please make sure
you're running the latest bios available.

Let us know how it goes,
  Jesse

Whoops, what I meant to say was that I removed the module with  
`modprobe -r`. My other comments about the new module not making a  
difference still stand though. Any thoughts?

--
Brian McNally


On Oct 30, 2006, at 8:42 AM, Auke Kok wrote:

> Brian McNally wrote:
>> Thanks for the quick reply Auke. I was a bit concerned that my  
>> message had even be sent to the list because the sourceforge web  
>> interface hasn't shown any messages since 9/27/2006.
>> I'm using the PWLA8391GT card. I've got the full kernel source,  
>> and not just the headers. I ran `make versioncheck` without luck.  
>> However, copying my .config from /boot and running just `make` in  
>> my source directory created the appropriate files. I was able to  
>> compile the driver afterwards.
>> I'm having some problems actually inserting the new module though.  
>> After running `make` I removed the old e1000 with `modprobe -n  
>> e1000` which appeared to work according to lsmod. Then, I inserted  
>> the new one with `insmod e1000.ko`. According to modinfo that  
>> loaded the same version of the module that I already had (7.0.33- 
>> k2). Is there something I'm doing wrong here?
>
> removing modules is commonly done with `rmmod` or `modprobe -r`.  
> The -n option makes `modprobe` do nothing :)
>
> Auke

sirius chromatograph

Up On the News - GSNH closes Up Friday, After-Market News Release - Get GSNH Quote Here. punch.
http://moneycentral.msn.com/detail/stock_quote?Symbol=gsnh

After weeks of speculation it's finally here, and the news is even bigger than we thought. stuyvesant.

We first knew something was up with GSNH when news came out Thursday regarding Drill LOMT #1. But GSNH really popped up on our radar with Friday's After-Market news. GSNH has announced its partners for the LOMT #1 sidetrack well and you are not going to believe who they are. impeller.

GSNH Names Partners for LOMT #1 Sidetrack Well dar.
Friday October 27, 4:05 pm ET plugging.
HOUSTON, Texas--(BUSINESS WIRE) - GSNH announces...has awarded drilling services for the LOMT #1 Sidetrack well to the following providers: absorb
* Patterson-UTI (Nasdaq: PTEN), Revenue: 2.23 billion, UP 63.30% crusade
* Schlumberger (NYSE: SLB), Revenue: 17.90 billion, UP 34.00% huxtable
* Halliburton (NYSE: HAL), Revenue: 22.90 billion, UP 13.40% shipboard

Oct. 27, 2006 (BUSINESS WIRE) - GSNH Names Partners for Sidetrack Well... phosphor
http://biz.yahoo.com/bw/061027/20061027005324.html?.v=1

GSNH has been releasing steady news worldwide, from Yahoo Finance, AOL, & MSN Money to Marketwatch & Bloomberg---even the NYSE & the NASDAQ have gotten in on the action. Exposure for GSNH is expansive. The increased frequency of news led us to believe that something big was coming for GSNH, and as usual, we were dead-on right. colatitude

Oct. 26, 2006 (BUSINESS WIRE) – GSNH to Drill LOMT #1... mature.
http://money.aol.com/news/articles/_a/greater-sooner-holdings-inc-to-drill/n20061026162609990029

Oct. 12, 2006 (BUSINESS WIRE) – GSNH Reports Drilling Success... lithology.
http://www.marketwatch.com/News/Story/Story.aspx?guid={05206016-17D5-4077-B8A3-3D8A763487E2}&siteid=mktw&sid=2133723&symb=

Oct. 11, 2006 (BUSINESS WIRE) – GSNH Announces the Anthony 33... decile.
http://news.moneycentral.msn.com/ticker/article.asp?Feed=BW&Date=20061011&ID=6094112&Symbol=US:GSNH

Oct. 4, 2006 (BUSINESS WIRE) – GSNH...285 million in Probable Reserves... curran.
http://bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GSNH:US&sid=a6F2jO13PWCU

Friday's After-Market news on GSNH and its newfound partnership with these major corporations (over 43 billion in revenue combined) is just the beginning. We believe that there is even bigger news coming, and as always, we are bringing you the news ahead of time, ahead of everyone else, and ahead of a major spike in GSNH stock price.

mccall quagmire approval

Brian McNally wrote:
> Thanks for the quick reply Auke. I was a bit concerned that my message 
> had even be sent to the list because the sourceforge web interface 
> hasn't shown any messages since 9/27/2006.
> 
> I'm using the PWLA8391GT card. I've got the full kernel source, and not 
> just the headers. I ran `make versioncheck` without luck. However, 
> copying my .config from /boot and running just `make` in my source 
> directory created the appropriate files. I was able to compile the 
> driver afterwards.
> 
> I'm having some problems actually inserting the new module though. After 
> running `make` I removed the old e1000 with `modprobe -n e1000` which 
> appeared to work according to lsmod. Then, I inserted the new one with 
> `insmod e1000.ko`. According to modinfo that loaded the same version of 
> the module that I already had (7.0.33-k2). Is there something I'm doing 
> wrong here?

removing modules is commonly done with `rmmod` or `modprobe -r`. The -n option makes 
`modprobe` do nothing :)

Auke

After some testing with the new driver (7.3.15_tdhdump according to  
modinfo), I'm still having the same problem as before. That is,  
traffic over the interface halts when I start passing a lot of  
traffic over it. I haven't done any testing to determine what that  
threshold is. Bouncing the interface fixes the problem until the next  
burst of traffic happens.

--
Brian McNally



On Oct 29, 2006, at 10:40 PM, Brian McNally wrote:

> Thanks for the quick reply Auke. I was a bit concerned that my  
> message had even be sent to the list because the sourceforge web  
> interface hasn't shown any messages since 9/27/2006.
>
> I'm using the PWLA8391GT card. I've got the full kernel source, and  
> not just the headers. I ran `make versioncheck` without luck.  
> However, copying my .config from /boot and running just `make` in  
> my source directory created the appropriate files. I was able to  
> compile the driver afterwards.
>
> I'm having some problems actually inserting the new module though.  
> After running `make` I removed the old e1000 with `modprobe -n  
> e1000` which appeared to work according to lsmod. Then, I inserted  
> the new one with `insmod e1000.ko`. According to modinfo that  
> loaded the same version of the module that I already had (7.0.33- 
> k2). Is there something I'm doing wrong here?
>
> `lspci -vv` indicates the following:
>
> 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/ 
> KM133] (rev 03)
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
>         Latency: 0
>         Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
>         Capabilities: <available only to root>
>
> 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/ 
> KM133 AGP] (prog-if 00 [Normal decode])
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
>         Latency: 0
>         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>         Memory behind bridge: dc000000-ddffffff
>         Prefetchable memory behind bridge: d0000000-d7ffffff
>         BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
>         Capabilities: <available only to root>
>
> 0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo  
> Super South] (rev 40)
>         Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping+ SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 0
>         Capabilities: <available only to root>
>
> 0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/ 
> VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a  
> [Master SecP PriP])
>         Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/ 
> VT8233/A/C/VT8235 PIPC Bus Master IDE
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 32
>         Region 4: I/O ports at c000 [size=16]
>         Capabilities: <available only to root>
>
> 0000:00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super  
> ACPI] (rev 40)
>         Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
>         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Interrupt: pin ? routed to IRQ 5
>         Capabilities: <available only to root>
>
> 0000:00:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3512  
> [SATALink/SATARaid] Serial ATA Controller (rev 01)
>         Subsystem: Silicon Image, Inc. SiI 3512 SATARaid Controller
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR+
>         Latency: 32, Cache Line Size: 0x08 (32 bytes)
>         Interrupt: pin A routed to IRQ 10
>         Region 0: I/O ports at cc00 [size=8]
>         Region 1: I/O ports at d000 [size=4]
>         Region 2: I/O ports at d400 [size=8]
>         Region 3: I/O ports at d800 [size=4]
>         Region 4: I/O ports at dc00 [size=16]
>         Region 5: Memory at df040000 (32-bit, non-prefetchable)  
> [size=512]
>         Expansion ROM at 20000000 [disabled] [size=512K]
>         Capabilities: <available only to root>
>
> 0000:00:0b.0 Ethernet controller: D-Link System Inc RTL8139  
> Ethernet (rev 10)
>         Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet  
> Adapter
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR+
>         Latency: 32 (8000ns min, 16000ns max)
>         Interrupt: pin A routed to IRQ 12
>         Region 0: I/O ports at e000 [size=256]
>         Region 1: Memory at df041000 (32-bit, non-prefetchable)  
> [size=256]
>         Capabilities: <available only to root>
>
> 0000:00:0d.0 Ethernet controller: Intel Corporation 82541PI Gigabit  
> Ethernet Controller (rev 05)
>         Subsystem: Intel Corporation: Unknown device 1376
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes)
>         Interrupt: pin A routed to IRQ 11
>         Region 0: Memory at df000000 (32-bit, non-prefetchable)  
> [size=128K]
>         Region 1: Memory at df020000 (32-bit, non-prefetchable)  
> [size=128K]
>         Region 2: I/O ports at e400 [size=64]
>         Expansion ROM at 20080000 [disabled] [size=128K]
>         Capabilities: <available only to root>
>
> 0000:00:0e.0 Ethernet controller: D-Link System Inc RTL8139  
> Ethernet (rev 10)
>         Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet  
> Adapter
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR+
>         Latency: 32 (8000ns min, 16000ns max)
>         Interrupt: pin A routed to IRQ 10
>         Region 0: I/O ports at e800 [size=256]
>         Region 1: Memory at df042000 (32-bit, non-prefetchable)  
> [size=256]
>         Capabilities: <available only to root>
>
> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV15  
> [GeForce2 GTS/Pro] (rev a3) (prog-if 00 [VGA])
>         Subsystem: Guillemot Corporation: Unknown device 7000
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium  
> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 32 (1250ns min, 250ns max)
>         Interrupt: pin A routed to IRQ 11
>         Region 0: Memory at dc000000 (32-bit, non-prefetchable)  
> [size=16M]
>         Region 1: Memory at d0000000 (32-bit, prefetchable)  
> [size=128M]
>         Expansion ROM at dd000000 [disabled] [size=64K]
>         Capabilities: <available only to root>
>
> --
> Brian McNally
>
>
> On Oct 29, 2006, at 6:32 PM, Auke Kok wrote:
>
>> Brian McNally wrote:
>>> Like others on this list, I've got the "e1000_clean_tx_irq:  
>>> Detected  Tx Unit Hang" error. For reference, I'm running Ubuntu  
>>> Server 6.06  and the 2.6.15-26 kernel. I've been told that recent  
>>> versions of the  driver may fix my problem.
>>
>> it also depends heavily on your hardware, so please include `lspci  
>> -vv` output for the device. What chipset is on your e1000?
>>
>>> From looking at the Makefile, it looks like I need version.h and   
>>> autoconf.h. The linux-source-2.6.15 package doesn't have these  
>>> files  though, which expectedly causes make to fail. What can I  
>>> do to fix or  work around this? I've tried copying these files  
>>> from another 2.6.15  kernel source, but that didn't work.
>>
>> the kernel autogenerates those as soon as you start compiling. You  
>> will need them available in the sources. Depending on your distro,  
>> this may be as easy as doing `make versioncheck` in your /usr/src/ 
>> linux directory. "only" kernel-headers may not be enough, having  
>> the full kernel sources installed will always work though, once  
>> they have been configured properly.
>>
>> BTW, in 2.6.18 you need utsrelease.h instead of version.h
>>
>>> Also, is there a command I can use to list the version of a  
>>> loaded  module? If I'm successful with getting these drivers  
>>> compiled that  would probably be a helpful command to have.
>>
>> `modinfo e1000` shows you the version number of the properly  
>> installed e1000 module for the currently running kernel, whether  
>> the e1000 module was loaded or not.
>>
>> hth,
>>
>> Auke
>

I take that back. I was running `modinfo e1000` which was looking at  
the existing module and not the new version I had just compiled.  
`modinfo e1000.ko` worked as expected.

--
Brian McNally


On Oct 29, 2006, at 10:40 PM, Brian McNally wrote:

> I'm having some problems actually inserting the new module though.  
> After running `make` I removed the old e1000 with `modprobe -n  
> e1000` which appeared to work according to lsmod. Then, I inserted  
> the new one with `insmod e1000.ko`. According to modinfo that  
> loaded the same version of the module that I already had (7.0.33- 
> k2). Is there something I'm doing wrong here?

Thanks for the quick reply Auke. I was a bit concerned that my  
message had even be sent to the list because the sourceforge web  
interface hasn't shown any messages since 9/27/2006.

I'm using the PWLA8391GT card. I've got the full kernel source, and  
not just the headers. I ran `make versioncheck` without luck.  
However, copying my .config from /boot and running just `make` in my  
source directory created the appropriate files. I was able to compile  
the driver afterwards.

I'm having some problems actually inserting the new module though.  
After running `make` I removed the old e1000 with `modprobe -n e1000`  
which appeared to work according to lsmod. Then, I inserted the new  
one with `insmod e1000.ko`. According to modinfo that loaded the same  
version of the module that I already had (7.0.33-k2). Is there  
something I'm doing wrong here?

`lspci -vv` indicates the following:

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/ 
KM133] (rev 03)
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
         Latency: 0
         Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
         Capabilities: <available only to root>

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/ 
KM133 AGP] (prog-if 00 [Normal decode])
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
         Latency: 0
         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
         Memory behind bridge: dc000000-ddffffff
         Prefetchable memory behind bridge: d0000000-d7ffffff
         BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
         Capabilities: <available only to root>

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo  
Super South] (rev 40)
         Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping+ SERR- FastB2B-
         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 0
         Capabilities: <available only to root>

0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/ 
VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a  
[Master SecP PriP])
         Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/ 
VT8233/A/C/VT8235 PIPC Bus Master IDE
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 32
         Region 4: I/O ports at c000 [size=16]
         Capabilities: <available only to root>

0000:00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super  
ACPI] (rev 40)
         Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin ? routed to IRQ 5
         Capabilities: <available only to root>

0000:00:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3512  
[SATALink/SATARaid] Serial ATA Controller (rev 01)
         Subsystem: Silicon Image, Inc. SiI 3512 SATARaid Controller
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR+
         Latency: 32, Cache Line Size: 0x08 (32 bytes)
         Interrupt: pin A routed to IRQ 10
         Region 0: I/O ports at cc00 [size=8]
         Region 1: I/O ports at d000 [size=4]
         Region 2: I/O ports at d400 [size=8]
         Region 3: I/O ports at d800 [size=4]
         Region 4: I/O ports at dc00 [size=16]
         Region 5: Memory at df040000 (32-bit, non-prefetchable)  
[size=512]
         Expansion ROM at 20000000 [disabled] [size=512K]
         Capabilities: <available only to root>

0000:00:0b.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet  
(rev 10)
         Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet Adapter
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR+
         Latency: 32 (8000ns min, 16000ns max)
         Interrupt: pin A routed to IRQ 12
         Region 0: I/O ports at e000 [size=256]
         Region 1: Memory at df041000 (32-bit, non-prefetchable)  
[size=256]
         Capabilities: <available only to root>

0000:00:0d.0 Ethernet controller: Intel Corporation 82541PI Gigabit  
Ethernet Controller (rev 05)
         Subsystem: Intel Corporation: Unknown device 1376
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes)
         Interrupt: pin A routed to IRQ 11
         Region 0: Memory at df000000 (32-bit, non-prefetchable)  
[size=128K]
         Region 1: Memory at df020000 (32-bit, non-prefetchable)  
[size=128K]
         Region 2: I/O ports at e400 [size=64]
         Expansion ROM at 20080000 [disabled] [size=128K]
         Capabilities: <available only to root>

0000:00:0e.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet  
(rev 10)
         Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet Adapter
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR+
         Latency: 32 (8000ns min, 16000ns max)
         Interrupt: pin A routed to IRQ 10
         Region 0: I/O ports at e800 [size=256]
         Region 1: Memory at df042000 (32-bit, non-prefetchable)  
[size=256]
         Capabilities: <available only to root>

0000:01:00.0 VGA compatible controller: nVidia Corporation NV15  
[GeForce2 GTS/Pro] (rev a3) (prog-if 00 [VGA])
         Subsystem: Guillemot Corporation: Unknown device 7000
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-  
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium  
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         Latency: 32 (1250ns min, 250ns max)
         Interrupt: pin A routed to IRQ 11
         Region 0: Memory at dc000000 (32-bit, non-prefetchable)  
[size=16M]
         Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
         Expansion ROM at dd000000 [disabled] [size=64K]
         Capabilities: <available only to root>

--
Brian McNally


On Oct 29, 2006, at 6:32 PM, Auke Kok wrote:

> Brian McNally wrote:
>> Like others on this list, I've got the "e1000_clean_tx_irq:  
>> Detected  Tx Unit Hang" error. For reference, I'm running Ubuntu  
>> Server 6.06  and the 2.6.15-26 kernel. I've been told that recent  
>> versions of the  driver may fix my problem.
>
> it also depends heavily on your hardware, so please include `lspci - 
> vv` output for the device. What chipset is on your e1000?
>
>> From looking at the Makefile, it looks like I need version.h and   
>> autoconf.h. The linux-source-2.6.15 package doesn't have these  
>> files  though, which expectedly causes make to fail. What can I do  
>> to fix or  work around this? I've tried copying these files from  
>> another 2.6.15  kernel source, but that didn't work.
>
> the kernel autogenerates those as soon as you start compiling. You  
> will need them available in the sources. Depending on your distro,  
> this may be as easy as doing `make versioncheck` in your /usr/src/ 
> linux directory. "only" kernel-headers may not be enough, having  
> the full kernel sources installed will always work though, once  
> they have been configured properly.
>
> BTW, in 2.6.18 you need utsrelease.h instead of version.h
>
>> Also, is there a command I can use to list the version of a  
>> loaded  module? If I'm successful with getting these drivers  
>> compiled that  would probably be a helpful command to have.
>
> `modinfo e1000` shows you the version number of the properly  
> installed e1000 module for the currently running kernel, whether  
> the e1000 module was loaded or not.
>
> hth,
>
> Auke

Brian McNally wrote:
> Like others on this list, I've got the "e1000_clean_tx_irq: Detected  
> Tx Unit Hang" error. For reference, I'm running Ubuntu Server 6.06  
> and the 2.6.15-26 kernel. I've been told that recent versions of the  
> driver may fix my problem.

it also depends heavily on your hardware, so please include `lspci -vv` output for the 
device. What chipset is on your e1000?

> From looking at the Makefile, it looks like I need version.h and  
> autoconf.h. The linux-source-2.6.15 package doesn't have these files  
> though, which expectedly causes make to fail. What can I do to fix or  
> work around this? I've tried copying these files from another 2.6.15  
> kernel source, but that didn't work.

the kernel autogenerates those as soon as you start compiling. You will need them 
available in the sources. Depending on your distro, this may be as easy as doing `make 
versioncheck` in your /usr/src/linux directory. "only" kernel-headers may not be enough, 
having the full kernel sources installed will always work though, once they have been 
configured properly.

BTW, in 2.6.18 you need utsrelease.h instead of version.h

> Also, is there a command I can use to list the version of a loaded  
> module? If I'm successful with getting these drivers compiled that  
> would probably be a helpful command to have.

`modinfo e1000` shows you the version number of the properly installed e1000 module for 
the currently running kernel, whether the e1000 module was loaded or not.

hth,

Auke

On Sat, Oct 28, 2006 at 09:25:33PM -0600, Jason Gunthorpe wrote:
> On Fri, Oct 20, 2006 at 02:26:43PM -0700, Brandeburg, Jesse wrote:
> 
> > any luck?  I am expecting at the very least the BIOS changed behavior.
 
> Ok, I have upgraded to the latest BIOS (since I last posted yet
> another one has been released..) dmidecode says the version is now
> CO96510J.86A.5434.2006.1016.1710

Good news, I finally found out how to follow your last advice to turn
off AMT. In this BIOS it is hidden under a password protected page
called 'Intel Management Engine' and the default password is in the
AMT documentation on the intel site. The BIOS instruction guide for
this MB has no hint. Ir made me choose a new strong password (which I
will defiantely loose) before I could turn it off. :< At least it will
never get turned on again!

[This BIOS seems to be a total joke, it looks like they randomly
 tossed together a bunch of modules and gave zippo thought to how
 they work together.]

So, after doing that, and setting the management from AMT to OFF
everything works fine:

[  302.645867] in e1000_update_stats 3179
[  302.645894] e1000_update_stats 3255
[  302.645902] e1000_update_stats 3308
[  302.645904] e1000_update_stats 3321
[  302.645906] media_type 0 link_speed 1000
[  302.645954] in e1000_read_phy_reg 3363
[  302.645956] in e1000_swfw_sync_acquire 3271 0x2
[  302.645958] out e1000_swfw_sync_acquire 3275
[  302.645962] in e1000_read_phy_reg_ex 3429
[  302.646015] out e1000_read_phy_reg_ex 3492
[  302.646018] out e1000_read_phy_reg 3416
[  302.646020] e1000_update_stats 3336
[  302.646022] out e1000_update_stats 3338

$ ethtool -i eth0
driver: e1000
version: 7.1.9-k4
firmware-version: 1.1-0
bus-info: 0000:00:19.0

# ethtool -e eth0
Offset		Values
------		------
0x0000		00 16 76 c8 16 f7 00 08 ff ff 10 10 ff ff ff ff 
0x0010		ff ff ff ff c7 10 01 00 86 80 4a 10 86 80 00 00 
0x0020		01 0d 00 00 00 00 05 96 20 50 00 33 00 00 07 8d 
0x0030		84 06 41 03 00 00 00 00 00 00 00 00 00 00 00 00 
0x0040		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0050		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0x0060		00 01 00 40 2a 12 07 40 ff ff ff ff ff ff ff ff 
0x0070		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ed 5a 
0x0080		20 61 1f 00 02 0e 12 00 40 2f 1f 00 18 90 1b 00 
0x0090		00 00 12 00 a0 2f 1f 00 24 8b 11 00 f0 f8 12 00 
0x00a0		00 20 1f 00 b0 10 10 00 00 00 11 00 c0 20 1f 00 
0x00b0		9a 24 1d 00 d3 00 1e 00 a0 28 1f 00 ce 04 14 00 
0x00c0		60 2f 1f 00 e4 29 10 00 00 00 1f 00 40 01 00 00 
0x00d0		20 1f 1f 00 06 16 10 00 14 b8 11 00 2a 01 15 00 
0x00e0		67 00 1e 00 40 1f 1f 00 65 00 14 00 2a 00 15 00 
0x00f0		2a 00 16 00 60 1f 1f 00 b0 3f 12 00 ff c0 16 00 
0x0100		ec 1d 17 00 ef f9 18 00 10 02 19 00 80 18 1f 00 
0x0110		03 00 15 00 80 17 1f 00 08 00 16 00 80 17 1f 00 
0x0120		08 d0 18 00 80 18 1f 00 18 d9 18 00 60 18 1f 00 
0x0130		00 08 1a 00 00 00 1f 00 01 00 19 00 40 13 00 00 
0x0140		51 60 1f 00 01 00 11 00 00 00 1f 00 ff ff ff ff 
0x0150		ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
[snip]

I don't know what you want to take away from this.. Is this just a
BIOS bug or does the driver have to do something horrible to interface
with AMT? In any case it would be nice to have a dmesg print that
something is wrong :> 

I wonder if it also fixes my prior problem with flow control not
working?

Regards,
Jason

On Fri, Oct 20, 2006 at 02:26:43PM -0700, Brandeburg, Jesse wrote:

> any luck?  I am expecting at the very least the BIOS changed behavior.

Ok, I have upgraded to the latest BIOS (since I last posted yet
another one has been released..) dmidecode says the version is now
CO96510J.86A.5434.2006.1016.1710

With this bios I now have HPET working:
 ACPI: HPET id: 0x8086a201 base:0xfed00000
 Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.

This configuration still gives lost tick messages similar to before
when the port is in gigabit mode.

ethtool behaves the same way as before.

I turned on CONFIG_PRINTK_TIME and added printks to trace
the problem:

[  143.106472] in e1000_update_stats 3179
[  143.106501] e1000_update_stats 3255
[  143.106509] e1000_update_stats 3308
[  143.106511] e1000_update_stats 3321
[  143.106512] media_type 0 link_speed 1000
[  143.106556] in e1000_read_phy_reg 3363
[  143.106557] in e1000_swfw_sync_acquire 3271 0x2
[  143.106559] out e1000_swfw_sync_acquire 3275
[  143.206750] out e1000_get_software_flag 8385 extcnf_ctrl=0x20000a
[  143.206752] out e1000_read_phy_reg 3372
[  143.206754] e1000_update_stats 3336
[  143.206760] time.c: Lost 24 timer tick(s)! rip _spin_unlock_irqrestore+0x8/0x10)
[..]
[  143.208397] out e1000_update_stats 3338

I've included the patch I am using so you can correlate the line
numbers.

The upshot is that the e1000_get_software_flag is timing out. That is
called as part of e1000_read_phy_reg that is executed in the tail end of
the update_stats function, while holding a spin lock.

Thanks,
Jason

Like others on this list, I've got the "e1000_clean_tx_irq: Detected  
Tx Unit Hang" error. For reference, I'm running Ubuntu Server 6.06  
and the 2.6.15-26 kernel. I've been told that recent versions of the  
driver may fix my problem.

 From looking at the Makefile, it looks like I need version.h and  
autoconf.h. The linux-source-2.6.15 package doesn't have these files  
though, which expectedly causes make to fail. What can I do to fix or  
work around this? I've tried copying these files from another 2.6.15  
kernel source, but that didn't work.

Also, is there a command I can use to list the version of a loaded  
module? If I'm successful with getting these drivers compiled that  
would probably be a helpful command to have.

Thanks,

--
Brian McNally

versatile fewer doodads luggage. does really provide Readers Rave asked extras crucial XP install scanning fine detail DocuPen desktop laser printer Nikon different systems. question
See More Videos Green Day quotThe Saints Are Comingquot video:U coming hurricane katrina hours ago Category:
Betrachten bentigen Player. beginnt. Bitte whlen wenn dazu werden. Kein Player Jetzt manuell Fragen Lesen wird zur Dieses
senden Als HTML einbinden auf: MySpace Blogger TypePad Von: Bsp: An: durch Kommas trennen Text Kopie meine Adresse

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<img alt="" src="cid:par...@mo..."
 height="308" width="650"><br>
I can't do much defending beyond maintaining that I wrote the best truth
I knew. it just is okay, asking questions is unpatriotic so stop it.<br>
I think I breathed a sigh of relief. She announces that she still has
issues with me over my writing here. He works in furniture, which we
invite you to take literally.<br>
She is quiet for the first few minutes until I point this out and she
can no longer forestall the inevitable. I love you to death, you moping
creature, but it isn't right.<br>
It is OS independent as it does not rely on the underlying architecture
of the operating system, thus can support Linux, Windows Mobile,
Symbian, BREW, and .<br>
He showed greater confidence and the effortless aplomb that had once
been his hallmark. I've spent a better part of January nursing a very
resilient head cold and cultivating some warm and fuzzy new
relationships. " I was suddenly hit with such a strong feeling of utter
emptiness that I didn't have the heart to continue. Apart from whether
there will be another an acquisition, or confirming rumours that Oracle
will offer its own Linux distribution, perhaps the most pressing .<br>
You like wikis and enforcing your own opinion, don't you?<br>
She announces that she still has issues with me over my writing here.
The feeling overcame me, and for a moment I completely lost awareness of
my surroundings. Because it's no longer cool now that it's out of Beta.
The search engine isn't like you. "  He came into focus and I thought
about kissing him, but his face was turned a little bit away from me at
a funny angle, and it seemed like too much effort.<br>
You see, one cannot ask the kind of questions one needs to without
sounding desperate or deluded.<br>
Finally, they fell apart.<br>
He looks like he would be good at frisbee, but further testing will be
necessary.<br>
They are much closer than I am with Sarah presently and I am in no
position to argue and keep Sarah as a friend. Often, however, we exit a
sold-out theater feeling deceived after the hype. Debt is also good for
the economy because.<br>
developed chip and OS. Because your son will .<br>
"I can't be with you, Devin.<br>
All of this was years ago and I can't stand on my faded memories of a
couple of nights. Occasionally, it is reported that the objects seem
aware of humans and will react to being seen. I told Dana I was meeting
you and I guess she wanted to come along.<br>
The intention of this article is not to prove or disprove the reality of
these phenomena. "  Do you need me to slow down?<br>
<br>
</body>
</html>

OK. Problem solved, or at least a working workaround.

ethtool -K eth0 tso off

does it. It was my mistake to assume that tcpdump shows the =
representation of the ethernet frame that was about to go out on the =
wire. I now ran a tcpdump at the sending end and the receiving end. The =
sending end has datagrams exceeding 1500 bytes, and at the receiving end =
of the wire they are 1500 bytes or less. I think it is safe to assume my =
wires don't have the intelligence of assembling those packets :), so the =
Ethernet frames must indeed have been at most 1500+14 bytes at the =
sending side, corresponding the interfaces' set mtu of 1500.

I'm unaware of any method to determine the actual Ethernet frames length =
without hacking the code :(

#tc -s qdisc show dev eth0=20
(tso set to on)
|qdisc pfifo 11: parent 1:1 limit 1000p
| Sent 70493937 bytes 12899 pkt (dropped 0, overlimits 0 requeues 0)
| rate 0bit 0pps backlog 12112b 8p requeues 0

Note that this yields an avpkt of 5465 bytes, I would expect it to have =
been slightly less than 1500+14 bytes.

the e1000 device is a Intel Corporation 82541GI/PI Gigabit Ethernet =
Controller (rev 05) (lspci), the driver was originally the one from the =
FC5 updated kernel, but I have repeated the tests with your latest =
released "7.2.9-NAPI", with the same results.

With tc shaping to 10Mbit/s (using htb) with tso set to "on" on this =
e1000, I got a unstable throughput between 3.40MB/s and 3.80MB/s =
(measured using FTP download with ncftp client while downloading a 85MB =
file).

Repeating this with tso set to "off", now I get a very stable throughput =
of 1.13MB/s, which is about what I would expect it to be, maybe slightly =
less. Extra CPU utilization with this setting is beyond measurement =
small (load avg at the "e1000" server remains at 0.00/0.00/0.00 during =
the FTP download, indeed considering the wirespeed is only 100Mbps).

I'm going to try to have the tc guys gave a look at this. I've had a =
look at the shaping code of the kernel myself but it doesn't really make =
all sense to me :(
It would be nice that bandwidth limiting actually worked with tso set to =
on. As far as I know the tc guys don't count packets but bytes, but the =
must be something that goes horribly wrong there during those =
calculations (I haven't found a [if (size > mtu) size =3D mtu;] yet ;)

--=20
Vik Heyndrickx

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<img alt="" src="cid:par...@co..."
 height="308" width="571"><br>
com's weblog about writing. It gorges on a half-cooked stew of
suppositions, superstitions and half-finished stories.<br>
They begin to believe there is hope for them.<br>
If you subscribe and did not.<br>
It also helped him gain a new understanding of just how phenomenally
successful the bond drive really was - why the photo was such an
important national icon.<br>
The mafia fatwa threatens to turn him into an Italian Salman Rushdie.
com Autism Spectrum Disorders GuideSite.<br>
The Naples Mafia is infamous for its harsh dealings with traitors and
critics and Saviano is in serious danger.<br>
It is hard to keep in mind as you walk the manicured grounds and gaze
into the reflecting pools. Do you have a hidden desire to write your
story? He wrote a bestselling nonfiction book about the Mafia in Naples,
Italy and he named names.<br>
Contributors include Lawrence C.<br>
The mafia fatwa threatens to turn him into an Italian Salman
Rushdie.<br>
I wrote the introduction to this.<br>
Their eyes grow a little less hard. Ryan was very persistent, phoning my
agent, emailing him. Jamie Manning's CD "What Remains" is a musical
testament to his experiences as a father of a child on the autism
spectrum. He wrote a bestselling nonfiction book about the Mafia in
Naples, Italy and he named names. Stephen Shore, an adult on the autism
spectrum and an international. com Guide to Autism is having a great
reason to call and interview some of the top names in the field.<br>
Other days it darts across to the waiting writer, bites him and then
turns tail.<br>
and the strange people who want a taste of the action.<br>
It is hard to keep in mind as you walk the manicured grounds and gaze
into the reflecting pools. He also provides detailed descriptions of the
inner workings of the criminal organization. Writers, too, have begun
rallying to his side. It just felt so incredibly fresh watching Annette
Bening and Alec Baldwin fight in that scene in the kitchen. com Asia for
Visitors GuideSite. It gorges on a half-cooked stew of suppositions,
superstitions and half-finished stories. Jamie Manning's CD "What
Remains" is a musical testament to his experiences as a father of a
child on the autism spectrum.<br>
Net, the world's best motorsport portal. Do you have a hidden desire to
write your story? There were so many things in this movie are so close
to life it just makes me shiver. There were so many things in this movie
are so close to life it just makes me shiver.<br>
com Autism Spectrum Disorders GuideSite.<br>
The mafia fatwa threatens to turn him into an Italian Salman Rushdie.<br>
<br>
</body>
</html>

Vik Heyndrickx wrote:
> I'm having a big problem with e1000. It sends out packets that are
> larger than the MTU. This causes tc (linux traffic control) to get
> confused: the data is going out the interface roughly three times
> faster than the configured rate. This problem does not exist with
> another nic installed in the same system.   =20
>=20
> It's a Fedora Core 5 system upgraded to the latest packages. These
> are the relevant bits of information of my systems:=20
>=20
> # uname -a
> Linux alexandria.edch 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:56
> EDT 2006 x86_64 x86_64 x86_64 GNU/Linux=20
<snip>

> If there a way to configure the driver not to do this? I want my
> packets limited to 1500 standard sized ethernet frames.=20

Those are TSO frames.  Ethereal shows them as huge frames because before
they get to the driver they are.  The frames are then segmented to MTU
size by the hardware.   you can disable it by disabling TSO using
ethtool, it will however cost you some CPU, but at 100Mb/s that probably
won't be a big deal.  The command is:
ethtool -K eth0 tso off

seems like tc should be using byte counts instead of frame counts,
sounds like a bug in tc :-(

Let us know if you have more issues
 Jesse

Also, output from:

ifconfig -a   (this will show what the MTU is set at for the interface)
ethtool -i ethx
ethtool ethx
netstat -i


Cheers,
John
-----------------------------------------------------------
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.", Benjamin
Franklin 1755=20


> -----Original Message-----
> From: e10...@li...=20
> [mailto:e10...@li...] On Behalf=20
> Of Auke Kok
> Sent: Friday, October 27, 2006 8:33 AM
> To: Vik Heyndrickx
> Cc: e1000-list
> Subject: Re: [E1000-devel] e1000 driver is sending jumbo=20
> frames exceeding mtu
>=20
>=20
> Vik Heyndrickx wrote:
> > Hi,
> >=20
> > I'm having a big problem with e1000. It sends out packets=20
> that are larger than the MTU. This causes tc (linux traffic=20
> control) to get confused: the data is going out the interface=20
> roughly three times faster than the configured rate. This=20
> problem does not exist with another nic installed in the same system.
> >=20
> > It's a Fedora Core 5 system upgraded to the latest=20
> packages. These are the relevant bits of information of my systems:
> >=20
> > # uname -a
> > Linux alexandria.edch 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14=20
> 16:59:56 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> >=20
> > # cat /var/log/messages | grep 'e1000:'
> > Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:01.0:=20
> e1000_probe: (PCI:66MHz:32-bit) xx:xx:xx:xx:xx:42
> > Oct 27 12:19:45 alexandria kernel: e1000: eth0:=20
> e1000_probe: Intel(R) PRO/1000 Network Connection
> > Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:02.0:=20
> e1000_probe: (PCI:66MHz:32-bit) xx:xx:xx:xx:xx:43
> > Oct 27 12:19:45 alexandria kernel: e1000: eth1:=20
> e1000_probe: Intel(R) PRO/1000 Network Connection
> > Oct 27 12:19:46 alexandria kernel: e1000: eth0:=20
> e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
> > Oct 27 12:19:46 alexandria kernel: e1000: eth1:=20
> e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
>=20
> I prefer to see the driver version too, and really we need=20
> the full dmesg output.
>=20
> lspci -vv ? I'd like to know what hardware you have too.
>=20
> > # ip link show
> > 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc=20
> pfifo_fast qlen 100
> >     link/ether xx:xx:xx:xx:xx:42 brd ff:ff:ff:ff:ff:ff
> > 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc=20
> pfifo_fast qlen 100
> >     link/ether xx:xx:xx:xx:xx:43 brd ff:ff:ff:ff:ff:ff
> >=20
> > This is a small portion of a packet trace (tcpdump) during=20
> an FTP download from server 10.33.1.21 to client 10.33.1.254:=20
> notice the large packets going out.
>=20
> so is 10.33.1.21 the e1000 NIC? this is not really clear...
>=20
> > 13:18:12.915056 IP (tos 0x8, ttl  64, id 42189, offset 0,=20
> flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42872385:42873833(1448) ack 1 win 46=20
> <nop,nop,timestamp 596232 304808104>
> > 13:18:12.915178 IP (tos 0x8, ttl  64, id 42190, offset 0,=20
> flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42873833:42875281(1448) ack 1 win 46=20
> <nop,nop,timestamp 596232 304808104>
> > 13:18:12.915308 IP (tos 0x8, ttl  64, id 42191, offset 0,=20
> flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42875281:42876729(1448) ack 1 win 46=20
> <nop,nop,timestamp 596232 304808104>
> > 13:18:12.916044 IP (tos 0x8, ttl  64, id 42192, offset 0,=20
> flags [DF], proto: TCP (6), length: 10188) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42876729:42886865(10136) ack 1 win 46=20
> <nop,nop,timestamp 596232 304808104>
> > 13:18:12.916917 IP (tos 0x8, ttl  64, id 42199, offset 0,=20
> flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42886865:42894105(7240) ack 1 win 46=20
> <nop,nop,timestamp 596232 304808104>
> > 13:18:12.917293 IP (tos 0x8, ttl  64, id 42204, offset 0,=20
> flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42894105:42901345(7240) ack 1 win 46=20
> <nop,nop,timestamp 596232 304808104>
> > 13:18:12.918168 IP (tos 0x8, ttl  64, id 42209, offset 0,=20
> flags [DF], proto: TCP (6), length: 10188) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42901345:42911481(10136) ack 1 win 46=20
> <nop,nop,timestamp 596233 304808105>
> > 13:18:12.918918 IP (tos 0x8, ttl  64, id 42216, offset 0,=20
> flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42911481:42920169(8688) ack 1 win 46=20
> <nop,nop,timestamp 596233 304808105>
> > 13:18:12.919667 IP (tos 0x8, ttl  64, id 42222, offset 0,=20
> flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42920169:42928857(8688) ack 1 win 46=20
> <nop,nop,timestamp 596233 304808105>
> > 13:18:12.920166 IP (tos 0x8, ttl  64, id 42228, offset 0,=20
> flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42928857:42936097(7240) ack 1 win 46=20
> <nop,nop,timestamp 596233 304808105>
> > 13:18:12.920791 IP (tos 0x8, ttl  64, id 42233, offset 0,=20
> flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42936097:42944785(8688) ack 1 win 46=20
> <nop,nop,timestamp 596233 304808105>
> > 13:18:12.921540 IP (tos 0x8, ttl  64, id 42239, offset 0,=20
> flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 >=20
> 10.33.1.254.44645: . 42944785:42953473(8688) ack 1 win 46=20
> <nop,nop,timestamp 596233 304808105>
> >=20
> > If there a way to configure the driver not to do this? I=20
> want my packets limited to 1500 standard sized ethernet frames.
>=20
> the driver should adhere to the MTU for sending packets on=20
> the wire. If it isn't then=20
> it's a big bug. But right now I don't have enough information=20
> from this report to=20
> investigate, so please provide us with the extra information.
>=20
> Cheers,
>=20
> Auke
>=20
> >=20
> > Thanks,
> >=20
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
_______________________________________________
E1000-devel mailing list
E10...@li...
https://lists.sourceforge.net/lists/listinfo/e1000-devel

Vik Heyndrickx wrote:
> Hi,
> 
> I'm having a big problem with e1000. It sends out packets that are larger than the MTU. This causes tc (linux traffic control) to get confused: the data is going out the interface roughly three times faster than the configured rate. This problem does not exist with another nic installed in the same system.
> 
> It's a Fedora Core 5 system upgraded to the latest packages. These are the relevant bits of information of my systems:
> 
> # uname -a
> Linux alexandria.edch 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:56 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> 
> # cat /var/log/messages | grep 'e1000:'
> Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:01.0: e1000_probe: (PCI:66MHz:32-bit) xx:xx:xx:xx:xx:42
> Oct 27 12:19:45 alexandria kernel: e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:02.0: e1000_probe: (PCI:66MHz:32-bit) xx:xx:xx:xx:xx:43
> Oct 27 12:19:45 alexandria kernel: e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
> Oct 27 12:19:46 alexandria kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
> Oct 27 12:19:46 alexandria kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex

I prefer to see the driver version too, and really we need the full dmesg output.

lspci -vv ? I'd like to know what hardware you have too.

> # ip link show
> 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100
>     link/ether xx:xx:xx:xx:xx:42 brd ff:ff:ff:ff:ff:ff
> 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 100
>     link/ether xx:xx:xx:xx:xx:43 brd ff:ff:ff:ff:ff:ff
> 
> This is a small portion of a packet trace (tcpdump) during an FTP download from server 10.33.1.21 to client 10.33.1.254: notice the large packets going out.

so is 10.33.1.21 the e1000 NIC? this is not really clear...

> 13:18:12.915056 IP (tos 0x8, ttl  64, id 42189, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . 42872385:42873833(1448) ack 1 win 46 <nop,nop,timestamp 596232 304808104>
> 13:18:12.915178 IP (tos 0x8, ttl  64, id 42190, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . 42873833:42875281(1448) ack 1 win 46 <nop,nop,timestamp 596232 304808104>
> 13:18:12.915308 IP (tos 0x8, ttl  64, id 42191, offset 0, flags [DF], proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . 42875281:42876729(1448) ack 1 win 46 <nop,nop,timestamp 596232 304808104>
> 13:18:12.916044 IP (tos 0x8, ttl  64, id 42192, offset 0, flags [DF], proto: TCP (6), length: 10188) 10.33.1.21.14224 > 10.33.1.254.44645: . 42876729:42886865(10136) ack 1 win 46 <nop,nop,timestamp 596232 304808104>
> 13:18:12.916917 IP (tos 0x8, ttl  64, id 42199, offset 0, flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . 42886865:42894105(7240) ack 1 win 46 <nop,nop,timestamp 596232 304808104>
> 13:18:12.917293 IP (tos 0x8, ttl  64, id 42204, offset 0, flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . 42894105:42901345(7240) ack 1 win 46 <nop,nop,timestamp 596232 304808104>
> 13:18:12.918168 IP (tos 0x8, ttl  64, id 42209, offset 0, flags [DF], proto: TCP (6), length: 10188) 10.33.1.21.14224 > 10.33.1.254.44645: . 42901345:42911481(10136) ack 1 win 46 <nop,nop,timestamp 596233 304808105>
> 13:18:12.918918 IP (tos 0x8, ttl  64, id 42216, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42911481:42920169(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105>
> 13:18:12.919667 IP (tos 0x8, ttl  64, id 42222, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42920169:42928857(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105>
> 13:18:12.920166 IP (tos 0x8, ttl  64, id 42228, offset 0, flags [DF], proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . 42928857:42936097(7240) ack 1 win 46 <nop,nop,timestamp 596233 304808105>
> 13:18:12.920791 IP (tos 0x8, ttl  64, id 42233, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42936097:42944785(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105>
> 13:18:12.921540 IP (tos 0x8, ttl  64, id 42239, offset 0, flags [DF], proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . 42944785:42953473(8688) ack 1 win 46 <nop,nop,timestamp 596233 304808105>
> 
> If there a way to configure the driver not to do this? I want my packets limited to 1500 standard sized ethernet frames.

the driver should adhere to the MTU for sending packets on the wire. If it isn't then 
it's a big bug. But right now I don't have enough information from this report to 
investigate, so please provide us with the extra information.

Cheers,

Auke

> 
> Thanks,
> 

Hi,

I'm having a big problem with e1000. It sends out packets that are =
larger than the MTU. This causes tc (linux traffic control) to get =
confused: the data is going out the interface roughly three times faster =
than the configured rate. This problem does not exist with another nic =
installed in the same system.

It's a Fedora Core 5 system upgraded to the latest packages. These are =
the relevant bits of information of my systems:

# uname -a
Linux alexandria.edch 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:56 EDT =
2006 x86_64 x86_64 x86_64 GNU/Linux

# cat /var/log/messages | grep 'e1000:'
Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:01.0: e1000_probe: =
(PCI:66MHz:32-bit) xx:xx:xx:xx:xx:42
Oct 27 12:19:45 alexandria kernel: e1000: eth0: e1000_probe: Intel(R) =
PRO/1000 Network Connection
Oct 27 12:19:45 alexandria kernel: e1000: 0000:06:02.0: e1000_probe: =
(PCI:66MHz:32-bit) xx:xx:xx:xx:xx:43
Oct 27 12:19:45 alexandria kernel: e1000: eth1: e1000_probe: Intel(R) =
PRO/1000 Network Connection
Oct 27 12:19:46 alexandria kernel: e1000: eth0: e1000_watchdog: NIC Link =
is Up 100 Mbps Full Duplex
Oct 27 12:19:46 alexandria kernel: e1000: eth1: e1000_watchdog: NIC Link =
is Up 100 Mbps Full Duplex

# ip link show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen =
100
    link/ether xx:xx:xx:xx:xx:42 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen =
100
    link/ether xx:xx:xx:xx:xx:43 brd ff:ff:ff:ff:ff:ff

This is a small portion of a packet trace (tcpdump) during an FTP =
download from server 10.33.1.21 to client 10.33.1.254: notice the large =
packets going out.

13:18:12.915056 IP (tos 0x8, ttl  64, id 42189, offset 0, flags [DF], =
proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42872385:42873833(1448) ack 1 win 46 <nop,nop,timestamp 596232 =
304808104>
13:18:12.915178 IP (tos 0x8, ttl  64, id 42190, offset 0, flags [DF], =
proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42873833:42875281(1448) ack 1 win 46 <nop,nop,timestamp 596232 =
304808104>
13:18:12.915308 IP (tos 0x8, ttl  64, id 42191, offset 0, flags [DF], =
proto: TCP (6), length: 1500) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42875281:42876729(1448) ack 1 win 46 <nop,nop,timestamp 596232 =
304808104>
13:18:12.916044 IP (tos 0x8, ttl  64, id 42192, offset 0, flags [DF], =
proto: TCP (6), length: 10188) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42876729:42886865(10136) ack 1 win 46 <nop,nop,timestamp 596232 =
304808104>
13:18:12.916917 IP (tos 0x8, ttl  64, id 42199, offset 0, flags [DF], =
proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42886865:42894105(7240) ack 1 win 46 <nop,nop,timestamp 596232 =
304808104>
13:18:12.917293 IP (tos 0x8, ttl  64, id 42204, offset 0, flags [DF], =
proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42894105:42901345(7240) ack 1 win 46 <nop,nop,timestamp 596232 =
304808104>
13:18:12.918168 IP (tos 0x8, ttl  64, id 42209, offset 0, flags [DF], =
proto: TCP (6), length: 10188) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42901345:42911481(10136) ack 1 win 46 <nop,nop,timestamp 596233 =
304808105>
13:18:12.918918 IP (tos 0x8, ttl  64, id 42216, offset 0, flags [DF], =
proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42911481:42920169(8688) ack 1 win 46 <nop,nop,timestamp 596233 =
304808105>
13:18:12.919667 IP (tos 0x8, ttl  64, id 42222, offset 0, flags [DF], =
proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42920169:42928857(8688) ack 1 win 46 <nop,nop,timestamp 596233 =
304808105>
13:18:12.920166 IP (tos 0x8, ttl  64, id 42228, offset 0, flags [DF], =
proto: TCP (6), length: 7292) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42928857:42936097(7240) ack 1 win 46 <nop,nop,timestamp 596233 =
304808105>
13:18:12.920791 IP (tos 0x8, ttl  64, id 42233, offset 0, flags [DF], =
proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42936097:42944785(8688) ack 1 win 46 <nop,nop,timestamp 596233 =
304808105>
13:18:12.921540 IP (tos 0x8, ttl  64, id 42239, offset 0, flags [DF], =
proto: TCP (6), length: 8740) 10.33.1.21.14224 > 10.33.1.254.44645: . =
42944785:42953473(8688) ack 1 win 46 <nop,nop,timestamp 596233 =
304808105>

If there a way to configure the driver not to do this? I want my packets =
limited to 1500 standard sized ethernet frames.

Thanks,

--=20
Vik Heyndrickx