I installed the new driver with your procedures below, and issued a "modprobe e1000 TxDescriptorStep=4,4,4 My dmesg logs finally showed parameters :
Oct 7 16:41:43 localhost NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx >= 0' failed Oct 7 16:41:43 localhost NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx >= 0' failed Oct 7 16:41:43 localhost kernel: e1000 0000:00:0b.0: PCI INT A disabled Oct 7 16:41:43 localhost kernel: Intel(R) PRO/1000 Network Driver - version 8.0.16-NAPI Oct 7 16:41:43 localhost kernel: Copyright (c) 1999-2009 Intel Corporation. Oct 7 16:41:43 localhost kernel: e1000 0000:00:0b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 Oct 7 16:41:43 localhost kernel: e1000 0000:00:0b.0: PCI: Disallowing DAC for device Oct 7 16:41:44 localhost kernel: e1000: 0000:00:0b.0: e1000_validate_option: Transmit_descriptor_step = 4 Oct 7 16:41:44 localhost kernel: e1000: 0000:00:0b.0: e1000_probe: (PCI:33MHz:32-bit) 00:1b:21:0b:dd:da Oct 7 16:41:44 localhost kernel: e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Oct 7 16:41:44 localhost kernel: e1000 0000:00:0c.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 Oct 7 16:41:44 localhost kernel: e1000 0000:00:0c.0: PCI: Disallowing DAC for device Oct 7 16:41:44 localhost kernel: e1000: 0000:00:0c.0: e1000_validate_option: Transmit_descriptor_step = 4 Oct 7 16:41:44 localhost kernel: e1000: 0000:00:0c.0: e1000_probe: (PCI:33MHz:32-bit) 00:1b:21:0c:6b:5b Oct 7 16:41:44 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 7 16:41:44 localhost kernel: e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection Oct 7 16:41:44 localhost kernel: e1000 0000:00:0d.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 Oct 7 16:41:44 localhost kernel: e1000 0000:00:0d.0: PCI: Disallowing DAC for device Oct 7 16:41:45 localhost kernel: e1000: 0000:00:0d.0: e1000_validate_option: Transmit_descriptor_step = 4 Oct 7 16:41:45 localhost kernel: e1000: 0000:00:0d.0: e1000_probe: (PCI:33MHz:32-bit) 00:1b:21:0c:71:40 Oct 7 16:41:45 localhost kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Oct 7 16:41:45 localhost kernel: e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection Oct 7 16:41:45 localhost NetworkManager: <info> (eth0): cleaning up... Oct 7 16:41:45 localhost NetworkManager: <info> (eth0): taking down device. Oct 7 16:41:45 localhost nm-dispatcher.action: Error in get_property: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist#012 Oct 7 16:41:46 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready Oct 7 16:41:47 localhost kernel: e1000: eth1: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Oct 7 16:41:47 localhost dnsmasq[2520]: no servers found in /etc/ resolv.conf, will retry Oct 7 16:41:47 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Oct 7 16:41:47 localhost kernel: e1000: eth2: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Oct 7 16:41:47 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Oct 7 16:41:48 localhost avahi-daemon[2465]: Registering new address record for fe80::21b:21ff:fe0c:6b5b on eth1.*. Oct 7 16:41:49 localhost NET[12598]: /etc/sysconfig/network-scripts/ ifup-post : updated /etc/resolv.conf Oct 7 16:41:49 localhost NetworkManager: <info> eth0: driver is 'e1000'. Oct 7 16:41:49 localhost NetworkManager: <info> Found new Ethernet device 'eth0'. Oct 7 16:41:49 localhost NetworkManager: <info> (eth0): exported as / org/freedesktop/Hal/devices/net_00_1b_21_0b_dd_da Oct 7 16:41:49 localhost avahi-daemon[2465]: Registering new address record for fe80::21b:21ff:fe0c:7140 on eth2.*. Oct 7 16:41:50 localhost avahi-daemon[2465]: New relevant interface eth1.IPv4 for mDNS. Oct 7 16:41:50 localhost avahi-daemon[2465]: Registering new address record for 10.100.0.9 on eth1.IPv4. Oct 7 16:41:50 localhost NetworkManager: <info> eth1: driver is 'e1000'. Oct 7 16:41:50 localhost NetworkManager: <info> Found new Ethernet device 'eth1'. Oct 7 16:41:50 localhost NetworkManager: <info> (eth1): exported as / org/freedesktop/Hal/devices/net_00_1b_21_0c_6b_5b Oct 7 16:41:50 localhost NetworkManager: <info> (eth1): carrier now ON (device state 1) Oct 7 16:41:51 localhost avahi-daemon[2465]: New relevant interface eth2.IPv4 for mDNS. Oct 7 16:41:51 localhost avahi-daemon[2465]: Registering new address record for 172.16.100.254 on eth2.IPv4. Oct 7 16:41:51 localhost NetworkManager: <info> eth2: driver is 'e1000'. Oct 7 16:41:51 localhost NetworkManager: <info> Found new Ethernet device 'eth2'. Oct 7 16:41:51 localhost NetworkManager: <info> (eth2): exported as / org/freedesktop/Hal/devices/net_00_1b_21_0c_71_40 Oct 7 16:41:51 localhost NetworkManager: <info> (eth2): carrier now ON (device state 1) Oct 7 16:41:53 localhost NetworkManager: <info> (eth0): device state change: 1 -> 2 Oct 7 16:41:53 localhost NetworkManager: <info> (eth0): bringing up device. Oct 7 16:41:53 localhost avahi-daemon[2465]: New relevant interface eth0.IPv4 for mDNS. Oct 7 16:41:53 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 7 16:41:53 localhost NetworkManager: <info> (eth0): preparing device. Oct 7 16:41:53 localhost NetworkManager: <info> (eth0): deactivating device (reason: 2). Oct 7 16:41:53 localhost avahi-daemon[2465]: Interface eth0.IPv4 no longer relevant for mDNS. Oct 7 16:41:54 localhost kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX Oct 7 16:41:54 localhost NetworkManager: <info> (eth0): carrier now ON (device state 2) Oct 7 16:41:54 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Then I issued a "ethtool -K eth0 tso off" Oct 7 16:43:56 localhost kernel: e1000: eth0: e1000_set_tso: TSO is Disabled Then I asked my collogue of mine to issue a fast, and large download from one of my FTP servers. As soon as he reached about 10 - 11 MB/s in transfer rate it looks like the eth0 interface just goes down, and pops up somewhat again. I get these in my logs : Oct 7 16:55:36 localhost kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX (I think this comes right after I execute my firewall script) One thing I don't understand is, if the interface goes down and comes right up after 1-2sec or so, why doesn't the firewall (netfilter) rules hang in ? Why do I have to relaunch interface config, and netfilter rules ? At the end, I will defiantly try to replace my HP Procurve 2524 with another one, but I don't think the Procurve is the problem.... Or what? As today the port, and the interface are both configured with AutoNeg, And Full Duplex… As before, I had a another firewall server that had the old 3COM 3C905 cards. In time to time, I also got Tx Unit hangs on those cards, but the internet link, and or netfilter rules, network configuration never crashed. It just keep going and going regard of those tx unit hangs. That was one of my main reasons I upgraded to INTEL e1000 cards. To upgrade my old PC, 3com cards and to handle my 100MB fiber dark fiber with ~200 devices connected in 3-4 networks doing NAT and pretty things. Correct me if I'm wrong, this Tx Unit hang problem on e1000 is what most related to AMD, and or AMD chipset platforms ? Today I found a old PC that only collects dust in my company. It has the legendary Intel 440BX (same as in Cisco Pix) chipset and also 2x SMP Intel Celeron 533 CPU's. Would it be a problem solver to change my rusty AMD, VIA combination in my current firewall to a rock solid 440BX with Intel CPU's ? I remember, that I never had any problems at all with PIII and or Intel chipset mobos in the past. Thanks allot. In desperate need for help. :) Best regards, Svavar O Reykjavik - Iceland On 7.10.2009, at 16:30, Graham, David wrote: > Svavar Örn Eysteinsson wrote: >> Well, finally applied the 8.0.16 driver and before updated the kernel >> to : 2.6.27.35-170.2.94.fc10.i686. >> Restarted the firewall so the newly installed kernel would run, >> compiled the driver and installed it. >> filename: /lib/modules/2.6.27.35-170.2.94.fc10.i686/kernel/ >> drivers/net/e1000/e1000.ko >> version: 8.0.16-NAPI >> license: GPL >> description: Intel(R) PRO/1000 Network Driver >> author: Intel Corporation, <linux.n...@intel.com> >> srcversion: D8FA73DEE439DF241A1B835 >> Issued a "modprobe e1000 TxDescriptorStep=4,4,4" and executed my >> firewall script that also configures the interfaces. > On rereading my original instructions, I see that they were not > accurate, and if you followed them exactly, the new driver would not > have been loaded with the proper parameters. The thing I forgot was > to make sure that the old driver version was removed before the > modprobe of the new one. If the old driver remained installed, the > modprobe would simply have been ignored. The corrected instructions > are as follows: > > cd <src directory of the e1000-8.0.16 driver> > make install > rmmod e1000 > modprobe e1000 TxDescriptorStep=4,4,4 > > To double-check that the new module version is loaded with the > proper parameters, please have a look at dmesg after you perform the > modprobe. If it is effective, it will include a line with > > "e1000_validate_option: Transmit descriptor step = 4" > >> This was early this morning. >> Now, just recently I got the TX Unit Hang again on eth0 interface >> (the >> public interface) : >> ( Same as usual, no traffic in or out ). had to re-execute the >> firewall script to >> Oct 6 15:32:54 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >> Detected Tx Unit Hang >> Oct 6 15:32:54 localhost kernel: Tx Queue <0> >> Oct 6 15:32:54 localhost kernel: TDH <49> > >> Could this be releated to a very high traffic on my public interface. >> Becouse, just at that moment my collegue downloaded from one of my >> FTP >> servers trough my firewall at ~11.1 MB/s > Quite likely. Previous occurrences of TXHangs on this Hardware are > related to high TX traffic on the hanging interface. It's be a good > way to test for the issue. >> That was about 15:30 or so, and this TX Unit problem came at 15:32 or >> so. >> Should I disable TSO for the adapters ? >> ethtool -K eth0 tso off >> ethtool -K eth1 tso off >> ethtool -K eth2 tso off > Good idea. The more "advanced" features that you can turn off the > better. > > I'm also interested to know if the issue occurs without the firewall > script, simply running ip_forward and no firewall. Do you know. > >> Also, My firewall public interface is connected to HP Procurve 2524 >> switch. > Thanks. I am trying to configure a similar setup here. >> Svavar O >> Reykjavik - Iceland >> ______________________________________ >> On 1.10.2009, at 22:48, Graham, David wrote: >>> Hi Svavar, >>> This looks like a problem that we have seen before on similar >>> platforms, and I'm hoping that the workaround we have already >>> provided will resolve the issue. Please follow these steps and let >>> us know. >>> >>> First, we will need to update your driver version from 8.0.6 to the >>> latest, which includes the workaround. >>> Please download the e1000-8.0.16 driver from the e1000 sourceforge >>> site. You'll see the driver tarball when you click on the e1000 >>> stable link at https://sourceforge.net/projects/e1000/files/ >>> >>> Extract the tarball >>> >>> tar xvzf e1000-8.0.16.tar.gz >>> >>> Build it >>> cd e1000-8.0.16/src >>> make >>> >>> Install using the new TxDescriptorStep parameter for each of your 3 >>> interfaces to activate the workaround. >>> >>> modprobe e1000 TxDescriptorStep=4,4,4 >>> >>> >>> Bring the interfaces up and retest. >>> >>> Please let me know if you need more detail, and I will be glad to >>> help further. >>> >>> Dave >>> >>> >>> -----Original Message----- >>> From: Svavar Örn Eysteinsson [mailto:sva...@fiton.is] >>> Sent: Thursday, October 01, 2009 4:43 AM >>> To: e1000-devel@lists.sourceforge.net >>> Subject: [E1000-devel] TX Unit hang with Intel Pro/1000 (82541PI) >>> (e1000) driver on Firewall/NAT machine. Help needed >>> >>> Hi. >>> I'm having a very serious trouble with TX Unit Hang on my Firewall/ >>> NAT >>> machine that serves >>> 100 pc's and devices and 4 networks. >>> >>> The machine has 1.5GB in RAM, AMD Sempron(tm) Processor 2600+ at >>> 1.6Ghz. >>> The network cards consist of 3 pieces of Intel Pro/1000 GT Desktop >>> Adapters 82541PI (rev 05), >>> and one VIA [Rhine-II] network card. >>> >>> My OS is Fedora 10, with 2.6.27.15-170 KERNEL. >>> My e1000 driver is 8.0.6-NAPI >>> Iptables is 1.4.1.1 >>> >>> >>> To my problem. Every now and then, I get a "TX Unit Hang" on >>> mostly on >>> my ETH1 >>> interface (that is a internal interface) but now these days I'm >>> getting it at my EXTERNAL >>> interface (eth0). >>> >>> When this Tx Unit Hangs comes up. No traffic is generated in or >>> out on >>> my firewall machine. >>> To fix the problem I have to relaunch the Firewall script. Script >>> generated by Fwbuilder. >>> When the script has relaunched all traffic is normal. >>> >>> We also host many WWW servers, and email servers. I' have recently >>> inserted a scheduled >>> cron job to relaunch the firewall script at 1hour basis, but that is >>> not a solution >>> for this problem. >>> >>> Can someone help me out, or give me some information regarding this >>> annoying problem. >>> >>> Thanks in advance. >>> >>> Best regards, >>> >>> Svavar O >>> Reykjavik - Iceland. >>> >>> >>> < Here's my messages.log output > >>> >>> Sep 30 00:33:20 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Sep 30 00:33:20 localhost kernel: Tx Queue <0> >>> Sep 30 00:33:20 localhost kernel: TDH <c3> >>> Sep 30 00:33:20 localhost kernel: TDT <c3> >>> Sep 30 00:33:20 localhost kernel: next_to_use <c3> >>> Sep 30 00:33:20 localhost kernel: next_to_clean <d7> >>> Sep 30 00:33:20 localhost kernel: buffer_info[next_to_clean] >>> Sep 30 00:33:20 localhost kernel: time_stamp <dae9c1d0> >>> Sep 30 00:33:20 localhost kernel: next_to_watch <d7> >>> Sep 30 00:33:20 localhost kernel: jiffies <dae9cb38> >>> Sep 30 00:33:20 localhost kernel: next_to_watch.status <0> >>> Sep 30 00:33:22 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Sep 30 00:33:22 localhost kernel: Tx Queue <0> >>> Sep 30 00:33:22 localhost kernel: TDH <c3> >>> Sep 30 00:33:22 localhost kernel: TDT <c3> >>> Sep 30 00:33:22 localhost kernel: next_to_use <c3> >>> Sep 30 00:33:22 localhost kernel: next_to_clean <d7> >>> Sep 30 00:33:22 localhost kernel: buffer_info[next_to_clean] >>> Sep 30 00:33:22 localhost kernel: time_stamp <dae9c1d0> >>> Sep 30 00:33:22 localhost kernel: next_to_watch <d7> >>> Sep 30 00:33:22 localhost kernel: jiffies <dae9d308> >>> Sep 30 00:33:22 localhost kernel: next_to_watch.status <0> >>> >>> Oct 1 11:17:31 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Oct 1 11:17:31 localhost kernel: Tx Queue <0> >>> Oct 1 11:17:31 localhost kernel: TDH <e2> >>> Oct 1 11:17:31 localhost kernel: TDT <e2> >>> Oct 1 11:17:31 localhost kernel: next_to_use <e2> >>> Oct 1 11:17:31 localhost kernel: next_to_clean <f6> >>> Oct 1 11:17:31 localhost kernel: buffer_info[next_to_clean] >>> Oct 1 11:17:31 localhost kernel: time_stamp <e25de7af> >>> Oct 1 11:17:31 localhost kernel: next_to_watch <f6> >>> Oct 1 11:17:31 localhost kernel: jiffies <e25debb0> >>> Oct 1 11:17:31 localhost kernel: next_to_watch.status <0> >>> Oct 1 11:17:33 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Oct 1 11:17:33 localhost kernel: Tx Queue <0> >>> Oct 1 11:17:33 localhost kernel: TDH <e2> >>> Oct 1 11:17:33 localhost kernel: TDT <e2> >>> Oct 1 11:17:33 localhost kernel: next_to_use <e2> >>> Oct 1 11:17:33 localhost kernel: next_to_clean <f6> >>> Oct 1 11:17:33 localhost kernel: buffer_info[next_to_clean] >>> Oct 1 11:17:33 localhost kernel: time_stamp <e25de7af> >>> Oct 1 11:17:33 localhost kernel: next_to_watch <f6> >>> Oct 1 11:17:33 localhost kernel: jiffies <e25df380> >>> Oct 1 11:17:33 localhost kernel: next_to_watch.status <0> >>> Oct 1 11:17:35 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Oct 1 11:17:35 localhost kernel: Tx Queue <0> >>> Oct 1 11:17:35 localhost kernel: TDH <e2> >>> Oct 1 11:17:35 localhost kernel: TDT <e2> >>> Oct 1 11:17:35 localhost kernel: next_to_use <e2> >>> Oct 1 11:17:35 localhost kernel: next_to_clean <f6> >>> Oct 1 11:17:35 localhost kernel: buffer_info[next_to_clean] >>> Oct 1 11:17:35 localhost kernel: time_stamp <e25de7af> >>> Oct 1 11:17:35 localhost kernel: next_to_watch <f6> >>> Oct 1 11:17:35 localhost kernel: jiffies <e25dfb50> >>> Oct 1 11:17:35 localhost kernel: next_to_watch.status <0> >>> Oct 1 11:17:37 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Oct 1 11:17:37 localhost kernel: Tx Queue <0> >>> Oct 1 11:17:37 localhost kernel: TDH <e2> >>> Oct 1 11:17:37 localhost kernel: TDT <e2> >>> Oct 1 11:17:37 localhost kernel: next_to_use <e2> >>> Oct 1 11:17:37 localhost kernel: next_to_clean <f6> >>> Oct 1 11:17:37 localhost kernel: buffer_info[next_to_clean] >>> Oct 1 11:17:37 localhost kernel: time_stamp <e25de7af> >>> Oct 1 11:17:37 localhost kernel: next_to_watch <f6> >>> Oct 1 11:17:37 localhost kernel: jiffies <e25e0320> >>> Oct 1 11:17:37 localhost kernel: next_to_watch.status <0> >>> Oct 1 11:17:39 localhost kernel: e1000: eth0: e1000_clean_tx_irq: >>> Detected Tx Unit Hang >>> Oct 1 11:17:39 localhost kernel: Tx Queue <0> >>> Oct 1 11:17:39 localhost kernel: TDH <e2> >>> Oct 1 11:17:39 localhost kernel: TDT <e2> >>> Oct 1 11:17:39 localhost kernel: next_to_use <e2> >>> Oct 1 11:17:39 localhost kernel: next_to_clean <f6> >>> Oct 1 11:17:39 localhost kernel: buffer_info[next_to_clean] >>> Oct 1 11:17:39 localhost kernel: time_stamp <e25de7af> >>> Oct 1 11:17:39 localhost kernel: next_to_watch <f6> >>> Oct 1 11:17:39 localhost kernel: jiffies <e25e0af0> >>> Oct 1 11:17:39 localhost kernel: next_to_watch.status <0> >>> >>> >>> >>> >>> >>> lspci shows : >>> >>> 00:00.0 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge >>> 00:00.1 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge >>> 00:00.2 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge >>> 00:00.3 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge >>> 00:00.4 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge >>> 00:00.7 Host bridge: VIA Technologies, Inc. K8M800 Host Bridge >>> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge >>> [K8T800/ >>> K8T890 South] >>> 00:0b.0 Ethernet controller: Intel Corporation 82541PI Gigabit >>> Ethernet Controller (rev 05) >>> 00:0c.0 Ethernet controller: Intel Corporation 82541PI Gigabit >>> Ethernet Controller (rev 05) >>> 00:0d.0 Ethernet controller: Intel Corporation 82541PI Gigabit >>> Ethernet Controller (rev 05) >>> 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID >>> Controller (rev 80) >>> 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/ >>> A/ >>> B/ >>> VT823x/A/C PIPC Bus Master IDE (rev 06) >>> 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB >>> 1.1 >>> Controller (rev 81) >>> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB >>> 1.1 >>> Controller (rev 81) >>> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB >>> 1.1 >>> Controller (rev 81) >>> 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB >>> 1.1 >>> Controller (rev 81) >>> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) >>> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/ >>> K8T800/K8T890 South] >>> 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/ >>> A/ >>> 8235/8237 AC97 Audio Controller (rev 60) >>> 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem >>> Controller (rev 80) >>> 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine- >>> II] >>> (rev 78) >>> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ >>> Opteron] HyperTransport Technology Configuration >>> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ >>> Opteron] Address Map >>> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ >>> Opteron] DRAM Controller >>> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/ >>> Opteron] Miscellaneous Control >>> 01:00.0 VGA compatible controller: VIA Technologies, Inc. K8M800/ >>> K8N800/K8N800A [S3 UniChrome Pro] (rev 01) >>> >>> >>> >>> lsmod shows : >>> >>> Module Size Used by >>> e1000 153668 0 >>> ipt_LOG 8836 0 >>> sit 12804 0 >>> tunnel4 6792 1 sit >>> dca 9124 0 >>> xt_multiport 6784 119 >>> act_nat 8004 0 >>> nf_nat_tftp 5504 0 >>> nf_nat_proto_sctp 5892 0 >>> libcrc32c 6400 1 nf_nat_proto_sctp >>> nf_nat_pptp 6656 0 >>> nf_nat_proto_gre 6020 1 nf_nat_pptp >>> nf_nat_proto_udplite 5892 0 >>> nf_nat_proto_dccp 5892 0 >>> nf_nat_h323 9472 0 >>> nf_nat_sip 9600 0 >>> nf_nat_snmp_basic 11656 0 >>> nf_nat_amanda 5760 0 >>> nf_nat_irc 6016 0 >>> nf_nat_ftp 6400 0 >>> ebt_snat 5760 0 >>> ebtable_nat 5888 0 >>> ebt_dnat 5632 0 >>> ebtables 19200 3 ebt_snat,ebtable_nat,ebt_dnat >>> nf_conntrack_ipv6 15864 0 >>> nf_conntrack_netlink 17792 0 >>> nfnetlink 7320 1 nf_conntrack_netlink >>> ts_kmp 6016 5 >>> nf_conntrack_amanda 7552 1 nf_nat_amanda >>> nf_conntrack_tftp 7956 1 nf_nat_tftp >>> nf_conntrack_ftp 10660 1 nf_nat_ftp >>> nf_conntrack_sane 8220 0 >>> nf_conntrack_irc 8868 1 nf_nat_irc >>> nf_conntrack_netbios_ns 6272 0 >>> nf_conntrack_sip 18708 1 nf_nat_sip >>> nf_conntrack_pptp 9092 1 nf_nat_pptp >>> nf_conntrack_proto_gre 8064 1 nf_conntrack_pptp >>> nf_conntrack_proto_dccp 9992 0 >>> nf_conntrack_proto_sctp 10248 0 >>> nf_conntrack_h323 46336 1 nf_nat_h323 >>> nf_conntrack_proto_udplite 7560 0 >>> ipt_MASQUERADE 6528 0 >>> iptable_nat 8712 1 >>> nf_nat 17944 14 >>> nf_nat_tftp >>> ,nf_nat_proto_sctp >>> ,nf_nat_pptp >>> ,nf_nat_proto_gre >>> ,nf_nat_proto_udplite >>> ,nf_nat_proto_dccp >>> ,nf_nat_h323 >>> ,nf_nat_sip >>> ,nf_nat_amanda >>> ,nf_nat_irc >>> ,nf_nat_ftp,nf_conntrack_netlink,ipt_MASQUERADE,iptable_nat >>> bridge 43668 0 >>> stp 6148 1 bridge >>> bnep 14848 2 >>> sco 12932 2 >>> l2cap 21504 3 bnep >>> bluetooth 48608 5 bnep,sco,l2cap >>> sunrpc 156052 3 >>> ipv6 230132 20 sit,nf_conntrack_ipv6 >>> dm_multipath 17164 0 >>> uinput 10624 0 >>> snd_via82xx 25752 0 >>> snd_via82xx_modem 14472 0 >>> gameport 13452 1 snd_via82xx >>> snd_ac97_codec 95268 2 snd_via82xx,snd_via82xx_modem >>> ac97_bus 5504 1 snd_ac97_codec >>> snd_seq_dummy 6660 0 >>> snd_seq_oss 30364 0 >>> snd_seq_midi_event 9600 1 snd_seq_oss >>> snd_seq 48576 5 >>> snd_seq_dummy,snd_seq_oss,snd_seq_midi_event >>> snd_pcm_oss 42496 0 >>> snd_mixer_oss 16896 1 snd_pcm_oss >>> snd_pcm 65924 4 >>> snd_via82xx,snd_via82xx_modem,snd_ac97_codec,snd_pcm_oss >>> snd_timer 22024 2 snd_seq,snd_pcm >>> snd_page_alloc 11016 3 >>> snd_via82xx,snd_via82xx_modem,snd_pcm >>> snd_mpu401_uart 10368 1 snd_via82xx >>> snd_rawmidi 22528 1 snd_mpu401_uart >>> snd_seq_device 10124 4 >>> snd_seq_dummy,snd_seq_oss,snd_seq,snd_rawmidi >>> snd 50616 13 >>> snd_via82xx >>> ,snd_via82xx_modem >>> ,snd_ac97_codec >>> ,snd_seq_dummy >>> ,snd_seq_oss >>> ,snd_seq >>> ,snd_pcm_oss >>> ,snd_mixer_oss >>> ,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device >>> soundcore 9416 1 snd >>> i2c_viapro 10772 0 >>> sata_via 10884 0 >>> via_rhine 23560 0 >>> mii 8192 1 via_rhine >>> k8temp 7936 0 >>> hwmon 6300 1 k8temp >>> i2c_core 21396 1 i2c_viapro >>> pcspkr 6272 0 >>> floppy 51988 0 >>> ata_generic 8452 0 >>> pata_acpi 7680 0 >>> pata_via 11908 2 >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in >>> SF, CA >>> is the only developer event you need to attend this year. Jumpstart >>> your >>> developing skills, take BlackBerry mobile applications to market and >>> stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> E1000-devel mailing list >>> E1000-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/e1000-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
