* Re: [NETFILTER]: Introduce nf_inet_address
From: David Woodhouse @ 2008-02-22 7:52 UTC (permalink / raw)
To: Patrick McHardy
Cc: netdev, Jan Engelhardt, David S. Miller, varekova, twoerner
In-Reply-To: <47BAEB6C.1030609@trash.net>
On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
> That would break iptables compilation, which already includes
> linux/in.h in some files. I guess the best fix for now is to
> include netinet/in.h in busybox and long-term clean this up
> properly.
It looks like iptables is fairly broken anyway:
make[1]: Entering directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
Extensions found:
make[1]: Leaving directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
error: Bad exit status from /var/tmp/rpm-tmp.32057 (%build)
--
dwmw2
^ permalink raw reply
* [PATCH] Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver
From: Satoru Takeuchi @ 2008-02-22 7:10 UTC (permalink / raw)
To: ebs, linuxppc-dev, netdev
Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
---
Index: 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig
===================================================================
--- 2.6.25-rc2.orig/drivers/net/ibm_newemac/Kconfig 2008-02-22 15:13:35.000000000 +0900
+++ 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig 2008-02-22 15:13:54.000000000 +0900
@@ -43,7 +43,7 @@ config IBM_NEW_EMAC_DEBUG
depends on IBM_NEW_EMAC
default n
-# The options below has to be select'ed by the respective
+# The options below has to be selected by the respective
# processor types or platforms
config IBM_NEW_EMAC_ZMII
^ permalink raw reply
* Re: [Bugme-new] [Bug 10061] New: Hang in md5_resync
From: Steinar H. Gunderson @ 2008-02-22 1:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: bugme-daemon, netdev
In-Reply-To: <20080221170737.94ad17cb.akpm@linux-foundation.org>
On Thu, Feb 21, 2008 at 05:07:37PM -0800, Andrew Morton wrote:
> It would be good if you could test the latest Linux snapshot please, see if
> we've already fixed this, thanks.
This is slightly difficult; it's a production machine.
I _might_ be able to do it tomorrow, but no guarantees.
/* Steinar */
--
Homepage: http://www.sesse.net/
^ permalink raw reply
* Re: [Bugme-new] [Bug 10061] New: Hang in md5_resync
From: Andrew Morton @ 2008-02-22 1:07 UTC (permalink / raw)
To: sgunderson; +Cc: bugme-daemon, netdev
In-Reply-To: <bug-10061-10286@http.bugzilla.kernel.org/>
(please respond via emailed reply-to-all, not via the bugzilla web
interface, thanks)
On Thu, 21 Feb 2008 13:13:13 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=10061
>
> Summary: Hang in md5_resync
> Product: IO/Storage
> Version: 2.5
> KernelVersion: 2.6.25-rc2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: MD
> AssignedTo: io_md@kernel-bugs.osdl.org
> ReportedBy: sgunderson@bigfoot.com
>
>
> Latest working kernel version: 2.6.23
> Earliest failing kernel version: 2.6.25-rc2
> Distribution: Debian unstable
> Hardware Environment: sata_nv, ext3, Seagate SATA disks
> Software Environment: N/A
> Problem Description: After upgrading to 2.6.25, I did some light I/O (basically
> a tab-complete in my home directory), and the whole machine promptly hung.
> After a while, the serial console spat out:
>
> [ 548.684064] BUG: soft lockup - CPU#1 stuck for]
> [ 548.684065] CPU 1:
> [ 548.684065] Modules linked in: tun eeprom ide_generic ide_disk ide_cd_mod
> cdx
> [ 548.684065] Pid: 3599, comm: md4_resync Not tainted 2.6.25-rc2 #1
> [ 548.684065] RIP: 0010:[<ffffffff802fee07>] [<ffffffff802fee07>]
> __write_loc0
> [ 548.684065] RSP: 0018:ffff81011fcffc18 EFLAGS: 00000287
> [ 548.684065] RAX: ffff81011c14dfd8 RBX: ffff8100d42d30c0 RCX:
> ffff8100d42d30c0
> [ 548.684065] RDX: 0000000000000000 RSI: ffff8100d4cd0d90 RDI:
> ffff8100d4cd0d00
> [ 548.684065] RBP: ffff81011fcffb90 R08: 00000000fe538a93 R09:
> 0000000000000000
> [ 548.684065] R10: 00000000000000c0 R11: ffffffff803ad3e1 R12:
> ffffffff8020bcb6
> [ 548.684065] R13: ffff81011fcffb90 R14: ffff8100d4cd0d00 R15:
> 0000000000000000
> [ 548.684065] FS: 00007f8748e0c6e0(0000) GS:ffff81011fcb5dc0(0000)
> knlGS:00000
> [ 548.684065] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 548.684066] CR2: 00007f8748e076f3 CR3: 00000000d296b000 CR4:
> 00000000000006e0
> [ 548.684066] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 548.684066] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 548.684066]
> [ 548.684066] Call Trace:
> [ 548.684066] <IRQ> [<ffffffff80446fe4>] ? _write_lock_bh+0x1a/0x1c
> [ 548.684066] [<ffffffff803ad49e>] ? neigh_resolve_output+0xbd/0x281
> [ 548.684066] [<ffffffff80407ab5>] ? ip6_output+0xc5c/0xc71
> [ 548.684066] [<ffffffff8039d414>] ? sock_alloc_send_skb+0x93/0x1e1
> [ 548.684066] [<ffffffff8041685b>] ? __ndisc_send+0x3c6/0x4fb
> [ 548.684066] [<ffffffff880a431a>] ? :sd_mod:sd_prep_fn+0x74/0x6fb
> [ 548.684066] [<ffffffff8041725b>] ? ndisc_send_ns+0x71/0x7e
> [ 548.684066] [<ffffffff80363c3c>] ? scsi_request_fn+0x339/0x3a5
> [ 548.684066] [<ffffffff804181df>] ? ndisc_solicit+0x159/0x166
> [ 548.684066] [<ffffffff80235673>] ? __mod_timer+0xb0/0xbf
> [ 548.684066] [<ffffffff803adc72>] ? neigh_timer_handler+0x292/0x2d0
> [ 548.684066] [<ffffffff803ad9e0>] ? neigh_timer_handler+0x0/0x2d0
> [ 548.684066] [<ffffffff8023521b>] ? run_timer_softirq+0x151/0x1bf
> [ 548.684066] [<ffffffff80231f40>] ? __do_softirq+0x65/0xcf
> [ 548.684066] [<ffffffff8020c20c>] ? call_softirq+0x1c/0x28
> [ 548.684066] [<ffffffff8020d8b4>] ? do_softirq+0x2c/0x68
> [ 548.684066] [<ffffffff8021919d>] ? smp_apic_timer_interrupt+0x8a/0xa5
> [ 548.684066] [<ffffffff8020bcb6>] ? apic_timer_interrupt+0x66/0x70
> [ 548.684066] <EOI> [<ffffffff880d549c>] ?
> :raid456:raid5_compute_sector+0x19
> [ 548.684066] [<ffffffff880d5511>] ? :raid456:stripe_to_pdidx+0x48/0x51
> [ 548.684066] [<ffffffff880db728>] ? :raid456:sync_request+0x7d3/0x8a1
> [ 548.684066] [<ffffffff802edf17>] ? generic_unplug_device+0x18/0x24
> [ 548.684066] [<ffffffff802ecdef>] ? blk_unplug+0x5a/0x60
> [ 548.684066] [<ffffffff880d51af>] ? :raid456:unplug_slaves+0x55/0x91
> [ 548.684066] [<ffffffff880b0884>] ? :md_mod:md_do_sync+0x54e/0x96c
> [ 548.684066] [<ffffffff802429a7>] ? getnstimeofday+0x2f/0x83
> [ 548.684066] [<ffffffff802263e0>] ? try_to_wake_up+0xfd/0x10e
> [ 548.684066] [<ffffffff880b2ff6>] ? :md_mod:md_thread+0xde/0xfa
> [ 548.684066] [<ffffffff880b2f18>] ? :md_mod:md_thread+0x0/0xfa
> [ 548.684066] [<ffffffff8023e741>] ? kthread+0x47/0x76
> [ 548.684066] [<ffffffff80228ebd>] ? schedule_tail+0x28/0x5c
> [ 548.684066] [<ffffffff8020be98>] ? child_rip+0xa/0x12
> [ 548.684066] [<ffffffff8023e6fa>] ? kthread+0x0/0x76
> [ 548.684066] [<ffffffff8020be8e>] ? child_rip+0x0/0x12
> [ 548.684066]
>
> and the machine continued hanging.
>
> Downgraded to 2.6.23 again, seems to work fine. Will try 2.6.24.2 shortly.
This looks like a networking regression, not a RAID regression.
We did have a big locking bug in netlink in 2.6.25-rc2, although your trace
doesn't appear to point at that particular bug.
It would be good if you could test the latest Linux snapshot please, see if
we've already fixed this, thanks.
^ permalink raw reply
* Re: 2.6.25-rc2-mm1 - several bugs and a crash
From: Tilman Schmidt @ 2008-02-22 0:52 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, linux-kernel, netdev, netfilter-devel
In-Reply-To: <47BE1A03.30300@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
Am 22.02.2008 01:40 schrieb Tilman Schmidt:
>>
>> [NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code warning
>
> Yes, it does; and the system also survives substantially longer.
> (IOW, it hasn't crashed on me so far.)
Which of course it did the second after I sent off that mail. :-(
No message at all this time at the time of the crash, even though
I had "tail -f /var/log/messages" running in an ssh session.
So the nf_conntrack BUG is fixed, but the crash (and of course the
swapper "spinlock bad magic" BUG) persists.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply
* Re: 2.6.25-rc2-mm1 - several bugs and a crash
From: Tilman Schmidt @ 2008-02-22 0:40 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, linux-kernel, netdev, netfilter-devel
In-Reply-To: <47BD6072.4000407@trash.net>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
Am 21.02.2008 12:28 schrieb Patrick McHardy:
>
> Could you test whether this patch fixes the netfilter
> warnings please?
> commit 736b33102292be0d75be1e950ca9bcd5361db7dd
> Author: Patrick McHardy <kaber@trash.net>
> Date: Thu Feb 21 12:26:01 2008 +0100
>
> [NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code warning
Yes, it does; and the system also survives substantially longer.
(IOW, it hasn't crashed on me so far.)
Thanks,
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply
* [PATCH] [SSB] Add CHIPCO IRQ access functions
From: Aurelien Jarno @ 2008-02-21 23:17 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev
This patch adds functions to setup and read the CHIPCO IRQ.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
---
drivers/ssb/driver_chipcommon.c | 10 ++++++++++
include/linux/ssb/ssb_driver_chipcommon.h | 4 ++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index e586321..45b672a 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -353,6 +353,16 @@ void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon *cc, u32 ticks)
chipco_write32(cc, SSB_CHIPCO_WATCHDOG, ticks);
}
+void ssb_chipco_irq_mask(struct ssb_chipcommon *cc, u32 mask, u32 value)
+{
+ chipco_write32_masked(cc, SSB_CHIPCO_IRQMASK, mask, value);
+}
+
+u32 ssb_chipco_irq_status(struct ssb_chipcommon *cc, u32 mask)
+{
+ return chipco_read32(cc, SSB_CHIPCO_IRQSTAT) & mask;
+}
+
u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask)
{
return chipco_read32(cc, SSB_CHIPCO_GPIOIN) & mask;
diff --git a/include/linux/ssb/ssb_driver_chipcommon.h b/include/linux/ssb/ssb_driver_chipcommon.h
index 536851b..b548a54 100644
--- a/include/linux/ssb/ssb_driver_chipcommon.h
+++ b/include/linux/ssb/ssb_driver_chipcommon.h
@@ -390,6 +390,10 @@ extern void ssb_chipco_set_clockmode(struct ssb_chipcommon *cc,
extern void ssb_chipco_watchdog_timer_set(struct ssb_chipcommon *cc,
u32 ticks);
+void ssb_chipco_irq_mask(struct ssb_chipcommon *cc, u32 mask, u32 value);
+
+u32 ssb_chipco_irq_status(struct ssb_chipcommon *cc, u32 mask);
+
/* Chipcommon GPIO pin access. */
u32 ssb_chipco_gpio_in(struct ssb_chipcommon *cc, u32 mask);
u32 ssb_chipco_gpio_out(struct ssb_chipcommon *cc, u32 mask, u32 value);
--
1.5.4.1
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply related
* Re: [PATCH] The kernel gets no IP from some DHCP servers, 2.6.24
From: Frans Pop @ 2008-02-21 23:41 UTC (permalink / raw)
To: Wappler Marcel; +Cc: linux-kernel, netdev
In-Reply-To: <83116F0A4FF67A4F97BA0B6E408C48E301C5C723@zuerich.BC-Int.NET>
Adding netdev list.
Original patch can be found at: http://lkml.org/lkml/2008/2/21/171
Wappler Marcel wrote:
> This patch fixes a DHCP issue of the kernel: some DHCP servers
> (i.e. in the Linksys WRT54Gv5) are very strict about the contents
> of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131
> page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'.
> These DHCP servers ignore Linux kernel's DHCP discovery packets with these
> two fields set to '255.255.255.255' (in contrast to popular DHCP clients,
> such as 'dhclient' or 'udhcpc'). This leads to a not booting system.
> I tested this on a ARM embedded device mounting rootfs over NFS obtaining
> its IP from a Linksys WRT54Gv5 Router running VxWorks and a PC based
> Server running a Linux. Changing the two fields to '0.0.0.0' worked.
>
> Please CC me personaly when answering this message.
>
> Thanks,
> Marcel
>
> --- linux-2.6.24.2/net/ipv4/ipconfig.c 2008-02-21 15:27:47.250890963 +0100
> +++ linux/net/ipv4/ipconfig.c 2008-02-21 15:36:12.686735925 +0100
> @@ -29,6 +29,10 @@
> *
> * Multiple Nameservers in /proc/net/pnp
> * -- Josef Siemes <jsiemes@web.de>, Aug 2002
> + *
> + * Bugfix: Not getting an IP from some DHCP servers: RFC2131 page 36
> + * Table 5 requests DHCPDISCOVER fields ciaddr and siaddr MUST be '0'.
> + * -- marcel.wappler@bridgeco.net
> */
>
> #include <linux/types.h>
> @@ -103,6 +107,7 @@
> - '3' from resolv.h */
>
> #define NONE __constant_htonl(INADDR_NONE)
> +#define ZERO __constant_htonl(((unsigned long int) 0x00000000))
>
> /*
> * Public IP configuration
> @@ -740,8 +745,8 @@
> b->htype = dev->type; /* can cause undefined behavior */
> }
> b->hlen = dev->addr_len;
> - b->your_ip = NONE;
> - b->server_ip = NONE;
> + b->your_ip = ZERO;
> + b->server_ip = ZERO;
> memcpy(b->hw_addr, dev->dev_addr, dev->addr_len);
> b->secs = htons(jiffies_diff / HZ);
> b->xid = d->xid;
>
> --
> Marcel Wappler
> Bridgeco AG
> CH-8600 Dübendorf
> Switzerland
^ permalink raw reply
* [PATCH 6/7] e1000e: fix spelling errors in comments
From: Auke Kok @ 2008-02-21 23:11 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
In-Reply-To: <20080221231041.5595.4933.stgit@localhost.localdomain>
Fix some spelling errors and inconsistencies in comment blocks.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/82571.c | 10 +++++-----
drivers/net/e1000e/defines.h | 10 +++++-----
drivers/net/e1000e/hw.h | 4 ++--
drivers/net/e1000e/ich8lan.c | 24 ++++++++++++------------
drivers/net/e1000e/lib.c | 16 ++++++++--------
drivers/net/e1000e/netdev.c | 16 +++++++++-------
drivers/net/e1000e/phy.c | 10 +++++-----
7 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/net/e1000e/82571.c b/drivers/net/e1000e/82571.c
index f7ffd35..7fe2031 100644
--- a/drivers/net/e1000e/82571.c
+++ b/drivers/net/e1000e/82571.c
@@ -438,7 +438,7 @@ static void e1000_release_nvm_82571(struct e1000_hw *hw)
* For non-82573 silicon, write data to EEPROM at offset using SPI interface.
*
* If e1000e_update_nvm_checksum is not called after this function, the
- * EEPROM will most likley contain an invalid checksum.
+ * EEPROM will most likely contain an invalid checksum.
**/
static s32 e1000_write_nvm_82571(struct e1000_hw *hw, u16 offset, u16 words,
u16 *data)
@@ -547,7 +547,7 @@ static s32 e1000_validate_nvm_checksum_82571(struct e1000_hw *hw)
* poll for completion.
*
* If e1000e_update_nvm_checksum is not called after this function, the
- * EEPROM will most likley contain an invalid checksum.
+ * EEPROM will most likely contain an invalid checksum.
**/
static s32 e1000_write_nvm_eewr_82571(struct e1000_hw *hw, u16 offset,
u16 words, u16 *data)
@@ -1053,7 +1053,7 @@ static s32 e1000_setup_fiber_serdes_link_82571(struct e1000_hw *hw)
/* If SerDes loopback mode is entered, there is no form
* of reset to take the adapter out of that mode. So we
* have to explicitly take the adapter out of loopback
- * mode. This prevents drivers from twidling their thumbs
+ * mode. This prevents drivers from twiddling their thumbs
* if another tool failed to take it out of loopback mode.
*/
ew32(SCTL,
@@ -1098,7 +1098,7 @@ static s32 e1000_valid_led_default_82571(struct e1000_hw *hw, u16 *data)
* e1000e_get_laa_state_82571 - Get locally administered address state
* @hw: pointer to the HW structure
*
- * Retrieve and return the current locally administed address state.
+ * Retrieve and return the current locally administered address state.
**/
bool e1000e_get_laa_state_82571(struct e1000_hw *hw)
{
@@ -1113,7 +1113,7 @@ bool e1000e_get_laa_state_82571(struct e1000_hw *hw)
* @hw: pointer to the HW structure
* @state: enable/disable locally administered address
*
- * Enable/Disable the current locally administed address state.
+ * Enable/Disable the current locally administers address state.
**/
void e1000e_set_laa_state_82571(struct e1000_hw *hw, bool state)
{
diff --git a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h
index 6232c3e..a4f511f 100644
--- a/drivers/net/e1000e/defines.h
+++ b/drivers/net/e1000e/defines.h
@@ -66,7 +66,7 @@
#define E1000_WUFC_ARP 0x00000020 /* ARP Request Packet Wakeup Enable */
/* Extended Device Control */
-#define E1000_CTRL_EXT_SDP7_DATA 0x00000080 /* Value of SW Defineable Pin 7 */
+#define E1000_CTRL_EXT_SDP7_DATA 0x00000080 /* Value of SW Definable Pin 7 */
#define E1000_CTRL_EXT_EE_RST 0x00002000 /* Reinitialize from EEPROM */
#define E1000_CTRL_EXT_RO_DIS 0x00020000 /* Relaxed Ordering disable */
#define E1000_CTRL_EXT_LINK_MODE_MASK 0x00C00000
@@ -75,12 +75,12 @@
#define E1000_CTRL_EXT_IAME 0x08000000 /* Interrupt acknowledge Auto-mask */
#define E1000_CTRL_EXT_INT_TIMER_CLR 0x20000000 /* Clear Interrupt timers after IMS clear */
-/* Receive Decriptor bit definitions */
+/* Receive Descriptor bit definitions */
#define E1000_RXD_STAT_DD 0x01 /* Descriptor Done */
#define E1000_RXD_STAT_EOP 0x02 /* End of Packet */
#define E1000_RXD_STAT_IXSM 0x04 /* Ignore checksum */
#define E1000_RXD_STAT_VP 0x08 /* IEEE VLAN Packet */
-#define E1000_RXD_STAT_UDPCS 0x10 /* UDP xsum caculated */
+#define E1000_RXD_STAT_UDPCS 0x10 /* UDP xsum calculated */
#define E1000_RXD_STAT_TCPCS 0x20 /* TCP xsum calculated */
#define E1000_RXD_ERR_CE 0x01 /* CRC Error */
#define E1000_RXD_ERR_SE 0x02 /* Symbol Error */
@@ -223,7 +223,7 @@
#define E1000_STATUS_LAN_INIT_DONE 0x00000200 /* Lan Init Completion by NVM */
#define E1000_STATUS_GIO_MASTER_ENABLE 0x00080000 /* Status of Master requests. */
-/* Constants used to intrepret the masked PCI-X bus speed. */
+/* Constants used to interpret the masked PCI-X bus speed. */
#define HALF_DUPLEX 1
#define FULL_DUPLEX 2
@@ -517,7 +517,7 @@
/* PHY 1000 MII Register/Bit Definitions */
/* PHY Registers defined by IEEE */
#define PHY_CONTROL 0x00 /* Control Register */
-#define PHY_STATUS 0x01 /* Status Regiser */
+#define PHY_STATUS 0x01 /* Status Register */
#define PHY_ID1 0x02 /* Phy Id Reg (word 1) */
#define PHY_ID2 0x03 /* Phy Id Reg (word 2) */
#define PHY_AUTONEG_ADV 0x04 /* Autoneg Advertisement */
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index 3c5862f..916025b 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -184,7 +184,7 @@ enum e1e_registers {
E1000_ICRXDMTC = 0x04120, /* Irq Cause Rx Desc MinThreshold Count */
E1000_ICRXOC = 0x04124, /* Irq Cause Receiver Overrun Count */
E1000_RXCSUM = 0x05000, /* RX Checksum Control - RW */
- E1000_RFCTL = 0x05008, /* Receive Filter Control*/
+ E1000_RFCTL = 0x05008, /* Receive Filter Control */
E1000_MTA = 0x05200, /* Multicast Table Array - RW Array */
E1000_RA = 0x05400, /* Receive Address - RW Array */
E1000_VFTA = 0x05600, /* VLAN Filter Table Array - RW Array */
@@ -202,7 +202,7 @@ enum e1e_registers {
E1000_FACTPS = 0x05B30, /* Function Active and Power State to MNG */
E1000_SWSM = 0x05B50, /* SW Semaphore */
E1000_FWSM = 0x05B54, /* FW Semaphore */
- E1000_HICR = 0x08F00, /* Host Inteface Control */
+ E1000_HICR = 0x08F00, /* Host Interface Control */
};
/* RSS registers */
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 8f8139d..0ae3955 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -671,7 +671,7 @@ static s32 e1000_get_phy_info_ich8lan(struct e1000_hw *hw)
* e1000_check_polarity_ife_ich8lan - Check cable polarity for IFE PHY
* @hw: pointer to the HW structure
*
- * Polarity is determined on the polarity reveral feature being enabled.
+ * Polarity is determined on the polarity reversal feature being enabled.
* This function is only called by other family-specific
* routines.
**/
@@ -947,7 +947,7 @@ static s32 e1000_flash_cycle_init_ich8lan(struct e1000_hw *hw)
/* Either we should have a hardware SPI cycle in progress
* bit to check against, in order to start a new cycle or
* FDONE bit should be changed in the hardware so that it
- * is 1 after harware reset, which can then be used as an
+ * is 1 after hardware reset, which can then be used as an
* indication whether a cycle is in progress or has been
* completed.
*/
@@ -1155,7 +1155,7 @@ static s32 e1000_write_nvm_ich8lan(struct e1000_hw *hw, u16 offset, u16 words,
* which writes the checksum to the shadow ram. The changes in the shadow
* ram are then committed to the EEPROM by processing each bank at a time
* checking for the modified bit and writing only the pending changes.
- * After a succesful commit, the shadow ram is cleared and is ready for
+ * After a successful commit, the shadow ram is cleared and is ready for
* future writes.
**/
static s32 e1000_update_nvm_checksum_ich8lan(struct e1000_hw *hw)
@@ -1680,7 +1680,7 @@ static s32 e1000_reset_hw_ich8lan(struct e1000_hw *hw)
* - initialize LED identification
* - setup receive address registers
* - setup flow control
- * - setup transmit discriptors
+ * - setup transmit descriptors
* - clear statistics
**/
static s32 e1000_init_hw_ich8lan(struct e1000_hw *hw)
@@ -1961,7 +1961,7 @@ static s32 e1000_kmrn_lock_loss_workaround_ich8lan(struct e1000_hw *hw)
E1000_PHY_CTRL_NOND0A_GBE_DISABLE);
ew32(PHY_CTRL, phy_ctrl);
- /* Call gig speed drop workaround on Giga disable before accessing
+ /* Call gig speed drop workaround on Gig disable before accessing
* any PHY registers */
e1000e_gig_downshift_workaround_ich8lan(hw);
@@ -1972,7 +1972,7 @@ static s32 e1000_kmrn_lock_loss_workaround_ich8lan(struct e1000_hw *hw)
/**
* e1000_set_kmrn_lock_loss_workaound_ich8lan - Set Kumeran workaround state
* @hw: pointer to the HW structure
- * @state: boolean value used to set the current Kumaran workaround state
+ * @state: boolean value used to set the current Kumeran workaround state
*
* If ICH8, set the current Kumeran workaround state (enabled - TRUE
* /disabled - FALSE).
@@ -2017,7 +2017,7 @@ void e1000e_igp3_phy_powerdown_workaround_ich8lan(struct e1000_hw *hw)
E1000_PHY_CTRL_NOND0A_GBE_DISABLE);
ew32(PHY_CTRL, reg);
- /* Call gig speed drop workaround on Giga disable before
+ /* Call gig speed drop workaround on Gig disable before
* accessing any PHY registers */
if (hw->mac.type == e1000_ich8lan)
e1000e_gig_downshift_workaround_ich8lan(hw);
@@ -2045,7 +2045,7 @@ void e1000e_igp3_phy_powerdown_workaround_ich8lan(struct e1000_hw *hw)
* @hw: pointer to the HW structure
*
* Steps to take when dropping from 1Gb/s (eg. link cable removal (LSC),
- * LPLU, Giga disable, MDIC PHY reset):
+ * LPLU, Gig disable, MDIC PHY reset):
* 1) Set Kumeran Near-end loopback
* 2) Clear Kumeran Near-end loopback
* Should only be called for ICH8[m] devices with IGP_3 Phy.
@@ -2089,10 +2089,10 @@ static s32 e1000_cleanup_led_ich8lan(struct e1000_hw *hw)
}
/**
- * e1000_led_on_ich8lan - Turn LED's on
+ * e1000_led_on_ich8lan - Turn LEDs on
* @hw: pointer to the HW structure
*
- * Turn on the LED's.
+ * Turn on the LEDs.
**/
static s32 e1000_led_on_ich8lan(struct e1000_hw *hw)
{
@@ -2105,10 +2105,10 @@ static s32 e1000_led_on_ich8lan(struct e1000_hw *hw)
}
/**
- * e1000_led_off_ich8lan - Turn LED's off
+ * e1000_led_off_ich8lan - Turn LEDs off
* @hw: pointer to the HW structure
*
- * Turn off the LED's.
+ * Turn off the LEDs.
**/
static s32 e1000_led_off_ich8lan(struct e1000_hw *hw)
{
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index 341d74e..95f75a4 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -1140,7 +1140,7 @@ s32 e1000e_config_fc_after_link_up(struct e1000_hw *hw)
}
/**
- * e1000e_get_speed_and_duplex_copper - Retreive current speed/duplex
+ * e1000e_get_speed_and_duplex_copper - Retrieve current speed/duplex
* @hw: pointer to the HW structure
* @speed: stores the current speed
* @duplex: stores the current duplex
@@ -1176,7 +1176,7 @@ s32 e1000e_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed, u16 *dup
}
/**
- * e1000e_get_speed_and_duplex_fiber_serdes - Retreive current speed/duplex
+ * e1000e_get_speed_and_duplex_fiber_serdes - Retrieve current speed/duplex
* @hw: pointer to the HW structure
* @speed: stores the current speed
* @duplex: stores the current duplex
@@ -1386,7 +1386,7 @@ s32 e1000e_cleanup_led_generic(struct e1000_hw *hw)
* e1000e_blink_led - Blink LED
* @hw: pointer to the HW structure
*
- * Blink the led's which are set to be on.
+ * Blink the LEDs which are set to be on.
**/
s32 e1000e_blink_led(struct e1000_hw *hw)
{
@@ -1491,7 +1491,7 @@ void e1000e_set_pcie_no_snoop(struct e1000_hw *hw, u32 no_snoop)
* @hw: pointer to the HW structure
*
* Returns 0 if successful, else returns -10
- * (-E1000_ERR_MASTER_REQUESTS_PENDING) if master disable bit has not casued
+ * (-E1000_ERR_MASTER_REQUESTS_PENDING) if master disable bit has not caused
* the master requests to be disabled.
*
* Disables PCI-Express master access and verifies there are no pending
@@ -1852,7 +1852,7 @@ static s32 e1000_ready_nvm_eeprom(struct e1000_hw *hw)
}
/**
- * e1000e_read_nvm_spi - Read EEPROM's using SPI
+ * e1000e_read_nvm_spi - Reads EEPROM using SPI
* @hw: pointer to the HW structure
* @offset: offset of word in the EEPROM to read
* @words: number of words to read
@@ -1956,7 +1956,7 @@ s32 e1000e_read_nvm_eerd(struct e1000_hw *hw, u16 offset, u16 words, u16 *data)
* Writes data to EEPROM at offset using SPI interface.
*
* If e1000e_update_nvm_checksum is not called after this function , the
- * EEPROM will most likley contain an invalid checksum.
+ * EEPROM will most likely contain an invalid checksum.
**/
s32 e1000e_write_nvm_spi(struct e1000_hw *hw, u16 offset, u16 words, u16 *data)
{
@@ -2198,7 +2198,7 @@ static u8 e1000_calculate_checksum(u8 *buffer, u32 length)
*
* Returns E1000_success upon success, else E1000_ERR_HOST_INTERFACE_COMMAND
*
- * This function checks whether the HOST IF is enabled for command operaton
+ * This function checks whether the HOST IF is enabled for command operation
* and also checks whether the previous command is completed. It busy waits
* in case of previous command is not completed.
**/
@@ -2230,7 +2230,7 @@ static s32 e1000_mng_enable_host_if(struct e1000_hw *hw)
}
/**
- * e1000e_check_mng_mode - check managament mode
+ * e1000e_check_mng_mode - check management mode
* @hw: pointer to the HW structure
*
* Reads the firmware semaphore register and returns true (>0) if
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 3031d6d..7824bc2 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1006,7 +1006,7 @@ static void e1000_irq_enable(struct e1000_adapter *adapter)
* e1000_get_hw_control - get control of the h/w from f/w
* @adapter: address of board private structure
*
- * e1000_get_hw_control sets {CTRL_EXT|FWSM}:DRV_LOAD bit.
+ * e1000_get_hw_control sets {CTRL_EXT|SWSM}:DRV_LOAD bit.
* For ASF and Pass Through versions of f/w this means that
* the driver is loaded. For AMT version (only with 82573)
* of the f/w this means that the network i/f is open.
@@ -1032,7 +1032,7 @@ static void e1000_get_hw_control(struct e1000_adapter *adapter)
* e1000_release_hw_control - release control of the h/w to f/w
* @adapter: address of board private structure
*
- * e1000_release_hw_control resets {CTRL_EXT|FWSM}:DRV_LOAD bit.
+ * e1000_release_hw_control resets {CTRL_EXT|SWSM}:DRV_LOAD bit.
* For ASF and Pass Through versions of f/w this means that the
* driver is no longer loaded. For AMT version (only with 82573) i
* of the f/w this means that the network i/f is closed.
@@ -1241,6 +1241,11 @@ void e1000e_free_rx_resources(struct e1000_adapter *adapter)
/**
* e1000_update_itr - update the dynamic ITR value based on statistics
+ * @adapter: pointer to adapter
+ * @itr_setting: current adapter->itr
+ * @packets: the number of packets during this measurement interval
+ * @bytes: the number of bytes during this measurement interval
+ *
* Stores a new ITR value based on packets and byte
* counts during the last interrupt. The advantage of per interrupt
* computation is faster updates and more accurate ITR for the current
@@ -1250,10 +1255,6 @@ void e1000e_free_rx_resources(struct e1000_adapter *adapter)
* while increasing bulk throughput.
* this functionality is controlled by the InterruptThrottleRate module
* parameter (see e1000_param.c)
- * @adapter: pointer to adapter
- * @itr_setting: current adapter->itr
- * @packets: the number of packets during this measurement interval
- * @bytes: the number of bytes during this measurement interval
**/
static unsigned int e1000_update_itr(struct e1000_adapter *adapter,
u16 itr_setting, int packets,
@@ -1366,6 +1367,7 @@ set_itr_now:
/**
* e1000_clean - NAPI Rx polling callback
* @adapter: board private structure
+ * @budget: amount of packets driver is allowed to process this poll
**/
static int e1000_clean(struct napi_struct *napi, int budget)
{
@@ -2000,7 +2002,7 @@ static void e1000_power_down_phy(struct e1000_adapter *adapter)
e1000_check_reset_block(hw))
return;
- /* managebility (AMT) is enabled */
+ /* manageability (AMT) is enabled */
if (er32(MANC) & E1000_MANC_SMBUS_EN)
return;
diff --git a/drivers/net/e1000e/phy.c b/drivers/net/e1000e/phy.c
index fc6fee1..dab3c46 100644
--- a/drivers/net/e1000e/phy.c
+++ b/drivers/net/e1000e/phy.c
@@ -121,7 +121,7 @@ s32 e1000e_phy_reset_dsp(struct e1000_hw *hw)
* @offset: register offset to be read
* @data: pointer to the read data
*
- * Reads the MDI control regsiter in the PHY at offset and stores the
+ * Reads the MDI control register in the PHY at offset and stores the
* information read to data.
**/
static s32 e1000_read_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 *data)
@@ -1172,7 +1172,7 @@ s32 e1000e_set_d3_lplu_state(struct e1000_hw *hw, bool active)
}
/**
- * e1000e_check_downshift - Checks whether a downshift in speed occured
+ * e1000e_check_downshift - Checks whether a downshift in speed occurred
* @hw: pointer to the HW structure
*
* Success returns 0, Failure returns 1
@@ -1388,8 +1388,8 @@ s32 e1000e_get_cable_length_m88(struct e1000_hw *hw)
*
* The automatic gain control (agc) normalizes the amplitude of the
* received signal, adjusting for the attenuation produced by the
- * cable. By reading the AGC registers, which reperesent the
- * cobination of course and fine gain value, the value can be put
+ * cable. By reading the AGC registers, which represent the
+ * combination of course and fine gain value, the value can be put
* into a lookup table to obtain the approximate cable length
* for each channel.
**/
@@ -1619,7 +1619,7 @@ s32 e1000e_phy_sw_reset(struct e1000_hw *hw)
* Verify the reset block is not blocking us from resetting. Acquire
* semaphore (if necessary) and read/set/write the device control reset
* bit in the PHY. Wait the appropriate delay time for the device to
- * reset and relase the semaphore (if necessary).
+ * reset and release the semaphore (if necessary).
**/
s32 e1000e_phy_hw_reset_generic(struct e1000_hw *hw)
{
^ permalink raw reply related
* [PATCH 2/7] e1000e: 82573 can use eerd method to read eeprom
From: Auke Kok @ 2008-02-21 23:10 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
In-Reply-To: <20080221231041.5595.4933.stgit@localhost.localdomain>
This simplifies the 82571/2/3 family initialization a bit
and removes an initialization table no longer needed.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/82571.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/e1000e/82571.c b/drivers/net/e1000e/82571.c
index 3beace5..f7ffd35 100644
--- a/drivers/net/e1000e/82571.c
+++ b/drivers/net/e1000e/82571.c
@@ -1281,16 +1281,6 @@ static struct e1000_phy_operations e82_phy_ops_m88 = {
static struct e1000_nvm_operations e82571_nvm_ops = {
.acquire_nvm = e1000_acquire_nvm_82571,
- .read_nvm = e1000e_read_nvm_spi,
- .release_nvm = e1000_release_nvm_82571,
- .update_nvm = e1000_update_nvm_checksum_82571,
- .valid_led_default = e1000_valid_led_default_82571,
- .validate_nvm = e1000_validate_nvm_checksum_82571,
- .write_nvm = e1000_write_nvm_82571,
-};
-
-static struct e1000_nvm_operations e82573_nvm_ops = {
- .acquire_nvm = e1000_acquire_nvm_82571,
.read_nvm = e1000e_read_nvm_eerd,
.release_nvm = e1000_release_nvm_82571,
.update_nvm = e1000_update_nvm_checksum_82571,
@@ -1355,6 +1345,6 @@ struct e1000_info e1000_82573_info = {
.get_invariants = e1000_get_invariants_82571,
.mac_ops = &e82571_mac_ops,
.phy_ops = &e82_phy_ops_m88,
- .nvm_ops = &e82573_nvm_ops,
+ .nvm_ops = &e82571_nvm_ops,
};
^ permalink raw reply related
* [PATCH 1/7] ixgb: add RNBC counter - no buffer count - to ethtool stats
From: Auke Kok @ 2008-02-21 23:10 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
This counter is valuable to determine if the system is unable
to timely return buffers to the hardware and this counter starts
to increase well before the hardware starts to drop packets. If
users experience rx_no_buffer_count increasing, they should increase
the amount of descriptors. That will provide more buffers for the
hardware and will decrease the chance of hard drops.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/ixgb/ixgb_ethtool.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index 53a9fd0..75f3a68 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -67,6 +67,7 @@ static struct ixgb_stats ixgb_gstrings_stats[] = {
{"rx_over_errors", IXGB_STAT(net_stats.rx_over_errors)},
{"rx_crc_errors", IXGB_STAT(net_stats.rx_crc_errors)},
{"rx_frame_errors", IXGB_STAT(net_stats.rx_frame_errors)},
+ {"rx_no_buffer_count", IXGB_STAT(stats.rnbc)},
{"rx_fifo_errors", IXGB_STAT(net_stats.rx_fifo_errors)},
{"rx_missed_errors", IXGB_STAT(net_stats.rx_missed_errors)},
{"tx_aborted_errors", IXGB_STAT(net_stats.tx_aborted_errors)},
^ permalink raw reply related
* Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
From: Eric Dumazet @ 2008-02-21 23:19 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: David S. Miller, netdev
In-Reply-To: <47BDDBB5.1050603@fr.ibm.com>
Daniel Lezcano a écrit :
> Eric Dumazet wrote:
>> Hi David
>>
>> This is an RFC, based on net-2.6 for convenience only.
>>
>> Thank you
>>
>> [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
>>
>> Loopback transmit function loopback_xmit() actually calls netif_rx()
>> to queue
>> a skb to the softnet queue, and arms a softirq so that this skb can be
>> handled later.
>>
>> This has a cost on SMP, because we need to hold a reference on the
>> device, and free this
>> reference when softirq dequeues packet.
>>
>> Following patch directly calls netif_receive_skb() and avoids lot of
>> atomic operations.
>> (atomic_inc(&dev->refcnt), set_and_set_bit(NAPI_STATE_SCHED,
>> &n->state), ...
>> atomic_dec(&dev->refcnt)...), cache line ping-pongs on device refcnt,
>> but also softirq overhead.
>>
>> This gives a nice boost on tbench for example (5 % on my machine)
>
> I understand this is interesting for the loopback when there is no
> multiple instances of it and it can't be unregistered. But now with the
> network namespaces, we can have multiple instances of the loopback and
> it can to be unregistered. Shouldn't we still use netif_rx ?
> Perhaps we can do something like:
>
> if (dev->nd_net == &init_net)
> netif_receive_skb(skb);
> else
> netif_rx(skb);
or
#ifdef CONFIG_NET_NS
if (dev->nd_net != &init_net)
netif_rx(skb);
else
#endif
netif_receive_skb(skb);
>
> Or we create:
> init_loopback_xmit() calling netif_receive_skb(skb);
> and setup this function when creating the loopback for init_net,
> otherwise we setup the usual loopback_xmit.
>
> We are still safe for multiple network namespaces and we have the
> improvement for init_net loopback.
>
I dont understand how my patch could degrade loopbackdev unregister logic. It
should only help it, by avoiding a queue of 'pending packets' per cpu.
When we want to unregister a network device, stack makes sure that no more
calls to dev->hard_start_xmit() can occur.
If no more loopback_xmit() calls are done on this device, it doesnt matter if
it internally uses netif_rx() or netif_receive_skb(skb)
loopback device has no queue, its really unfortunate to use the 'softirq'
internal queue.
^ permalink raw reply
* [PATCH 7/7] e1000e: remove unused read value in ASPM disable code.
From: Auke Kok @ 2008-02-21 23:11 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
In-Reply-To: <20080221231041.5595.4933.stgit@localhost.localdomain>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/netdev.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 7824bc2..fc5c63f 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3490,7 +3490,6 @@ static int e1000_suspend(struct pci_dev *pdev, pm_message_t state)
static void e1000e_disable_l1aspm(struct pci_dev *pdev)
{
int pos;
- u32 cap;
u16 val;
/*
@@ -3505,7 +3504,6 @@ static void e1000e_disable_l1aspm(struct pci_dev *pdev)
* active.
*/
pos = pci_find_capability(pdev, PCI_CAP_ID_EXP);
- pci_read_config_dword(pdev, pos + PCI_EXP_LNKCAP, &cap);
pci_read_config_word(pdev, pos + PCI_EXP_LNKCTL, &val);
if (val & 0x2) {
dev_warn(&pdev->dev, "Disabling L1 ASPM\n");
^ permalink raw reply related
* [PATCH 4/7] e1000e: fix flow control when using ethtool overrides
From: Auke Kok @ 2008-02-21 23:10 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
In-Reply-To: <20080221231041.5595.4933.stgit@localhost.localdomain>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/lib.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index 16f35fa..0860b5f 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -589,9 +589,6 @@ static s32 e1000_set_default_fc_generic(struct e1000_hw *hw)
s32 ret_val;
u16 nvm_data;
- if (mac->fc != e1000_fc_default)
- return 0;
-
/* Read and store word 0x0F of the EEPROM. This word contains bits
* that determine the hardware's default PAUSE (flow control) mode,
* a bit that determines whether the HW defaults to enabling or
^ permalink raw reply related
* [PATCH 5/7] e1000e: fix flow control denial of service possibility
From: Auke Kok @ 2008-02-21 23:11 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
In-Reply-To: <20080221231041.5595.4933.stgit@localhost.localdomain>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
this patch avoids a denial of service from an evildoer sending a
continuous stream of flow control at our adapter that is plugged
into a non-flow control enabled switch.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/lib.c | 31 +++++--------------------------
1 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
index 0860b5f..341d74e 100644
--- a/drivers/net/e1000e/lib.c
+++ b/drivers/net/e1000e/lib.c
@@ -1104,34 +1104,13 @@ s32 e1000e_config_fc_after_link_up(struct e1000_hw *hw)
(mii_nway_lp_ability_reg & NWAY_LPAR_ASM_DIR)) {
mac->fc = e1000_fc_rx_pause;
hw_dbg(hw, "Flow Control = RX PAUSE frames only.\r\n");
- }
- /* Per the IEEE spec, at this point flow control should be
- * disabled. However, we want to consider that we could
- * be connected to a legacy switch that doesn't advertise
- * desired flow control, but can be forced on the link
- * partner. So if we advertised no flow control, that is
- * what we will resolve to. If we advertised some kind of
- * receive capability (Rx Pause Only or Full Flow Control)
- * and the link partner advertised none, we will configure
- * ourselves to enable Rx Flow Control only. We can do
- * this safely for two reasons: If the link partner really
- * didn't want flow control enabled, and we enable Rx, no
- * harm done since we won't be receiving any PAUSE frames
- * anyway. If the intent on the link partner was to have
- * flow control enabled, then by us enabling RX only, we
- * can at least receive pause frames and process them.
- * This is a good idea because in most cases, since we are
- * predominantly a server NIC, more times than not we will
- * be asked to delay transmission of packets than asking
- * our link partner to pause transmission of frames.
- */
- else if ((mac->original_fc == e1000_fc_none) ||
- (mac->original_fc == e1000_fc_tx_pause)) {
+ } else {
+ /*
+ * Per the IEEE spec, at this point flow control
+ * should be disabled.
+ */
mac->fc = e1000_fc_none;
hw_dbg(hw, "Flow Control = NONE.\r\n");
- } else {
- mac->fc = e1000_fc_rx_pause;
- hw_dbg(hw, "Flow Control = RX PAUSE frames only.\r\n");
}
/* Now we need to do one last check... If we auto-
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply related
* [PATCH 3/7] e1000e: fix link up message to show ethX:
From: Auke Kok @ 2008-02-21 23:10 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev
In-Reply-To: <20080221231041.5595.4933.stgit@localhost.localdomain>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/e1000.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 8b88c22..327c062 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -42,8 +42,7 @@
struct e1000_info;
#define ndev_printk(level, netdev, format, arg...) \
- printk(level "%s: %s: " format, (netdev)->dev.parent->bus_id, \
- (netdev)->name, ## arg)
+ printk(level "%s: " format, (netdev)->name, ## arg)
#ifdef DEBUG
#define ndev_dbg(netdev, format, arg...) \
^ permalink raw reply related
* Re: sungem triggers NAPI warning
From: Benjamin Herrenschmidt @ 2008-02-21 22:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1203599125.4427.0.camel@johannes.berg>
On Thu, 2008-02-21 at 14:05 +0100, Johannes Berg wrote:
> On Thu, 2008-02-21 at 13:54 +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-02-19 at 22:38 +0100, Johannes Berg wrote:
> > > I started getting this warning with recent kernels:
> >
> > Do that help ?
> >
> > In gem_poll(), do:
> >
> > - work_done += gem_rx(gp, budget);
> > + work_done += gem_rx(gp, budget - work_done);
>
> That looks correct, but I haven't been able to trigger the warning again
> even with similar workloads so I haven't tested this change because I
> can't even reproduce without it.
I still think the change is obviously correct, so I'll give a second
close look at the code and produce a patch.
Ben.
^ permalink raw reply
* Re: [PATCH] alloc_percpu() fails to allocate percpu data
From: Peter Zijlstra @ 2008-02-21 22:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Andrew Morton, linux kernel, netdev,
Christoph Lameter, Zhang, Yanmin
In-Reply-To: <47BDBC23.10605@cosmosbay.com>
On Thu, 2008-02-21 at 19:00 +0100, Eric Dumazet wrote:
> Some oprofile results obtained while using tbench on a 2x2 cpu machine
> were very surprising.
>
> For example, loopback_xmit() function was using high number of cpu
> cycles to perform the statistic updates, supposed to be real cheap
> since they use percpu data
>
> pcpu_lstats = netdev_priv(dev);
> lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
> lb_stats->packets++; /* HERE : serious contention */
> lb_stats->bytes += skb->len;
>
>
> struct pcpu_lstats is a small structure containing two longs. It
> appears that on my 32bits platform, alloc_percpu(8) allocates a single
> cache line, instead of giving to each cpu a separate cache line.
>
> Using the following patch gave me impressive boost in various
> benchmarks ( 6 % in tbench) (all percpu_counters hit this bug too)
>
> Long term fix (ie >= 2.6.26) would be to let each CPU allocate their
> own block of memory, so that we dont need to roudup sizes to
> L1_CACHE_BYTES, or merging the SGI stuff of course...
>
> Note : SLUB vs SLAB is important here to *show* the improvement, since
> they dont have the same minimum allocation sizes (8 bytes vs 32
> bytes). This could very well explain regressions some guys reported
> when they switched to SLUB.
I've complained about this false sharing as well, so until we get the
new and improved percpu allocators,
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> mm/allocpercpu.c | 15 ++++++++++++++-
> 1 files changed, 14 insertions(+), 1 deletion(-)
>
>
> plain text document attachment (percpu_populate.patch)
> diff --git a/mm/allocpercpu.c b/mm/allocpercpu.c
> index 7e58322..b0012e2 100644
> --- a/mm/allocpercpu.c
> +++ b/mm/allocpercpu.c
> @@ -6,6 +6,10 @@
> #include <linux/mm.h>
> #include <linux/module.h>
>
> +#ifndef cache_line_size
> +#define cache_line_size() L1_CACHE_BYTES
> +#endif
> +
> /**
> * percpu_depopulate - depopulate per-cpu data for given cpu
> * @__pdata: per-cpu data to depopulate
> @@ -52,6 +56,11 @@ void *percpu_populate(void *__pdata, size_t size, gfp_t gfp, int cpu)
> struct percpu_data *pdata = __percpu_disguise(__pdata);
> int node = cpu_to_node(cpu);
>
> + /*
> + * We should make sure each CPU gets private memory.
> + */
> + size = roundup(size, cache_line_size());
> +
> BUG_ON(pdata->ptrs[cpu]);
> if (node_online(node))
> pdata->ptrs[cpu] = kmalloc_node(size, gfp|__GFP_ZERO, node);
> @@ -98,7 +107,11 @@ EXPORT_SYMBOL_GPL(__percpu_populate_mask);
> */
> void *__percpu_alloc_mask(size_t size, gfp_t gfp, cpumask_t *mask)
> {
> - void *pdata = kzalloc(nr_cpu_ids * sizeof(void *), gfp);
> + /*
> + * We allocate whole cache lines to avoid false sharing
> + */
> + size_t sz = roundup(nr_cpu_ids * sizeof(void *), cache_line_size());
> + void *pdata = kzalloc(sz, gfp);
> void *__pdata = __percpu_disguise(pdata);
>
> if (unlikely(!pdata))
^ permalink raw reply
* [PATCH] Fix multicast on VLAN interfaces
From: Phil Oester @ 2008-02-21 22:05 UTC (permalink / raw)
To: netdev; +Cc: kaber
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
In commit 56addd6eeeb4e11f5a0af7093ca078e0f29140e0 the VLAN multicast list
handling was reworked. Unfortunately, a variable initialization was missed,
and multicast over vlan devices has been broken since 2.6.23-rc1 (apparently
not too many people use this). Trivial fix below, which might be a candidate
for -stable.
Phil
Signed-off-by: Phil Oester <kernel@linuxace.com>
[-- Attachment #2: patch-mcast-vlan --]
[-- Type: text/plain, Size: 371 bytes --]
diff --git a/net/core/dev.c b/net/core/dev.c
index 908f07c..999af2e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2905,6 +2905,7 @@ int __dev_addr_add(struct dev_addr_list **list, int *count,
return -ENOMEM;
memcpy(da->da_addr, addr, alen);
da->da_addrlen = alen;
+ da->da_synced = 0;
da->da_users = 1;
da->da_gusers = glbl ? 1 : 0;
da->next = *list;
^ permalink raw reply related
* Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
From: Daniel Lezcano @ 2008-02-21 20:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <47BDC848.50607@cosmosbay.com>
Eric Dumazet wrote:
> Hi David
>
> This is an RFC, based on net-2.6 for convenience only.
>
> Thank you
>
> [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
>
> Loopback transmit function loopback_xmit() actually calls netif_rx() to
> queue
> a skb to the softnet queue, and arms a softirq so that this skb can be
> handled later.
>
> This has a cost on SMP, because we need to hold a reference on the
> device, and free this
> reference when softirq dequeues packet.
>
> Following patch directly calls netif_receive_skb() and avoids lot of
> atomic operations.
> (atomic_inc(&dev->refcnt), set_and_set_bit(NAPI_STATE_SCHED, &n->state),
> ...
> atomic_dec(&dev->refcnt)...), cache line ping-pongs on device refcnt,
> but also softirq overhead.
>
> This gives a nice boost on tbench for example (5 % on my machine)
I understand this is interesting for the loopback when there is no
multiple instances of it and it can't be unregistered. But now with the
network namespaces, we can have multiple instances of the loopback and
it can to be unregistered. Shouldn't we still use netif_rx ?
Perhaps we can do something like:
if (dev->nd_net == &init_net)
netif_receive_skb(skb);
else
netif_rx(skb);
Or we create:
init_loopback_xmit() calling netif_receive_skb(skb);
and setup this function when creating the loopback for init_net,
otherwise we setup the usual loopback_xmit.
We are still safe for multiple network namespaces and we have the
improvement for init_net loopback.
^ permalink raw reply
* Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...
From: Andrey Borzenkov @ 2008-02-21 19:46 UTC (permalink / raw)
To: Kok, Auke; +Cc: Andrew Morton, e1000-devel, netdev, linux-kernel
In-Reply-To: <47BDC3E7.8040807@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4774 bytes --]
On Thursday 21 February 2008, Kok, Auke wrote:
> Kok, Auke wrote:
> > Kok, Auke wrote:
> >> Andrew Morton wrote:
> >>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> >>>
> >>>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
> >>>>
> >>>> [ 8803.850634] ACPI: Preparing to enter system sleep state S3
> >>>> [ 8803.853141] Suspending console(s)
> >>>> [ 8805.287505] serial 00:09: disabled
> >>>> [ 8805.291564] Trying to free already-free IRQ 11
> >>>> [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
> >>>> [ 8805.291628] [<c0152127>] free_irq+0xb7/0x130
> >>>> [ 8805.291675] [<c024bd80>] e100_suspend+0xc0/0x100
> >>>> [ 8805.291724] [<c01eaa36>] pci_device_suspend+0x26/0x70
> >>>> [ 8805.291747] [<c0243674>] suspend_device+0x94/0xd0
> >>>> [ 8805.291763] [<c02439a3>] device_suspend+0x153/0x240
> >>>> [ 8805.291784] [<c014314f>] suspend_devices_and_enter+0x4f/0xf0
> >>>> [ 8805.291808] [<c0143a5f>] ? freeze_processes+0x3f/0x80
> >>>> [ 8805.291825] [<c01432fa>] enter_state+0xaa/0x140
> >>>> [ 8805.291840] [<c014341f>] state_store+0x8f/0xd0
> >>>> [ 8805.291852] [<c0143390>] ? state_store+0x0/0xd0
> >>>> [ 8805.291866] [<c01d3404>] kobj_attr_store+0x24/0x30
> >>>> [ 8805.291901] [<c01b547b>] sysfs_write_file+0xbb/0x110
> >>>> [ 8805.291936] [<c0177d79>] vfs_write+0x99/0x130
> >>>> [ 8805.291963] [<c01b53c0>] ? sysfs_write_file+0x0/0x110
> >>>> [ 8805.291979] [<c01782fd>] sys_write+0x3d/0x70
> >>>> [ 8805.291998] [<c010409a>] sysenter_past_esp+0x5f/0xa5
> >>>> [ 8805.292038] =======================
> >>>> [ 8805.347640] ACPI: PCI interrupt for device 0000:00:06.0 disabled
> >>>> [ 8805.361128] ACPI: PCI interrupt for device 0000:00:02.0 disabled
> >>>> [ 8805.376670] hwsleep-0322 [00] enter_sleep_state : Entering sleep state [S3]
> >>>> [ 8805.376670] Back to C!
> >>>>
> >>>> Interface is unused normally (only for netconsole sometimes). dmesg and config
> >>>> attached.
> >>> Does reverting this:
> >>>
> >>> commit 8543da6672b0994921f014f2250e27ae81645580
> >>> Author: Auke Kok <auke-jan.h.kok@intel.com>
> >>> Date: Wed Dec 12 16:30:42 2007 -0800
> >>>
> >>> e100: free IRQ to remove warningwhenrebooting
> >>>
> >>> with this patch:
> >>>
> >>> --- a/drivers/net/e100.c~revert-1
> >>> +++ a/drivers/net/e100.c
> >>> @@ -2804,9 +2804,8 @@ static int e100_suspend(struct pci_dev *
> >>> pci_enable_wake(pdev, PCI_D3cold, 0);
> >>> }
> >>>
> >>> - free_irq(pdev->irq, netdev);
> >>> -
> >>> pci_disable_device(pdev);
> >>> + free_irq(pdev->irq, netdev);
> >>> pci_set_power_state(pdev, PCI_D3hot);
> >>>
> >>> return 0;
> >>> @@ -2848,8 +2847,6 @@ static void e100_shutdown(struct pci_dev
> >>> pci_enable_wake(pdev, PCI_D3cold, 0);
> >>> }
> >>>
> >>> - free_irq(pdev->irq, netdev);
> >>> -
> >>> pci_disable_device(pdev);
> >>> pci_set_power_state(pdev, PCI_D3hot);
> >>> }
> >>> _
> >>>
> >>> fix it?
> >>>
> >>>> Hmm ... after resume device has disappeared at all ...
> >>>>
> >>>> {pts/1}% cat /proc/interrupts
> >>>> CPU0
> >>>> 0: 1290492 XT-PIC-XT timer
> >>>> 1: 6675 XT-PIC-XT i8042
> >>>> 2: 0 XT-PIC-XT cascade
> >>>> 3: 2 XT-PIC-XT
> >>>> 4: 2 XT-PIC-XT
> >>>> 5: 3 XT-PIC-XT
> >>>> 7: 4 XT-PIC-XT irda0
> >>>> 8: 0 XT-PIC-XT rtc0
> >>>> 9: 583 XT-PIC-XT acpi
> >>>> 10: 2 XT-PIC-XT
> >>>> 11: 31483 XT-PIC-XT yenta, yenta, yenta, ohci_hcd:usb1, ALI 5451, pcmcia0.0
> >>>> 12: 28070 XT-PIC-XT i8042
> >>>> 14: 21705 XT-PIC-XT ide0
> >>>> 15: 82123 XT-PIC-XT ide1
> >>>> NMI: 0 Non-maskable interrupts
> >>>> TRM: 0 Thermal event interrupts
> >>>> SPU: 0 Spurious interrupts
> >>>> ERR: 0
> >>> I hope that's not a separate bug...
> >> I'll take a look at this as well. thanks for reporting.
> >
> > ok, I just had a repro - on a regular shutdown even.
> >
> > this always worked before - I'm not blaming anything yet but something in the pci
> > shutdown code must now be freeing our irq for us (I'm not using anything fancy to
> > autoconfigure my network here).
> >
> > I definately do not see this with 2.6.24 either.
>
> can you try this patch please? It rewrites e100 to do suspend/shutdown just like
> e1000e does, which is much more tested than anything else. I don't get the IRQ
> message anymore - but I haven't gotten to testing suspend/resume just yet.
>
Yes it fixes it.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: sungem triggers NAPI warning
From: Johannes Berg @ 2008-02-21 13:05 UTC (permalink / raw)
To: benh; +Cc: netdev
In-Reply-To: <1203562472.10422.102.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
On Thu, 2008-02-21 at 13:54 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-19 at 22:38 +0100, Johannes Berg wrote:
> > I started getting this warning with recent kernels:
>
> Do that help ?
>
> In gem_poll(), do:
>
> - work_done += gem_rx(gp, budget);
> + work_done += gem_rx(gp, budget - work_done);
That looks correct, but I haven't been able to trigger the warning again
even with similar workloads so I haven't tested this change because I
can't even reproduce without it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: kernel BUG at net/core/skbuff.c:95!
From: Jim Westfall @ 2008-02-21 19:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, acme
In-Reply-To: <20080220.215707.194209573.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote [02.20.08]:
> From: Jim Westfall <jwestfall@surrealistic.net>
> Date: Wed, 20 Feb 2008 21:46:48 -0800
>
> > static inline void llc_pdu_init_as_test_rsp(struct sk_buff *skb,
> > struct sk_buff *ev_skb)
> > {
> > struct llc_pdu_un *pdu = llc_pdu_un_hdr(skb);
> >
> > pdu->ctrl_1 = LLC_PDU_TYPE_U;
> > pdu->ctrl_1 |= LLC_1_PDU_CMD_TEST;
> > pdu->ctrl_1 |= LLC_U_PF_BIT_MASK;
> > if (ev_skb->protocol == htons(ETH_P_802_2)) {
> > struct llc_pdu_un *ev_pdu = llc_pdu_un_hdr(ev_skb);
> > int dsize;
> >
> > dsize = ntohs(eth_hdr(ev_skb)->h_proto) - 3;
> > memcpy(((u8 *)pdu) + 3, ((u8 *)ev_pdu) + 3, dsize);
> > skb_put(skb, dsize);
> > }
> > ..
> > }
>
> Probably what should happen is:
>
I just started looking at the skbuff|net|llc code last night, hopefully
these aren't totally stupid questions/comments.
> 1) First this function validates that there are really
> 'dsize' bytes available in the ev_skb source.
looks like this can be done easily with skb_tailroom()..
I am curious if we should also be verifying that dsize is valid? Its
value is coming from a recv'd llc packet.
The llc header is |mac|mac|16bit length|. The above code seems to be
piggy backing a normal ethernet header struct, by using h_proto as the
llc length. I am not sure if that length value can be trusted and we run
the risk of memcpy'ing off the end of the source structure/skbuff?
>
> 2) Second, skb_realloc_headroom() is called on 'skb' with
> a second argument of 'dsize'.
This suggestion escapes me. The skb_put() call in the above
code would increase skb->tail. Wont skb_realloc_headroom() create
additional space between skb->head and skb->data when we really want it
between skb->tail and skb->end?
thanks
jim
>
> That means also this function now needs to return error
> values, and the callers updated to handle that.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
From: Eric Dumazet @ 2008-02-21 18:51 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
Hi David
This is an RFC, based on net-2.6 for convenience only.
Thank you
[RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
Loopback transmit function loopback_xmit() actually calls netif_rx() to
queue
a skb to the softnet queue, and arms a softirq so that this skb can be
handled later.
This has a cost on SMP, because we need to hold a reference on the
device, and free this
reference when softirq dequeues packet.
Following patch directly calls netif_receive_skb() and avoids lot of
atomic operations.
(atomic_inc(&dev->refcnt), set_and_set_bit(NAPI_STATE_SCHED, &n->state), ...
atomic_dec(&dev->refcnt)...), cache line ping-pongs on device refcnt,
but also softirq overhead.
This gives a nice boost on tbench for example (5 % on my machine)
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: loopback_xmit.patch --]
[-- Type: text/plain, Size: 355 bytes --]
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index f2a6e71..9bed7ed 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -158,7 +158,7 @@ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev)
lb_stats->bytes += skb->len;
lb_stats->packets++;
- netif_rx(skb);
+ netif_receive_skb(skb);
return 0;
}
^ permalink raw reply related
* Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...
From: Kok, Auke @ 2008-02-21 18:33 UTC (permalink / raw)
To: Kok, Auke
Cc: e1000-devel, netdev, Andrew Morton, Andrey Borzenkov,
linux-kernel
In-Reply-To: <47BC725C.3060400@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4383 bytes --]
Kok, Auke wrote:
> Kok, Auke wrote:
>> Andrew Morton wrote:
>>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>>>
>>>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>>>
>>>> [ 8803.850634] ACPI: Preparing to enter system sleep state S3
>>>> [ 8803.853141] Suspending console(s)
>>>> [ 8805.287505] serial 00:09: disabled
>>>> [ 8805.291564] Trying to free already-free IRQ 11
>>>> [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
>>>> [ 8805.291628] [<c0152127>] free_irq+0xb7/0x130
>>>> [ 8805.291675] [<c024bd80>] e100_suspend+0xc0/0x100
>>>> [ 8805.291724] [<c01eaa36>] pci_device_suspend+0x26/0x70
>>>> [ 8805.291747] [<c0243674>] suspend_device+0x94/0xd0
>>>> [ 8805.291763] [<c02439a3>] device_suspend+0x153/0x240
>>>> [ 8805.291784] [<c014314f>] suspend_devices_and_enter+0x4f/0xf0
>>>> [ 8805.291808] [<c0143a5f>] ? freeze_processes+0x3f/0x80
>>>> [ 8805.291825] [<c01432fa>] enter_state+0xaa/0x140
>>>> [ 8805.291840] [<c014341f>] state_store+0x8f/0xd0
>>>> [ 8805.291852] [<c0143390>] ? state_store+0x0/0xd0
>>>> [ 8805.291866] [<c01d3404>] kobj_attr_store+0x24/0x30
>>>> [ 8805.291901] [<c01b547b>] sysfs_write_file+0xbb/0x110
>>>> [ 8805.291936] [<c0177d79>] vfs_write+0x99/0x130
>>>> [ 8805.291963] [<c01b53c0>] ? sysfs_write_file+0x0/0x110
>>>> [ 8805.291979] [<c01782fd>] sys_write+0x3d/0x70
>>>> [ 8805.291998] [<c010409a>] sysenter_past_esp+0x5f/0xa5
>>>> [ 8805.292038] =======================
>>>> [ 8805.347640] ACPI: PCI interrupt for device 0000:00:06.0 disabled
>>>> [ 8805.361128] ACPI: PCI interrupt for device 0000:00:02.0 disabled
>>>> [ 8805.376670] hwsleep-0322 [00] enter_sleep_state : Entering sleep state [S3]
>>>> [ 8805.376670] Back to C!
>>>>
>>>> Interface is unused normally (only for netconsole sometimes). dmesg and config
>>>> attached.
>>> Does reverting this:
>>>
>>> commit 8543da6672b0994921f014f2250e27ae81645580
>>> Author: Auke Kok <auke-jan.h.kok@intel.com>
>>> Date: Wed Dec 12 16:30:42 2007 -0800
>>>
>>> e100: free IRQ to remove warningwhenrebooting
>>>
>>> with this patch:
>>>
>>> --- a/drivers/net/e100.c~revert-1
>>> +++ a/drivers/net/e100.c
>>> @@ -2804,9 +2804,8 @@ static int e100_suspend(struct pci_dev *
>>> pci_enable_wake(pdev, PCI_D3cold, 0);
>>> }
>>>
>>> - free_irq(pdev->irq, netdev);
>>> -
>>> pci_disable_device(pdev);
>>> + free_irq(pdev->irq, netdev);
>>> pci_set_power_state(pdev, PCI_D3hot);
>>>
>>> return 0;
>>> @@ -2848,8 +2847,6 @@ static void e100_shutdown(struct pci_dev
>>> pci_enable_wake(pdev, PCI_D3cold, 0);
>>> }
>>>
>>> - free_irq(pdev->irq, netdev);
>>> -
>>> pci_disable_device(pdev);
>>> pci_set_power_state(pdev, PCI_D3hot);
>>> }
>>> _
>>>
>>> fix it?
>>>
>>>> Hmm ... after resume device has disappeared at all ...
>>>>
>>>> {pts/1}% cat /proc/interrupts
>>>> CPU0
>>>> 0: 1290492 XT-PIC-XT timer
>>>> 1: 6675 XT-PIC-XT i8042
>>>> 2: 0 XT-PIC-XT cascade
>>>> 3: 2 XT-PIC-XT
>>>> 4: 2 XT-PIC-XT
>>>> 5: 3 XT-PIC-XT
>>>> 7: 4 XT-PIC-XT irda0
>>>> 8: 0 XT-PIC-XT rtc0
>>>> 9: 583 XT-PIC-XT acpi
>>>> 10: 2 XT-PIC-XT
>>>> 11: 31483 XT-PIC-XT yenta, yenta, yenta, ohci_hcd:usb1, ALI 5451, pcmcia0.0
>>>> 12: 28070 XT-PIC-XT i8042
>>>> 14: 21705 XT-PIC-XT ide0
>>>> 15: 82123 XT-PIC-XT ide1
>>>> NMI: 0 Non-maskable interrupts
>>>> TRM: 0 Thermal event interrupts
>>>> SPU: 0 Spurious interrupts
>>>> ERR: 0
>>> I hope that's not a separate bug...
>> I'll take a look at this as well. thanks for reporting.
>
> ok, I just had a repro - on a regular shutdown even.
>
> this always worked before - I'm not blaming anything yet but something in the pci
> shutdown code must now be freeing our irq for us (I'm not using anything fancy to
> autoconfigure my network here).
>
> I definately do not see this with 2.6.24 either.
can you try this patch please? It rewrites e100 to do suspend/shutdown just like
e1000e does, which is much more tested than anything else. I don't get the IRQ
message anymore - but I haven't gotten to testing suspend/resume just yet.
Auke
[-- Attachment #2: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox