[PATCH] quirk_vialatency: Omit reading pci revision ID
Don't read the revision ID unnecessary since the PCI subsystem
fills this field in already.
Updated to fix a thinko bug in a previously sent patch.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
drivers/pci/quirks.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index d0bb5b9..92dc513 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -139,25 +139,22 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82439TX,quir
static void quirk_vialatency(struct pci_dev *dev)
{
struct pci_dev *p;
- u8 rev;
u8 busarb;
/* Ok we have a potential problem chipset here. Now see if we have
a buggy southbridge */
p = pci_get_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, NULL);
if (p!=NULL) {
- pci_read_config_byte(p, PCI_CLASS_REVISION, );
/* 0x40 - 0x4f == 686B, 0x10 - 0x2f == 686A; thanks Dan Hollis
*/
/* Check for buggy part revisions */
- if (rev < 0x40 || rev > 0x42)
+ if (p->revision < 0x40 || p->revision > 0x42)
goto exit;
} else {
p = pci_get_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231,
NULL);
if (p==NULL)/* No problem parts */
goto exit;
- pci_read_config_byte(p, PCI_CLASS_REVISION, );
/* Check for buggy part revisions */
- if (rev < 0x10 || rev > 0x12)
+ if (p->revision < 0x10 || p->revision > 0x12)
goto exit;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] quirk_vialatency: Omit reading pci revision ID
Don't read the revision ID unnecessary since the PCI subsystem
fills this field in already.
Updated to fix a thinko bug in a previously sent patch.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
drivers/pci/quirks.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index d0bb5b9..92dc513 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -139,25 +139,22 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82439TX,quir
static void quirk_vialatency(struct pci_dev *dev)
{
struct pci_dev *p;
- u8 rev;
u8 busarb;
/* Ok we have a potential problem chipset here. Now see if we have
a buggy southbridge */
p = pci_get_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, NULL);
if (p!=NULL) {
- pci_read_config_byte(p, PCI_CLASS_REVISION, rev);
/* 0x40 - 0x4f == 686B, 0x10 - 0x2f == 686A; thanks Dan Hollis
*/
/* Check for buggy part revisions */
- if (rev 0x40 || rev 0x42)
+ if (p-revision 0x40 || p-revision 0x42)
goto exit;
} else {
p = pci_get_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231,
NULL);
if (p==NULL)/* No problem parts */
goto exit;
- pci_read_config_byte(p, PCI_CLASS_REVISION, rev);
/* Check for buggy part revisions */
- if (rev 0x10 || rev 0x12)
+ if (p-revision 0x10 || p-revision 0x12)
goto exit;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [RESEND] PCI: read revision ID by default
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_64.c |2 ++
arch/sparc64/kernel/pci.c|1 +
drivers/pci/probe.c |1 +
include/linux/pci.h |1 +
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 249cca2..b2c55ca 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -367,8 +367,10 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
dev->class = get_int_prop(node, "class-code", 0);
+ dev->revision = get_int_prop(node, "revision-id", 0);
DBG("class: 0x%x\n", dev->class);
+ DBG("revision: 0x%x\n", dev->revision);
dev->current_state = 4; /* unknown power state */
dev->error_state = pci_channel_io_normal;
diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
index 81f4a5e..55ad1b8 100644
--- a/arch/sparc64/kernel/pci.c
+++ b/arch/sparc64/kernel/pci.c
@@ -448,6 +448,7 @@ struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
*/
pci_read_config_dword(dev, PCI_CLASS_REVISION, );
dev->class = class >> 8;
+ dev->revision = class & 0xff;
sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..a574b7f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -702,6 +702,7 @@ static int pci_setup_device(struct pci_dev * dev)
dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
pci_read_config_dword(dev, PCI_CLASS_REVISION, );
+ dev->revision = class & 0xff;
class >>= 8;/* upper 3 bytes */
dev->class = class;
class >>= 8;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fbf3766..9847936 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -138,6 +138,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned intclass; /* 3 bytes: (base,sub,prog-if) */
+ u8 revision; /* PCI revision, low byte of class word
*/
u8 hdr_type; /* PCI header type (`multi' flag masked
out) */
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [RESEND] PCI: read revision ID by default
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
arch/powerpc/kernel/pci_64.c |2 ++
arch/sparc64/kernel/pci.c|1 +
drivers/pci/probe.c |1 +
include/linux/pci.h |1 +
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 249cca2..b2c55ca 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -367,8 +367,10 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
sprintf(pci_name(dev), %04x:%02x:%02x.%d, pci_domain_nr(bus),
dev-bus-number, PCI_SLOT(devfn), PCI_FUNC(devfn));
dev-class = get_int_prop(node, class-code, 0);
+ dev-revision = get_int_prop(node, revision-id, 0);
DBG(class: 0x%x\n, dev-class);
+ DBG(revision: 0x%x\n, dev-revision);
dev-current_state = 4; /* unknown power state */
dev-error_state = pci_channel_io_normal;
diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
index 81f4a5e..55ad1b8 100644
--- a/arch/sparc64/kernel/pci.c
+++ b/arch/sparc64/kernel/pci.c
@@ -448,6 +448,7 @@ struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
*/
pci_read_config_dword(dev, PCI_CLASS_REVISION, class);
dev-class = class 8;
+ dev-revision = class 0xff;
sprintf(pci_name(dev), %04x:%02x:%02x.%d, pci_domain_nr(bus),
dev-bus-number, PCI_SLOT(devfn), PCI_FUNC(devfn));
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..a574b7f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -702,6 +702,7 @@ static int pci_setup_device(struct pci_dev * dev)
dev-bus-number, PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn));
pci_read_config_dword(dev, PCI_CLASS_REVISION, class);
+ dev-revision = class 0xff;
class = 8;/* upper 3 bytes */
dev-class = class;
class = 8;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fbf3766..9847936 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -138,6 +138,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned intclass; /* 3 bytes: (base,sub,prog-if) */
+ u8 revision; /* PCI revision, low byte of class word
*/
u8 hdr_type; /* PCI header type (`multi' flag masked
out) */
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: also read revision ID for sparc64, ppc, read class at the same time
Since the PCI bus class and revision are in the same dword, we
can fill in both in the same read.
Other non-x86 arches use different methods to fill in these values,
make sure to adjust those too.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_64.c |2 ++
arch/sparc64/kernel/pci.c|1 +
drivers/pci/probe.c |4 +---
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 249cca2..b2c55ca 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -367,8 +367,10 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
dev->class = get_int_prop(node, "class-code", 0);
+ dev->revision = get_int_prop(node, "revision-id", 0);
DBG("class: 0x%x\n", dev->class);
+ DBG("revision: 0x%x\n", dev->revision);
dev->current_state = 4; /* unknown power state */
dev->error_state = pci_channel_io_normal;
diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
index 38a32bc..759cc20 100644
--- a/arch/sparc64/kernel/pci.c
+++ b/arch/sparc64/kernel/pci.c
@@ -448,6 +448,7 @@ struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
*/
pci_read_config_dword(dev, PCI_CLASS_REVISION, );
dev->class = class >> 8;
+ dev->revision = class & 0xff;
sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 0fdb71d..a574b7f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -702,6 +702,7 @@ static int pci_setup_device(struct pci_dev * dev)
dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
pci_read_config_dword(dev, PCI_CLASS_REVISION, );
+ dev->revision = class & 0xff;
class >>= 8;/* upper 3 bytes */
dev->class = class;
class >>= 8;
@@ -918,9 +919,6 @@ pci_scan_device(struct pci_bus *bus, int devfn)
dev->cfg_size = pci_cfg_space_size(dev);
dev->error_state = pci_channel_io_normal;
- /* read the PCI revision: 1 byte */
- pci_read_config_byte(dev, PCI_REVISION_ID, >revision);
-
/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
set this higher, assuming the system even supports it. */
dev->dma_mask = 0x;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: also read revision ID for sparc64, ppc, read class at the same time
Since the PCI bus class and revision are in the same dword, we can fill in both in the same read. Other non-x86 arches use different methods to fill in these values, make sure to adjust those too. Signed-off-by: Auke Kok [EMAIL PROTECTED] --- arch/powerpc/kernel/pci_64.c |2 ++ arch/sparc64/kernel/pci.c|1 + drivers/pci/probe.c |4 +--- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c index 249cca2..b2c55ca 100644 --- a/arch/powerpc/kernel/pci_64.c +++ b/arch/powerpc/kernel/pci_64.c @@ -367,8 +367,10 @@ struct pci_dev *of_create_pci_dev(struct device_node *node, sprintf(pci_name(dev), %04x:%02x:%02x.%d, pci_domain_nr(bus), dev-bus-number, PCI_SLOT(devfn), PCI_FUNC(devfn)); dev-class = get_int_prop(node, class-code, 0); + dev-revision = get_int_prop(node, revision-id, 0); DBG(class: 0x%x\n, dev-class); + DBG(revision: 0x%x\n, dev-revision); dev-current_state = 4; /* unknown power state */ dev-error_state = pci_channel_io_normal; diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c index 38a32bc..759cc20 100644 --- a/arch/sparc64/kernel/pci.c +++ b/arch/sparc64/kernel/pci.c @@ -448,6 +448,7 @@ struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm, */ pci_read_config_dword(dev, PCI_CLASS_REVISION, class); dev-class = class 8; + dev-revision = class 0xff; sprintf(pci_name(dev), %04x:%02x:%02x.%d, pci_domain_nr(bus), dev-bus-number, PCI_SLOT(devfn), PCI_FUNC(devfn)); diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 0fdb71d..a574b7f 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -702,6 +702,7 @@ static int pci_setup_device(struct pci_dev * dev) dev-bus-number, PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn)); pci_read_config_dword(dev, PCI_CLASS_REVISION, class); + dev-revision = class 0xff; class = 8;/* upper 3 bytes */ dev-class = class; class = 8; @@ -918,9 +919,6 @@ pci_scan_device(struct pci_bus *bus, int devfn) dev-cfg_size = pci_cfg_space_size(dev); dev-error_state = pci_channel_io_normal; - /* read the PCI revision: 1 byte */ - pci_read_config_byte(dev, PCI_REVISION_ID, dev-revision); - /* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer) set this higher, assuming the system even supports it. */ dev-dma_mask = 0x; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [RFC] PCI: read revision ID by default
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/pci/probe.c |3 +++
include/linux/pci.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..0fdb71d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -918,6 +918,9 @@ pci_scan_device(struct pci_bus *bus, int devfn)
dev->cfg_size = pci_cfg_space_size(dev);
dev->error_state = pci_channel_io_normal;
+ /* read the PCI revision: 1 byte */
+ pci_read_config_byte(dev, PCI_REVISION_ID, >revision);
+
/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
set this higher, assuming the system even supports it. */
dev->dma_mask = 0x;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fbf3766..9847936 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -138,6 +138,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned intclass; /* 3 bytes: (base,sub,prog-if) */
+ u8 revision; /* PCI revision, low byte of class word
*/
u8 hdr_type; /* PCI header type (`multi' flag masked
out) */
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [RFC] PCI: read revision ID by default
Currently there are 97 occurrences where drivers need the pci
revision ID. We can do this once for all devices. Even the pci
subsystem needs the revision several times for quirks. The extra
u8 member pads out nicely in the pci_dev struct.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/pci/probe.c |3 +++
include/linux/pci.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e48fcf0..0fdb71d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -918,6 +918,9 @@ pci_scan_device(struct pci_bus *bus, int devfn)
dev-cfg_size = pci_cfg_space_size(dev);
dev-error_state = pci_channel_io_normal;
+ /* read the PCI revision: 1 byte */
+ pci_read_config_byte(dev, PCI_REVISION_ID, dev-revision);
+
/* Assume 32-bit PCI; let 64-bit PCI cards (which are far rarer)
set this higher, assuming the system even supports it. */
dev-dma_mask = 0x;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fbf3766..9847936 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -138,6 +138,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned intclass; /* 3 bytes: (base,sub,prog-if) */
+ u8 revision; /* PCI revision, low byte of class word
*/
u8 hdr_type; /* PCI header type (`multi' flag masked
out) */
u8 rom_base_reg; /* which config register controls the
ROM */
u8 pin;/* which interrupt pin this device uses
*/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] [condingstyle] Add chapter on tests
Several standards have been established on how to format tests and use
NULL/false/true tests.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
Documentation/CodingStyle | 51 +++--
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index f518395..3635b38 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -393,7 +393,7 @@ int fun(int a)
int result = 0;
char *buffer = kmalloc(SIZE);
- if (buffer == NULL)
+ if (!buffer)
return -ENOMEM;
if (condition1) {
@@ -409,7 +409,36 @@ out:
return result;
}
- Chapter 8: Commenting
+ Chapyer 8: Tests
+
+Testing return values from function calls can get complex when you need
+to re-use the value later on. You should store the value before doing
+any tests on it. Never assign values inside a condition to another
+variable.
+
+ err = test_something();
+ if (err) {
+ printk(KERN_ERR "Error: test_something() failed\n");
+ return err;
+ }
+
+If you give your variables and pointers good names, there is never a need
+to compare the value stored in that variable to NULL or true/false, so
+omit all that and keep it short.
+
+ ptr = s->next;
+ if (!ptr)
+ return;
+
+ v = (read_byte(register));
+ if (v & mask)
+ return;
+
+ if (is_prime(number))
+ return 0;
+
+
+ Chapter 9: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
try to explain HOW your code works in a comment: it's much better to
@@ -449,7 +478,7 @@ multiple data declarations). This leaves you room for a
small comment on each
item, explaining its use.
- Chapter 9: You've made a mess of it
+ Chapter 10: You've made a mess of it
That's OK, we all do. You've probably been told by your long-time Unix
user helper that "GNU emacs" automatically formats the C sources for
@@ -497,7 +526,7 @@ re-formatting you may want to take a look at the man page.
But
remember: "indent" is not a fix for bad programming.
- Chapter 10: Configuration-files
+ Chapter 11: Configuration-files
For configuration options (arch/xxx/Kconfig, and all the Kconfig files),
somewhat different indentation is used.
@@ -522,7 +551,7 @@ support for file-systems, for instance) should be denoted
(DANGEROUS), other
experimental options should be denoted (EXPERIMENTAL).
- Chapter 11: Data structures
+ Chapter 12: Data structures
Data structures that have visibility outside the single-threaded
environment they are created and destroyed in should always have
@@ -553,7 +582,7 @@ Remember: if another thread can find your data structure,
and you don't
have a reference count on it, you almost certainly have a bug.
- Chapter 12: Macros, Enums and RTL
+ Chapter 13: Macros, Enums and RTL
Names of macros defining constants and labels in enums are capitalized.
@@ -608,7 +637,7 @@ The cpp manual deals with macros exhaustively. The gcc
internals manual also
covers RTL which is used frequently with assembly language in the kernel.
- Chapter 13: Printing kernel messages
+ Chapter 14: Printing kernel messages
Kernel developers like to be seen as literate. Do mind the spelling
of kernel messages to make a good impression. Do not use crippled
@@ -619,7 +648,7 @@ Kernel messages do not have to be terminated with a period.
Printing numbers in parentheses (%d) adds no value and should be avoided.
- Chapter 14: Allocating memory
+ Chapter 15: Allocating memory
The kernel provides the following general purpose memory allocators:
kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API
@@ -638,7 +667,7 @@ from void pointer to any other pointer type is guaranteed
by the C programming
language.
- Chapter 15: The inline disease
+ Chapter 16: The inline disease
There appears to be a common misperception that gcc has a magic "make me
faster" speedup option called "inline". While the use of inlines can be
@@ -665,7 +694,7 @@ appears outweighs the potential value of the hint that
tells gcc to do
something it would have done anyway.
- Chapter 16: Function return values and names
+ Chapter 17: Function return values and names
Functions can return values of many different kinds, and one of the
most common is a value indicating whether the function succeeded or
@@ -699,7 +728,7 @@ result. Typical examples would be functions that return
pointers; they use
NULL or the ERR_PTR mechanism to report failure.
[PATCH 1/2] [CodingStyle] Add comment to not put spaces before tabs.
Mixed space/tab indentation is wrong. Ironically this is what the coding style document actually shows ;) Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- Documentation/CodingStyle |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index afc2867..f518395 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -13,7 +13,7 @@ and NOT read it. Burn them, it's a great symbolic gesture. Anyway, here goes: - Chapter 1: Indentation + Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) @@ -71,6 +71,8 @@ used for indentation, and the above example is deliberately broken. Get a decent editor and don't leave whitespace at the end of lines. +Don't put spaces before tabs or mix them. + Chapter 2: Breaking long lines and strings - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [CodingStyle] Add comment to not put spaces before tabs.
Mixed space/tab indentation is wrong. Ironically this is what the coding style document actually shows ;) Signed-off-by: Auke Kok [EMAIL PROTECTED] --- Documentation/CodingStyle |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index afc2867..f518395 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -13,7 +13,7 @@ and NOT read it. Burn them, it's a great symbolic gesture. Anyway, here goes: - Chapter 1: Indentation + Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) @@ -71,6 +71,8 @@ used for indentation, and the above example is deliberately broken. Get a decent editor and don't leave whitespace at the end of lines. +Don't put spaces before tabs or mix them. + Chapter 2: Breaking long lines and strings - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] [condingstyle] Add chapter on tests
Several standards have been established on how to format tests and use
NULL/false/true tests.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
Documentation/CodingStyle | 51 +++--
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index f518395..3635b38 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -393,7 +393,7 @@ int fun(int a)
int result = 0;
char *buffer = kmalloc(SIZE);
- if (buffer == NULL)
+ if (!buffer)
return -ENOMEM;
if (condition1) {
@@ -409,7 +409,36 @@ out:
return result;
}
- Chapter 8: Commenting
+ Chapyer 8: Tests
+
+Testing return values from function calls can get complex when you need
+to re-use the value later on. You should store the value before doing
+any tests on it. Never assign values inside a condition to another
+variable.
+
+ err = test_something();
+ if (err) {
+ printk(KERN_ERR Error: test_something() failed\n);
+ return err;
+ }
+
+If you give your variables and pointers good names, there is never a need
+to compare the value stored in that variable to NULL or true/false, so
+omit all that and keep it short.
+
+ ptr = s-next;
+ if (!ptr)
+ return;
+
+ v = (read_byte(register));
+ if (v mask)
+ return;
+
+ if (is_prime(number))
+ return 0;
+
+
+ Chapter 9: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
try to explain HOW your code works in a comment: it's much better to
@@ -449,7 +478,7 @@ multiple data declarations). This leaves you room for a
small comment on each
item, explaining its use.
- Chapter 9: You've made a mess of it
+ Chapter 10: You've made a mess of it
That's OK, we all do. You've probably been told by your long-time Unix
user helper that GNU emacs automatically formats the C sources for
@@ -497,7 +526,7 @@ re-formatting you may want to take a look at the man page.
But
remember: indent is not a fix for bad programming.
- Chapter 10: Configuration-files
+ Chapter 11: Configuration-files
For configuration options (arch/xxx/Kconfig, and all the Kconfig files),
somewhat different indentation is used.
@@ -522,7 +551,7 @@ support for file-systems, for instance) should be denoted
(DANGEROUS), other
experimental options should be denoted (EXPERIMENTAL).
- Chapter 11: Data structures
+ Chapter 12: Data structures
Data structures that have visibility outside the single-threaded
environment they are created and destroyed in should always have
@@ -553,7 +582,7 @@ Remember: if another thread can find your data structure,
and you don't
have a reference count on it, you almost certainly have a bug.
- Chapter 12: Macros, Enums and RTL
+ Chapter 13: Macros, Enums and RTL
Names of macros defining constants and labels in enums are capitalized.
@@ -608,7 +637,7 @@ The cpp manual deals with macros exhaustively. The gcc
internals manual also
covers RTL which is used frequently with assembly language in the kernel.
- Chapter 13: Printing kernel messages
+ Chapter 14: Printing kernel messages
Kernel developers like to be seen as literate. Do mind the spelling
of kernel messages to make a good impression. Do not use crippled
@@ -619,7 +648,7 @@ Kernel messages do not have to be terminated with a period.
Printing numbers in parentheses (%d) adds no value and should be avoided.
- Chapter 14: Allocating memory
+ Chapter 15: Allocating memory
The kernel provides the following general purpose memory allocators:
kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API
@@ -638,7 +667,7 @@ from void pointer to any other pointer type is guaranteed
by the C programming
language.
- Chapter 15: The inline disease
+ Chapter 16: The inline disease
There appears to be a common misperception that gcc has a magic make me
faster speedup option called inline. While the use of inlines can be
@@ -665,7 +694,7 @@ appears outweighs the potential value of the hint that
tells gcc to do
something it would have done anyway.
- Chapter 16: Function return values and names
+ Chapter 17: Function return values and names
Functions can return values of many different kinds, and one of the
most common is a value indicating whether the function succeeded or
@@ -699,7 +728,7 @@ result. Typical examples would be functions that return
pointers; they use
NULL or the ERR_PTR mechanism to report failure.
- Chapter 17: Don't re-invent the kernel macros
+ Chapter 18: Don't
[PATCH 2/3] e1000: FIX: firmware handover bits
From: Bruce Allan <[EMAIL PROTECTED]>
Upon code inspection it was spotted that the firmware handover bit get/set
mismatched, which may have resulted in management issues on PCI-E
adapters. Setting them correctly may fix some management issues such
as arp routing etc.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Bruce Allan <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 33 -
1 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index fff3bc0..3492f0b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -409,25 +409,21 @@ e1000_release_hw_control(struct e1000_adapter *adapter)
{
uint32_t ctrl_ext;
uint32_t swsm;
- uint32_t extcnf;
/* Let firmware taken over control of h/w */
switch (adapter->hw.mac_type) {
- case e1000_82571:
- case e1000_82572:
- case e1000_80003es2lan:
- ctrl_ext = E1000_READ_REG(>hw, CTRL_EXT);
- E1000_WRITE_REG(>hw, CTRL_EXT,
- ctrl_ext & ~E1000_CTRL_EXT_DRV_LOAD);
- break;
case e1000_82573:
swsm = E1000_READ_REG(>hw, SWSM);
E1000_WRITE_REG(>hw, SWSM,
swsm & ~E1000_SWSM_DRV_LOAD);
+ break;
+ case e1000_82571:
+ case e1000_82572:
+ case e1000_80003es2lan:
case e1000_ich8lan:
- extcnf = E1000_READ_REG(>hw, CTRL_EXT);
+ ctrl_ext = E1000_READ_REG(>hw, CTRL_EXT);
E1000_WRITE_REG(>hw, CTRL_EXT,
- extcnf & ~E1000_CTRL_EXT_DRV_LOAD);
+ ctrl_ext & ~E1000_CTRL_EXT_DRV_LOAD);
break;
default:
break;
@@ -450,26 +446,21 @@ e1000_get_hw_control(struct e1000_adapter *adapter)
{
uint32_t ctrl_ext;
uint32_t swsm;
- uint32_t extcnf;
/* Let firmware know the driver has taken over */
switch (adapter->hw.mac_type) {
- case e1000_82571:
- case e1000_82572:
- case e1000_80003es2lan:
- ctrl_ext = E1000_READ_REG(>hw, CTRL_EXT);
- E1000_WRITE_REG(>hw, CTRL_EXT,
- ctrl_ext | E1000_CTRL_EXT_DRV_LOAD);
- break;
case e1000_82573:
swsm = E1000_READ_REG(>hw, SWSM);
E1000_WRITE_REG(>hw, SWSM,
swsm | E1000_SWSM_DRV_LOAD);
break;
+ case e1000_82571:
+ case e1000_82572:
+ case e1000_80003es2lan:
case e1000_ich8lan:
- extcnf = E1000_READ_REG(>hw, EXTCNF_CTRL);
- E1000_WRITE_REG(>hw, EXTCNF_CTRL,
- extcnf | E1000_EXTCNF_CTRL_SWFLAG);
+ ctrl_ext = E1000_READ_REG(>hw, CTRL_EXT);
+ E1000_WRITE_REG(>hw, CTRL_EXT,
+ ctrl_ext | E1000_CTRL_EXT_DRV_LOAD);
break;
default:
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq
From: Auke Kok <[EMAIL PROTECTED]>
DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts
after having called pci_request_irq. This obviously requires us to finish
our software setup which assigns the irq handler before we request the
irq.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 66 +++-
1 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 98215fd..fff3bc0 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -522,14 +522,15 @@ e1000_release_manageability(struct e1000_adapter *adapter)
}
}
-int
-e1000_up(struct e1000_adapter *adapter)
+/**
+ * e1000_configure - configure the hardware for RX and TX
+ * @adapter = private board structure
+ **/
+static void e1000_configure(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
int i;
- /* hardware has been reset, we need to reload some things */
-
e1000_set_multi(netdev);
e1000_restore_vlan(adapter);
@@ -548,14 +549,20 @@ e1000_up(struct e1000_adapter *adapter)
}
adapter->tx_queue_len = netdev->tx_queue_len;
+}
+
+int e1000_up(struct e1000_adapter *adapter)
+{
+ /* hardware has been reset, we need to reload some things */
+ e1000_configure(adapter);
+
+ clear_bit(__E1000_DOWN, >flags);
#ifdef CONFIG_E1000_NAPI
- netif_poll_enable(netdev);
+ netif_poll_enable(adapter->netdev);
#endif
e1000_irq_enable(adapter);
- clear_bit(__E1000_DOWN, >flags);
-
/* fire a link change interrupt to start the watchdog */
E1000_WRITE_REG(>hw, ICS, E1000_ICS_LSC);
return 0;
@@ -640,15 +647,15 @@ e1000_down(struct e1000_adapter *adapter)
* reschedule our watchdog timer */
set_bit(__E1000_DOWN, >flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_disable(netdev);
+#endif
e1000_irq_disable(adapter);
del_timer_sync(>tx_fifo_stall_timer);
del_timer_sync(>watchdog_timer);
del_timer_sync(>phy_info_timer);
-#ifdef CONFIG_E1000_NAPI
- netif_poll_disable(netdev);
-#endif
netdev->tx_queue_len = adapter->tx_queue_len;
adapter->link_speed = 0;
adapter->link_duplex = 0;
@@ -1410,21 +1417,17 @@ e1000_open(struct net_device *netdev)
return -EBUSY;
/* allocate transmit descriptors */
- if ((err = e1000_setup_all_tx_resources(adapter)))
+ err = e1000_setup_all_tx_resources(adapter);
+ if (err)
goto err_setup_tx;
/* allocate receive descriptors */
- if ((err = e1000_setup_all_rx_resources(adapter)))
- goto err_setup_rx;
-
- err = e1000_request_irq(adapter);
+ err = e1000_setup_all_rx_resources(adapter);
if (err)
- goto err_req_irq;
+ goto err_setup_rx;
e1000_power_up_phy(adapter);
- if ((err = e1000_up(adapter)))
- goto err_up;
adapter->mng_vlan_id = E1000_MNG_VLAN_NONE;
if ((adapter->hw.mng_cookie.status &
E1000_MNG_DHCP_COOKIE_STATUS_VLAN_SUPPORT)) {
@@ -1437,12 +1440,33 @@ e1000_open(struct net_device *netdev)
e1000_check_mng_mode(>hw))
e1000_get_hw_control(adapter);
+ /* before we allocate an interrupt, we must be ready to handle it.
+* Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
+* as soon as we call pci_request_irq, so we have to setup our
+* clean_rx handler before we do so. */
+ e1000_configure(adapter);
+
+ err = e1000_request_irq(adapter);
+ if (err)
+ goto err_req_irq;
+
+ /* From here on the code is the same as e1000_up() */
+ clear_bit(__E1000_DOWN, >flags);
+
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
+ e1000_irq_enable(adapter);
+
+ /* fire a link status change interrupt to start the watchdog */
+ E1000_WRITE_REG(>hw, ICS, E1000_ICS_LSC);
+
return E1000_SUCCESS;
-err_up:
- e1000_power_down_phy(adapter);
- e1000_free_irq(adapter);
err_req_irq:
+ e1000_release_hw_control(adapter);
+ e1000_power_down_phy(adapter);
e1000_free_all_rx_resources(adapter);
err_setup_rx:
e1000_free_all_tx_resources(adapter);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] e1000: FIX: Stop raw interrupts disabled nag from RT
From: Mark Huth <[EMAIL PROTECTED]>
Current e1000_xmit_frame spews raw interrupt disabled nag messages when
used with RT kernel patches. This patch uses spin_trylock_irqsave,
which allows RT patches to properly manage the irq semantics.
Signed-off-by: Mark Huth <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 3492f0b..7bbefca 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3378,12 +3378,9 @@ e1000_xmit_frame(struct sk_buff *skb, struct net_device
*netdev)
(adapter->hw.mac_type == e1000_82573))
e1000_transfer_dhcp_info(adapter, skb);
- local_irq_save(flags);
- if (!spin_trylock(_ring->tx_lock)) {
+ if (!spin_trylock_irqsave(_ring->tx_lock, flags))
/* Collision - tell upper layer to requeue */
- local_irq_restore(flags);
return NETDEV_TX_LOCKED;
- }
/* need: count + 2 desc gap to keep tail from touching
* head, otherwise try next time */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq
From: Auke Kok [EMAIL PROTECTED]
DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts
after having called pci_request_irq. This obviously requires us to finish
our software setup which assigns the irq handler before we request the
irq.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 66 +++-
1 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 98215fd..fff3bc0 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -522,14 +522,15 @@ e1000_release_manageability(struct e1000_adapter *adapter)
}
}
-int
-e1000_up(struct e1000_adapter *adapter)
+/**
+ * e1000_configure - configure the hardware for RX and TX
+ * @adapter = private board structure
+ **/
+static void e1000_configure(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter-netdev;
int i;
- /* hardware has been reset, we need to reload some things */
-
e1000_set_multi(netdev);
e1000_restore_vlan(adapter);
@@ -548,14 +549,20 @@ e1000_up(struct e1000_adapter *adapter)
}
adapter-tx_queue_len = netdev-tx_queue_len;
+}
+
+int e1000_up(struct e1000_adapter *adapter)
+{
+ /* hardware has been reset, we need to reload some things */
+ e1000_configure(adapter);
+
+ clear_bit(__E1000_DOWN, adapter-flags);
#ifdef CONFIG_E1000_NAPI
- netif_poll_enable(netdev);
+ netif_poll_enable(adapter-netdev);
#endif
e1000_irq_enable(adapter);
- clear_bit(__E1000_DOWN, adapter-flags);
-
/* fire a link change interrupt to start the watchdog */
E1000_WRITE_REG(adapter-hw, ICS, E1000_ICS_LSC);
return 0;
@@ -640,15 +647,15 @@ e1000_down(struct e1000_adapter *adapter)
* reschedule our watchdog timer */
set_bit(__E1000_DOWN, adapter-flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_disable(netdev);
+#endif
e1000_irq_disable(adapter);
del_timer_sync(adapter-tx_fifo_stall_timer);
del_timer_sync(adapter-watchdog_timer);
del_timer_sync(adapter-phy_info_timer);
-#ifdef CONFIG_E1000_NAPI
- netif_poll_disable(netdev);
-#endif
netdev-tx_queue_len = adapter-tx_queue_len;
adapter-link_speed = 0;
adapter-link_duplex = 0;
@@ -1410,21 +1417,17 @@ e1000_open(struct net_device *netdev)
return -EBUSY;
/* allocate transmit descriptors */
- if ((err = e1000_setup_all_tx_resources(adapter)))
+ err = e1000_setup_all_tx_resources(adapter);
+ if (err)
goto err_setup_tx;
/* allocate receive descriptors */
- if ((err = e1000_setup_all_rx_resources(adapter)))
- goto err_setup_rx;
-
- err = e1000_request_irq(adapter);
+ err = e1000_setup_all_rx_resources(adapter);
if (err)
- goto err_req_irq;
+ goto err_setup_rx;
e1000_power_up_phy(adapter);
- if ((err = e1000_up(adapter)))
- goto err_up;
adapter-mng_vlan_id = E1000_MNG_VLAN_NONE;
if ((adapter-hw.mng_cookie.status
E1000_MNG_DHCP_COOKIE_STATUS_VLAN_SUPPORT)) {
@@ -1437,12 +1440,33 @@ e1000_open(struct net_device *netdev)
e1000_check_mng_mode(adapter-hw))
e1000_get_hw_control(adapter);
+ /* before we allocate an interrupt, we must be ready to handle it.
+* Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
+* as soon as we call pci_request_irq, so we have to setup our
+* clean_rx handler before we do so. */
+ e1000_configure(adapter);
+
+ err = e1000_request_irq(adapter);
+ if (err)
+ goto err_req_irq;
+
+ /* From here on the code is the same as e1000_up() */
+ clear_bit(__E1000_DOWN, adapter-flags);
+
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
+ e1000_irq_enable(adapter);
+
+ /* fire a link status change interrupt to start the watchdog */
+ E1000_WRITE_REG(adapter-hw, ICS, E1000_ICS_LSC);
+
return E1000_SUCCESS;
-err_up:
- e1000_power_down_phy(adapter);
- e1000_free_irq(adapter);
err_req_irq:
+ e1000_release_hw_control(adapter);
+ e1000_power_down_phy(adapter);
e1000_free_all_rx_resources(adapter);
err_setup_rx:
e1000_free_all_tx_resources(adapter);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] e1000: FIX: Stop raw interrupts disabled nag from RT
From: Mark Huth [EMAIL PROTECTED]
Current e1000_xmit_frame spews raw interrupt disabled nag messages when
used with RT kernel patches. This patch uses spin_trylock_irqsave,
which allows RT patches to properly manage the irq semantics.
Signed-off-by: Mark Huth [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 3492f0b..7bbefca 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3378,12 +3378,9 @@ e1000_xmit_frame(struct sk_buff *skb, struct net_device
*netdev)
(adapter-hw.mac_type == e1000_82573))
e1000_transfer_dhcp_info(adapter, skb);
- local_irq_save(flags);
- if (!spin_trylock(tx_ring-tx_lock)) {
+ if (!spin_trylock_irqsave(tx_ring-tx_lock, flags))
/* Collision - tell upper layer to requeue */
- local_irq_restore(flags);
return NETDEV_TX_LOCKED;
- }
/* need: count + 2 desc gap to keep tail from touching
* head, otherwise try next time */
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] e1000: FIX: firmware handover bits
From: Bruce Allan [EMAIL PROTECTED]
Upon code inspection it was spotted that the firmware handover bit get/set
mismatched, which may have resulted in management issues on PCI-E
adapters. Setting them correctly may fix some management issues such
as arp routing etc.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Bruce Allan [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 33 -
1 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index fff3bc0..3492f0b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -409,25 +409,21 @@ e1000_release_hw_control(struct e1000_adapter *adapter)
{
uint32_t ctrl_ext;
uint32_t swsm;
- uint32_t extcnf;
/* Let firmware taken over control of h/w */
switch (adapter-hw.mac_type) {
- case e1000_82571:
- case e1000_82572:
- case e1000_80003es2lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
- ctrl_ext ~E1000_CTRL_EXT_DRV_LOAD);
- break;
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, SWSM);
E1000_WRITE_REG(adapter-hw, SWSM,
swsm ~E1000_SWSM_DRV_LOAD);
+ break;
+ case e1000_82571:
+ case e1000_82572:
+ case e1000_80003es2lan:
case e1000_ich8lan:
- extcnf = E1000_READ_REG(adapter-hw, CTRL_EXT);
+ ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
E1000_WRITE_REG(adapter-hw, CTRL_EXT,
- extcnf ~E1000_CTRL_EXT_DRV_LOAD);
+ ctrl_ext ~E1000_CTRL_EXT_DRV_LOAD);
break;
default:
break;
@@ -450,26 +446,21 @@ e1000_get_hw_control(struct e1000_adapter *adapter)
{
uint32_t ctrl_ext;
uint32_t swsm;
- uint32_t extcnf;
/* Let firmware know the driver has taken over */
switch (adapter-hw.mac_type) {
- case e1000_82571:
- case e1000_82572:
- case e1000_80003es2lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
- ctrl_ext | E1000_CTRL_EXT_DRV_LOAD);
- break;
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, SWSM);
E1000_WRITE_REG(adapter-hw, SWSM,
swsm | E1000_SWSM_DRV_LOAD);
break;
+ case e1000_82571:
+ case e1000_82572:
+ case e1000_80003es2lan:
case e1000_ich8lan:
- extcnf = E1000_READ_REG(adapter-hw, EXTCNF_CTRL);
- E1000_WRITE_REG(adapter-hw, EXTCNF_CTRL,
- extcnf | E1000_EXTCNF_CTRL_SWFLAG);
+ ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
+ E1000_WRITE_REG(adapter-hw, CTRL_EXT,
+ ctrl_ext | E1000_CTRL_EXT_DRV_LOAD);
break;
default:
break;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: e1000_intr in request_irq faults in 2.6.20-git
Andrew Morton wrote: On Thu, 15 Feb 2007 18:10:53 -0800 "Brandeburg, Jesse" <[EMAIL PROTECTED]> wrote: @@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev) e1000_update_mng_vlan(adapter); } + err = e1000_request_irq(adapter); + if (err) + goto err_req_irq; + /* If AMT is enabled, let the firmware know that the network * interface is now open */ if (adapter->hw.mac_type == e1000_82573 && @@ -1439,10 +1439,11 @@ e1000_open(struct net_device *netdev) return E1000_SUCCESS; +err_req_irq: + e1000_down(adapter); + e1000_free_irq(adapter); err_up: We don't want that e1000_free_irq(adapter) in the error path. indeed, thanks for spotting and telling me before I sent this to Jeff. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000_intr in request_irq faults in 2.6.20-git
[Adding Dimitri Mishin to the CC - he proposed the same patch earlier]
Len Brown wrote:
On Thursday 15 February 2007 21:10, Brandeburg, Jesse wrote:
Eric W. Biederman wrote:
Len Brown <[EMAIL PROTECTED]> writes:
e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
System is a D875PBZ with LOM.
clues?
I'm guessing this is an old bug found by the following bit of
debug coded added into since v2.6.20
+#ifdef CONFIG_DEBUG_SHIRQ
+ if (irqflags & IRQF_SHARED) {
+ /*
+* It's a shared IRQ -- the driver ought to be
prepared for it +* to happen immediately, so let's
make sure +* We do this before actually
registering it, to make sure that +* a 'real' IRQ
doesn't run in parallel with our fake +*/
+ if (irqflags & IRQF_DISABLED) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ handler(irq, dev_id);
+ local_irq_restore(flags);
+ } else
+ handler(irq, dev_id);
+ }
+#endif
I don't have a clue why the e1000 wasn't ready though.
our code is clearly calling request_irq before we have assigned the
function pointer adapter->clean_rx as well as adapter->alloc_rx_buf
That would be a bug, a possible patch would be (inline and attached):
compile tested, *but* I couldn't test this patch to make sure it worked
because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
disk.
[PATCH] e1000: fix shared interrupt warning message
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c
b/drivers/net/e1000/e1000_main.c
index 619c892..b8c4d5c 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1417,10 +1417,6 @@ e1000_open(struct net_device *netdev)
if ((err = e1000_setup_all_rx_resources(adapter)))
goto err_setup_rx;
- err = e1000_request_irq(adapter);
- if (err)
- goto err_req_irq;
-
e1000_power_up_phy(adapter);
if ((err = e1000_up(adapter)))
@@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev)
e1000_update_mng_vlan(adapter);
}
+ err = e1000_request_irq(adapter);
+ if (err)
+ goto err_req_irq;
+
/* If AMT is enabled, let the firmware know that the network
* interface is now open */
if (adapter->hw.mac_type == e1000_82573 &&
@@ -1439,10 +1439,11 @@ e1000_open(struct net_device *netdev)
return E1000_SUCCESS;
+err_req_irq:
+ e1000_down(adapter);
+ e1000_free_irq(adapter);
err_up:
e1000_power_down_phy(adapter);
- e1000_free_irq(adapter);
-err_req_irq:
e1000_free_all_rx_resources(adapter);
err_setup_rx:
e1000_free_all_tx_resources(adapter);
Works for me(tm) on latest 2.6.20-git and D875PBZ.
If there are no objections I'll push this patch to Jeff Garzik together with two
other changes I have for him.
Cheers,
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: e1000_intr in request_irq faults in 2.6.20-git
[Adding Dimitri Mishin to the CC - he proposed the same patch earlier]
Len Brown wrote:
On Thursday 15 February 2007 21:10, Brandeburg, Jesse wrote:
Eric W. Biederman wrote:
Len Brown [EMAIL PROTECTED] writes:
e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
System is a D875PBZ with LOM.
clues?
I'm guessing this is an old bug found by the following bit of
debug coded added into since v2.6.20
+#ifdef CONFIG_DEBUG_SHIRQ
+ if (irqflags IRQF_SHARED) {
+ /*
+* It's a shared IRQ -- the driver ought to be
prepared for it +* to happen immediately, so let's
make sure +* We do this before actually
registering it, to make sure that +* a 'real' IRQ
doesn't run in parallel with our fake +*/
+ if (irqflags IRQF_DISABLED) {
+ unsigned long flags;
+
+ local_irq_save(flags);
+ handler(irq, dev_id);
+ local_irq_restore(flags);
+ } else
+ handler(irq, dev_id);
+ }
+#endif
I don't have a clue why the e1000 wasn't ready though.
our code is clearly calling request_irq before we have assigned the
function pointer adapter-clean_rx as well as adapter-alloc_rx_buf
That would be a bug, a possible patch would be (inline and attached):
compile tested, *but* I couldn't test this patch to make sure it worked
because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
disk.
[PATCH] e1000: fix shared interrupt warning message
From: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c
b/drivers/net/e1000/e1000_main.c
index 619c892..b8c4d5c 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1417,10 +1417,6 @@ e1000_open(struct net_device *netdev)
if ((err = e1000_setup_all_rx_resources(adapter)))
goto err_setup_rx;
- err = e1000_request_irq(adapter);
- if (err)
- goto err_req_irq;
-
e1000_power_up_phy(adapter);
if ((err = e1000_up(adapter)))
@@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev)
e1000_update_mng_vlan(adapter);
}
+ err = e1000_request_irq(adapter);
+ if (err)
+ goto err_req_irq;
+
/* If AMT is enabled, let the firmware know that the network
* interface is now open */
if (adapter-hw.mac_type == e1000_82573
@@ -1439,10 +1439,11 @@ e1000_open(struct net_device *netdev)
return E1000_SUCCESS;
+err_req_irq:
+ e1000_down(adapter);
+ e1000_free_irq(adapter);
err_up:
e1000_power_down_phy(adapter);
- e1000_free_irq(adapter);
-err_req_irq:
e1000_free_all_rx_resources(adapter);
err_setup_rx:
e1000_free_all_tx_resources(adapter);
Works for me(tm) on latest 2.6.20-git and D875PBZ.
If there are no objections I'll push this patch to Jeff Garzik together with two
other changes I have for him.
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: e1000_intr in request_irq faults in 2.6.20-git
Andrew Morton wrote: On Thu, 15 Feb 2007 18:10:53 -0800 Brandeburg, Jesse [EMAIL PROTECTED] wrote: @@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev) e1000_update_mng_vlan(adapter); } + err = e1000_request_irq(adapter); + if (err) + goto err_req_irq; + /* If AMT is enabled, let the firmware know that the network * interface is now open */ if (adapter-hw.mac_type == e1000_82573 @@ -1439,10 +1439,11 @@ e1000_open(struct net_device *netdev) return E1000_SUCCESS; +err_req_irq: + e1000_down(adapter); + e1000_free_irq(adapter); err_up: We don't want that e1000_free_irq(adapter) in the error path. indeed, thanks for spotting and telling me before I sent this to Jeff. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] e1000: Use ARRAY_SIZE macro when appropriate
Ahmed S. Darwish wrote:
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
Acked-by: Auke Kok <[EMAIL PROTECTED]>
Cheers,
Auke
---
Patch is compile tested.
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -746,7 +746,7 @@ err_setup:
uint32_t pat, value; \
uint32_t test[] = \
{0x5A5A5A5A, 0xA5A5A5A5, 0x, 0x}; \
- for (pat = 0; pat < sizeof(test)/sizeof(test[0]); pat++) {
\
+ for (pat = 0; pat < ARRAY_SIZE(test); pat++) { \
E1000_WRITE_REG(>hw, R, (test[pat] & W)); \
value = E1000_READ_REG(>hw, R); \
if (value != (test[pat] & W & M)) {
\
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Ahmed S. Darwish wrote:
On Mon, Feb 05, 2007 at 12:31:26PM -0800, Auke Kok wrote:
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option
*opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks, Here's the new patch.
Use ARRAY_SIZE macro when appropriate.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
Acked-by: Auke Kok <[EMAIL PROTECTED]>
Cheers,
Auke
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..c38ce73 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,8 +245,6 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
-
/**
* ixgb_check_options - Range Checking for Command Line Parameters
* @adapter: board private structure
@@ -335,7 +333,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
.name = "Flow Control",
.err = "reading default settings from EEPROM",
.def = ixgb_fc_tx_pause,
- .arg = { .l = { .nr = LIST_LEN(fc_list),
+ .arg = { .l = { .nr = ARRAY_SIZE(fc_list),
.p = fc_list }}
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Ahmed S. Darwish wrote:
On Mon, Feb 05, 2007 at 12:31:26PM -0800, Auke Kok wrote:
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option
*opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks, Here's the new patch.
Use ARRAY_SIZE macro when appropriate.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
Cheers,
Auke
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..c38ce73 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,8 +245,6 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
-
/**
* ixgb_check_options - Range Checking for Command Line Parameters
* @adapter: board private structure
@@ -335,7 +333,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
.name = Flow Control,
.err = reading default settings from EEPROM,
.def = ixgb_fc_tx_pause,
- .arg = { .l = { .nr = LIST_LEN(fc_list),
+ .arg = { .l = { .nr = ARRAY_SIZE(fc_list),
.p = fc_list }}
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] e1000: Use ARRAY_SIZE macro when appropriate
Ahmed S. Darwish wrote:
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
Cheers,
Auke
---
Patch is compile tested.
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -746,7 +746,7 @@ err_setup:
uint32_t pat, value; \
uint32_t test[] = \
{0x5A5A5A5A, 0xA5A5A5A5, 0x, 0x}; \
- for (pat = 0; pat sizeof(test)/sizeof(test[0]); pat++) {
\
+ for (pat = 0; pat ARRAY_SIZE(test); pat++) { \
E1000_WRITE_REG(adapter-hw, R, (test[pat] W)); \
value = E1000_READ_REG(adapter-hw, R); \
if (value != (test[pat] W M)) {
\
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks,
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks,
Auke
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc7: known regressions (v2) (part 1)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I've never had this device work 100% with MSI on any kernel version I've tested so far. But I'm not the original reporter of the problem, and I believe for him it was a true regression where a previous kernel wored correctly. maybe I've been unclear, but here's how e1000 detects link changes: 1) by checking every 2 seconds in the watchdog by reading PHY registers That would explain why I see link status changes but 0 interrupt count in /proc/interrupts. However, on >= 2.6.19 the link state never changes. Ever. It's always down. On <= 2.6.18 the link state does change but with 0 interupt count. 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt control register if the link is down to start with, the watchdog will obviously spot a 'link up' change since it doesn't use any interrupts. This does not seem to work on 2.6.19+. Unless the watchdog interval is tens of minutes. I've waited at least 5 minutes and link never went up. that's explained by a driver change that did that. Since at initialization we're basically waiting for a link change to tell the stack that we're up, we decided to change the order to have the hardware fire an LSI interrupt to trigger a watchdog run. So no interrupts would immediately explain why the watchdog never runs. That's nothing to worry about for this problem, as soon as interrupts are seen in /proc/interrupts this all starts working for e1000. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc7: known regressions (v2) (part 1)
Adam Kropelin wrote: > Eric W. Biederman wrote: >> Auke Kok <[EMAIL PROTECTED]> writes: >>> None of the MSI code in e1000 has changed significantly either. as >>> far as I can see, the msi code in e1000 has not changed since >>> 2.6.18. Nonetheless there's no way I can debug any of this without a >>> system. >>> [...] >>> Perhaps Adam can git-bisect this issue? Adam? >> Do we have any explanation about the weird /proc/interrupts output? >> i.e. Multiple MSI irqs being assigned to the same card? >> >> Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything >> to do with the duplication in /proc/interrupts? >> >> I can't see any way for a pci device that doesn't support msi-x to be >> assigned multiple interrupts simultaneously. >> >> I just skimmed through the code and there hasn't been any significant >> generic MSI work since 2.6.19. >> >> Did this device really work with MSI enabled in 2.6.19? > > I've never had this device work 100% with MSI on any kernel version I've > tested so far. But I'm not the original reporter of the problem, and I > believe for him it was a true regression where a previous kernel wored > correctly. maybe I've been unclear, but here's how e1000 detects link changes: 1) by checking every 2 seconds in the watchdog by reading PHY registers 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt control register if the link is down to start with, the watchdog will obviously spot a 'link up' change since it doesn't use any interrupts. The link interrupt (LSI) is a generic interrupt that comes over the same vector (be it MSI or not) as RX interrupts, and in your case doesn't arrive at all, which should be demonstrateable if you set e.g. the watchdog interval to 30 seconds and unplug the cable - the driver won't spot the link change until the watchdog fires a lot later than you unplugged the cable. > The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status > interrupts seem to work but rx/tx does not. A few more details here: > <http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450_name=linux_kernel> > I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report > back any variations in behavior I notice. that would be a good start, but I still think that you might have a broken bridge on that system. Anyway, thanks for digging into this. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc7: known regressions (v2) (part 1)
Adam Kropelin wrote: Eric W. Biederman wrote: Auke Kok [EMAIL PROTECTED] writes: None of the MSI code in e1000 has changed significantly either. as far as I can see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no way I can debug any of this without a system. [...] Perhaps Adam can git-bisect this issue? Adam? Do we have any explanation about the weird /proc/interrupts output? i.e. Multiple MSI irqs being assigned to the same card? Does /sbin/ifconfig ethN down ; /sbin/ifconfig ethN up have anything to do with the duplication in /proc/interrupts? I can't see any way for a pci device that doesn't support msi-x to be assigned multiple interrupts simultaneously. I just skimmed through the code and there hasn't been any significant generic MSI work since 2.6.19. Did this device really work with MSI enabled in 2.6.19? I've never had this device work 100% with MSI on any kernel version I've tested so far. But I'm not the original reporter of the problem, and I believe for him it was a true regression where a previous kernel wored correctly. maybe I've been unclear, but here's how e1000 detects link changes: 1) by checking every 2 seconds in the watchdog by reading PHY registers 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt control register if the link is down to start with, the watchdog will obviously spot a 'link up' change since it doesn't use any interrupts. The link interrupt (LSI) is a generic interrupt that comes over the same vector (be it MSI or not) as RX interrupts, and in your case doesn't arrive at all, which should be demonstrateable if you set e.g. the watchdog interval to 30 seconds and unplug the cable - the driver won't spot the link change until the watchdog fires a lot later than you unplugged the cable. The behavior I observe on 2.6.19 is better than 2.6.20-rc7. Link status interrupts seem to work but rx/tx does not. A few more details here: http://www.kroptech.com/~adk0212/mailimport/showmsg.php?msg_id=3339092450db_name=linux_kernel I'm going to test 2.6.16 thru 2.6.20-rc7 this weekend and will report back any variations in behavior I notice. that would be a good start, but I still think that you might have a broken bridge on that system. Anyway, thanks for digging into this. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc7: known regressions (v2) (part 1)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I've never had this device work 100% with MSI on any kernel version I've tested so far. But I'm not the original reporter of the problem, and I believe for him it was a true regression where a previous kernel wored correctly. maybe I've been unclear, but here's how e1000 detects link changes: 1) by checking every 2 seconds in the watchdog by reading PHY registers That would explain why I see link status changes but 0 interrupt count in /proc/interrupts. However, on = 2.6.19 the link state never changes. Ever. It's always down. On = 2.6.18 the link state does change but with 0 interupt count. 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt control register if the link is down to start with, the watchdog will obviously spot a 'link up' change since it doesn't use any interrupts. This does not seem to work on 2.6.19+. Unless the watchdog interval is tens of minutes. I've waited at least 5 minutes and link never went up. that's explained by a driver change that did that. Since at initialization we're basically waiting for a link change to tell the stack that we're up, we decided to change the order to have the hardware fire an LSI interrupt to trigger a watchdog run. So no interrupts would immediately explain why the watchdog never runs. That's nothing to worry about for this problem, as soon as interrupts are seen in /proc/interrupts this all starts working for e1000. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc7: known regressions (v2) (part 1)
Adrian Bunk wrote: This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Subject: e1000: 82571EB/82572EI PCI-E cards: link is always down (MSI related) References : http://lkml.org/lkml/2007/1/16/27 http://lkml.org/lkml/2007/1/17/182 Submitter : Allen Parker <[EMAIL PROTECTED]> Adam Kropelin <[EMAIL PROTECTED]> Handled-By : Auke Kok <[EMAIL PROTECTED]> Status : problem is being debugged I probably can't fix this bug. Not only do I doubt that the e1000 driver is at fault here, I don't have a system with this particular chipset. Most likely the regression comes from a combination of MSI layer rewrites and possibly platform issues. We've seen many reports that are similar and all are on the platform type mentioned here. I really don't want to point fingers here either. None of the MSI code in e1000 has changed significantly either. as far as I can see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no way I can debug any of this without a system. I will address the fact that we are lacking any of these systems to test on, but that is not going to get this issue handled (not to mention soon) in the way it needs to be. I strongly encourage the people on the linux-pci list to help out, I'll trace the e1000 driver for suspicious activity (again), but I run countless tests on the latest trees and nothing has shown up recently, other than Eric Biederman's msi irq reclaim leak fix. Perhaps Adam can git-bisect this issue? Adam? Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
Adrian Bunk wrote: On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote: (cc: list trimmed and thread moved to linux-pci) I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that the PHY state is correct, it's just that the interrupt is not getting thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok with MSI enabled (link status responds appropriately) but packet tx fails with timeout errors, implying that perhaps MAC interrupts are not arriving. I've attached the contents dmesg, 'lspci -vvv', and 'cat /proc/interrupts' from 2.6.20-rc5. This is an nForce 430 based chipset on a Dell E521 which has had interrupt routing issues before. Prior to 2.6.19 it had to be booted with 'noapic' in order to come up at all. It also had USB lockup problems until I applied the latest BIOS update (v1.1.4). So a BIOS interrupt routing bug with MSI is not out of the question. I'm happy to gather more data or run tests... Was this regression fixed by Eric's patch that is included in -rc7? no, this is a different issue afaics. Eric's patch solves a msi vector leak where MSI's were no longer recovered after all 256 of them were handed out. The issue here seems to be a very different regression (no vector at all or vector not setup correctly to begin with). I do suggest re-testing the issue with 2.6.20rc7, but it's unlikely it fixes the problem for Adam. The same issue was reported 2/3 days ago by another user basically too (no interrupts at all arriving with MSI enabled). Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MSI failure on nForce 430 (WAS: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression))
Adrian Bunk wrote: On Sat, Jan 20, 2007 at 02:34:37PM -0500, Adam Kropelin wrote: (cc: list trimmed and thread moved to linux-pci) I have a PCI-E e1000 card that does not see interrupts on 2.6.20-rc5 unless CONFIG_PCI_MSI is disabled. An e1000 maintainer indicated that the PHY state is correct, it's just that the interrupt is not getting thru to the kernel. Interestingly, on 2.6.19 PHY interrupts get thru ok with MSI enabled (link status responds appropriately) but packet tx fails with timeout errors, implying that perhaps MAC interrupts are not arriving. I've attached the contents dmesg, 'lspci -vvv', and 'cat /proc/interrupts' from 2.6.20-rc5. This is an nForce 430 based chipset on a Dell E521 which has had interrupt routing issues before. Prior to 2.6.19 it had to be booted with 'noapic' in order to come up at all. It also had USB lockup problems until I applied the latest BIOS update (v1.1.4). So a BIOS interrupt routing bug with MSI is not out of the question. I'm happy to gather more data or run tests... Was this regression fixed by Eric's patch that is included in -rc7? no, this is a different issue afaics. Eric's patch solves a msi vector leak where MSI's were no longer recovered after all 256 of them were handed out. The issue here seems to be a very different regression (no vector at all or vector not setup correctly to begin with). I do suggest re-testing the issue with 2.6.20rc7, but it's unlikely it fixes the problem for Adam. The same issue was reported 2/3 days ago by another user basically too (no interrupts at all arriving with MSI enabled). Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc7: known regressions (v2) (part 1)
Adrian Bunk wrote: This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Subject: e1000: 82571EB/82572EI PCI-E cards: link is always down (MSI related) References : http://lkml.org/lkml/2007/1/16/27 http://lkml.org/lkml/2007/1/17/182 Submitter : Allen Parker [EMAIL PROTECTED] Adam Kropelin [EMAIL PROTECTED] Handled-By : Auke Kok [EMAIL PROTECTED] Status : problem is being debugged I probably can't fix this bug. Not only do I doubt that the e1000 driver is at fault here, I don't have a system with this particular chipset. Most likely the regression comes from a combination of MSI layer rewrites and possibly platform issues. We've seen many reports that are similar and all are on the platform type mentioned here. I really don't want to point fingers here either. None of the MSI code in e1000 has changed significantly either. as far as I can see, the msi code in e1000 has not changed since 2.6.18. Nonetheless there's no way I can debug any of this without a system. I will address the fact that we are lacking any of these systems to test on, but that is not going to get this issue handled (not to mention soon) in the way it needs to be. I strongly encourage the people on the linux-pci list to help out, I'll trace the e1000 driver for suspicious activity (again), but I run countless tests on the latest trees and nothing has shown up recently, other than Eric Biederman's msi irq reclaim leak fix. Perhaps Adam can git-bisect this issue? Adam? Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Ban module license tag string termination trick
Trent Waddington wrote: On 2/2/07, Jon Masters <[EMAIL PROTECTED]> wrote: Ok. I totally dig the *idea* here - I mean, this issue has been ongoing for a long time now. But I'd like to see a few comments as to whether we need a technological mechanism here to enforce the obvious. To me, it just seems totally obvious (any legal comment?) that early C string termination is undermining the intent of the MODULE_LICENSE tag. I'm not a lawyer, but I can tell you exactly what a lawyer would say: "well, ya know, it's hard to say when it comes to these issues" that's the answer to *any* copyright question. :) to me it even screams "bypassing or a digital copyright enforcement system". that sounds really close to "D.M.C.A. violation" :) thank goodness I'm not a laywer... Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Ban module license tag string termination trick
Trent Waddington wrote: On 2/2/07, Jon Masters [EMAIL PROTECTED] wrote: Ok. I totally dig the *idea* here - I mean, this issue has been ongoing for a long time now. But I'd like to see a few comments as to whether we need a technological mechanism here to enforce the obvious. To me, it just seems totally obvious (any legal comment?) that early C string termination is undermining the intent of the MODULE_LICENSE tag. I'm not a lawyer, but I can tell you exactly what a lawyer would say: well, ya know, it's hard to say when it comes to these issues that's the answer to *any* copyright question. :) to me it even screams bypassing or a digital copyright enforcement system. that sounds really close to D.M.C.A. violation :) thank goodness I'm not a laywer... Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Francois Romieu wrote: Nicolas Mailhot <[EMAIL PROTECTED]> : [...] incomplete NDAed documentation. If (as this offer implies) there are good driver authors waiting to do more drivering, why aren't those a priority? So far nobody cared enough to maintain a list of said out-of-tree drivers. why not post this on the OSDL driver wiki [1]? There already is a list of 'binary kernel drivers'. It would seem a proper addition there. Cheers, Auke [1] http://developer.osdl.org/dev/opendrivers/wiki/index.php/Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unidentified Intel wifi network card
Scott Lockwood wrote: I'm looking for assistance with a wifi device I can't find a driver for, the Intel Wireless 3945. I"m getting this: :0c:00.0 Network controller: Intel Corporation: Unknown device 4222 (rev 02) on a new Dell Latitude D820. Anyone know if there will be an open source driver for this any time soon, or if there is one now? I'm using the latest vendor supplied kernel, so my apologies if this has already been done and I'm late to the party. I wasn't able to find much, other than 'use the NDIS wrapper' which I really don't want to do. http://ipw3945.sourceforge.net/ Cheers, Auke PS google for '3945 driver linux' also showed this as #1 hit: http://www.google.com/search?q=3945+driver+linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unidentified Intel wifi network card
Scott Lockwood wrote: I'm looking for assistance with a wifi device I can't find a driver for, the Intel Wireless 3945. Im getting this: :0c:00.0 Network controller: Intel Corporation: Unknown device 4222 (rev 02) on a new Dell Latitude D820. Anyone know if there will be an open source driver for this any time soon, or if there is one now? I'm using the latest vendor supplied kernel, so my apologies if this has already been done and I'm late to the party. I wasn't able to find much, other than 'use the NDIS wrapper' which I really don't want to do. http://ipw3945.sourceforge.net/ Cheers, Auke PS google for '3945 driver linux' also showed this as #1 hit: http://www.google.com/search?q=3945+driver+linux - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
Francois Romieu wrote: Nicolas Mailhot [EMAIL PROTECTED] : [...] incomplete NDAed documentation. If (as this offer implies) there are good driver authors waiting to do more drivering, why aren't those a priority? So far nobody cared enough to maintain a list of said out-of-tree drivers. why not post this on the OSDL driver wiki [1]? There already is a list of 'binary kernel drivers'. It would seem a proper addition there. Cheers, Auke [1] http://developer.osdl.org/dev/opendrivers/wiki/index.php/Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
[snip]
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the
moment. Perhaps Eric Biederman can help?
Does this patch fix it for you? It looks like i386 vector allocate
did not have logic to look through the set of vectors more than once.
Yes. A few hundred cycles of loading/unloading snd_hda_intel with enable_msi=1
didn't break it on i386.
I sure hope this can get into 2.6.20!
Auke
The code in this patch is a simplified version of what we have
on x86_64.
Eric
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 2424cc9..6a3875f 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -1227,26 +1227,32 @@ static u8 irq_vector[NR_IRQ_VECTORS] __read_mostly = {
FIRST_DEVICE_VECTOR , 0 }
static int __assign_irq_vector(int irq)
{
- static int current_vector = FIRST_DEVICE_VECTOR, offset = 0;
- int vector;
+ static int current_vector = FIRST_DEVICE_VECTOR, current_offset = 0;
+ int vector, offset, i;
BUG_ON((unsigned)irq >= NR_IRQ_VECTORS);
if (irq_vector[irq] > 0)
return irq_vector[irq];
- current_vector += 8;
- if (current_vector == SYSCALL_VECTOR)
- current_vector += 8;
-
- if (current_vector >= FIRST_SYSTEM_VECTOR) {
- offset++;
- if (!(offset % 8))
- return -ENOSPC;
- current_vector = FIRST_DEVICE_VECTOR + offset;
- }
-
vector = current_vector;
+ offset = current_offset;
+next:
+ vector += 8;
+ if (vector >= FIRST_SYSTEM_VECTOR) {
+ offset = (offset + 1) % 8;
+ vector = FIRST_DEVICE_VECTOR + offset;
+ }
+ if (vector == current_vector)
+ return -ENOSPC;
+ if (vector == SYSCALL_VECTOR)
+ goto next;
+ for (i = 0; i < NR_IRQ_VECTORS; i++)
+ if (irq_vector[i] == vector)
+ goto next;
+
+ current_vector = vector;
+ current_offset = offset;
irq_vector[irq] = vector;
return vector;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote:
Auke Kok [EMAIL PROTECTED] writes:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
[snip]
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the
moment. Perhaps Eric Biederman can help?
Does this patch fix it for you? It looks like i386 vector allocate
did not have logic to look through the set of vectors more than once.
Yes. A few hundred cycles of loading/unloading snd_hda_intel with enable_msi=1
didn't break it on i386.
I sure hope this can get into 2.6.20!
Auke
The code in this patch is a simplified version of what we have
on x86_64.
Eric
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 2424cc9..6a3875f 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -1227,26 +1227,32 @@ static u8 irq_vector[NR_IRQ_VECTORS] __read_mostly = {
FIRST_DEVICE_VECTOR , 0 }
static int __assign_irq_vector(int irq)
{
- static int current_vector = FIRST_DEVICE_VECTOR, offset = 0;
- int vector;
+ static int current_vector = FIRST_DEVICE_VECTOR, current_offset = 0;
+ int vector, offset, i;
BUG_ON((unsigned)irq = NR_IRQ_VECTORS);
if (irq_vector[irq] 0)
return irq_vector[irq];
- current_vector += 8;
- if (current_vector == SYSCALL_VECTOR)
- current_vector += 8;
-
- if (current_vector = FIRST_SYSTEM_VECTOR) {
- offset++;
- if (!(offset % 8))
- return -ENOSPC;
- current_vector = FIRST_DEVICE_VECTOR + offset;
- }
-
vector = current_vector;
+ offset = current_offset;
+next:
+ vector += 8;
+ if (vector = FIRST_SYSTEM_VECTOR) {
+ offset = (offset + 1) % 8;
+ vector = FIRST_DEVICE_VECTOR + offset;
+ }
+ if (vector == current_vector)
+ return -ENOSPC;
+ if (vector == SYSCALL_VECTOR)
+ goto next;
+ for (i = 0; i NR_IRQ_VECTORS; i++)
+ if (irq_vector[i] == vector)
+ goto next;
+
+ current_vector = vector;
+ current_offset = offset;
irq_vector[irq] = vector;
return vector;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -MM]: updated e1000 - new hardware initialization code (replacement patch)
Andrew, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-mm to receive an updated version of the new e1000 hardware initialization code. This version incorporates both previously sent patches and replaces them, as well as adding some minor extra kdoc headers. The patch applies cleanly against jgarzik's netdev-2.6 #upstream commit 5ad0d383ddbf0d2fce43b8aac267a6c299fd2dff. the patch is also available in monolithic form over http: http://foo-projects.org/~sofar/e1000_git_new_device_init_code.patch.bz2 (166kb) or http://foo-projects.org/~sofar/e1000_git_new_device_init_code.patch (1.2mb) Cheers, Auke --- e1000: New device initialization code, fixes From: Jeb Cramer <[EMAIL PROTECTED]> This rewrite of the hardware initialization code splits up the driver low-level initialization code per chipset family. Several families exist with different initialization code per chipset, revision, and this allows us later to select only enable certain devices in the driver. The current code enables all previous drivers and thus doesn't change anything to the user, but is radically different internally. Mac and phy layers are also split, and everything is grouped in an API layer that the driver uses to interface the hardware. Support was added for a PCI-e 4-port Fibre version of the PRO/1000 PT quad port adapter (device 0x10a5). MTU changes on a downed interface require a phy commit to enact the new size immediately. Replace hard coded RAR numbers with constant. Add several function description and fix some small copy+paste errors in others. Fix link speed detection on PCI adapters showing wrong PCI bus speed. Fix laa detection. Rewrite tbi static for 82543. Fix mta list overflow. Don't unmap skb's twice in occasions, but set dma=0. Flatten dhcp generic function for readability. Change force phy speed duplex setup to be void and static. Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Bruce Allan <[EMAIL PROTECTED]> Signed-off-by: Jeb Cramer <[EMAIL PROTECTED]> Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 97 drivers/net/e1000/e1000_80003es2lan.c | 1377 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 670 ++ drivers/net/e1000/e1000_82541.c | 1305 + drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 551 ++ drivers/net/e1000/e1000_82543.c | 1643 ++ drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1127 drivers/net/e1000/e1000_82571.h | 42 drivers/net/e1000/e1000_api.c | 1174 drivers/net/e1000/e1000_api.h | 161 + drivers/net/e1000/e1000_defines.h | 1297 + drivers/net/e1000/e1000_ethtool.c | 470 +- drivers/net/e1000/e1000_hw.c | 9038 - drivers/net/e1000/e1000_hw.h | 3859 ++ drivers/net/e1000/e1000_ich8lan.c | 2427 + drivers/net/e1000/e1000_ich8lan.h | 110 drivers/net/e1000/e1000_mac.c | 1939 +++ drivers/net/e1000/e1000_mac.h | 84 drivers/net/e1000/e1000_main.c| 936 ++- drivers/net/e1000/e1000_manage.c | 388 + drivers/net/e1000/e1000_manage.h | 83 drivers/net/e1000/e1000_nvm.c | 859 +++ drivers/net/e1000/e1000_nvm.h | 61 drivers/net/e1000/e1000_osdep.h | 57 drivers/net/e1000/e1000_param.c | 100 drivers/net/e1000/e1000_phy.c | 1932 +++ drivers/net/e1000/e1000_phy.h | 159 + drivers/net/e1000/e1000_regs.h| 236 + 32 files changed, 19321 insertions(+), 13100 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote: Auke Kok <[EMAIL PROTECTED]> writes: I highly doubt it - I've seen the problem even on this weeks git on x86_64. Moreover, I'm at home for the weekend and testing resources are limited :). I'll see what I can do Thanks. There may be more to it than what I suspect, but I could not reproduce it on x86_64. Now I may have missed something as I optimized my tested based on the fact that close and open are triggered when you up and down a network interface. so I didn't do a complete rmmod, (since my network driver wasn't modular). Since you have seen this on x86_64 I will look deeper. gah, strike that. my only x86_64 system here survived the test with latest git tree. my 386 system here has no msi devices and I can't reinstall my x86_64 system since it's headless, so I can't test anything until monday. I'll give it a full test again and see which 2.6.20rc kernels did fail, most likely a much older tree (I suspect). Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 "Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector" and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c "Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips" the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter->pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the
moment. Perhaps Eric Biederman can help?
Does this patch fix it for you? It looks like i386 vector allocate
did not have logic to look through the set of vectors more than once.
The code in this patch is a simplified version of what we have
on x86_64.
I highly doubt it - I've seen the problem even on this weeks git on x86_64.
Moreover, I'm at home for the weekend and testing resources are limited :). I'll
see what I can do
Auke
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote:
Auke Kok [EMAIL PROTECTED] writes:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter-pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the
moment. Perhaps Eric Biederman can help?
Does this patch fix it for you? It looks like i386 vector allocate
did not have logic to look through the set of vectors more than once.
The code in this patch is a simplified version of what we have
on x86_64.
I highly doubt it - I've seen the problem even on this weeks git on x86_64.
Moreover, I'm at home for the weekend and testing resources are limited :). I'll
see what I can do
Auke
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Eric W. Biederman wrote: Auke Kok [EMAIL PROTECTED] writes: I highly doubt it - I've seen the problem even on this weeks git on x86_64. Moreover, I'm at home for the weekend and testing resources are limited :). I'll see what I can do Thanks. There may be more to it than what I suspect, but I could not reproduce it on x86_64. Now I may have missed something as I optimized my tested based on the fact that close and open are triggered when you up and down a network interface. so I didn't do a complete rmmod, (since my network driver wasn't modular). Since you have seen this on x86_64 I will look deeper. gah, strike that. my only x86_64 system here survived the test with latest git tree. my 386 system here has no msi devices and I can't reinstall my x86_64 system since it's headless, so I can't test anything until monday. I'll give it a full test again and see which 2.6.20rc kernels did fail, most likely a much older tree (I suspect). Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -MM]: updated e1000 - new hardware initialization code (replacement patch)
Andrew, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-mm to receive an updated version of the new e1000 hardware initialization code. This version incorporates both previously sent patches and replaces them, as well as adding some minor extra kdoc headers. The patch applies cleanly against jgarzik's netdev-2.6 #upstream commit 5ad0d383ddbf0d2fce43b8aac267a6c299fd2dff. the patch is also available in monolithic form over http: http://foo-projects.org/~sofar/e1000_git_new_device_init_code.patch.bz2 (166kb) or http://foo-projects.org/~sofar/e1000_git_new_device_init_code.patch (1.2mb) Cheers, Auke --- e1000: New device initialization code, fixes From: Jeb Cramer [EMAIL PROTECTED] This rewrite of the hardware initialization code splits up the driver low-level initialization code per chipset family. Several families exist with different initialization code per chipset, revision, and this allows us later to select only enable certain devices in the driver. The current code enables all previous drivers and thus doesn't change anything to the user, but is radically different internally. Mac and phy layers are also split, and everything is grouped in an API layer that the driver uses to interface the hardware. Support was added for a PCI-e 4-port Fibre version of the PRO/1000 PT quad port adapter (device 0x10a5). MTU changes on a downed interface require a phy commit to enact the new size immediately. Replace hard coded RAR numbers with constant. Add several function description and fix some small copy+paste errors in others. Fix link speed detection on PCI adapters showing wrong PCI bus speed. Fix laa detection. Rewrite tbi static for 82543. Fix mta list overflow. Don't unmap skb's twice in occasions, but set dma=0. Flatten dhcp generic function for readability. Change force phy speed duplex setup to be void and static. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 97 drivers/net/e1000/e1000_80003es2lan.c | 1377 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 670 ++ drivers/net/e1000/e1000_82541.c | 1305 + drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 551 ++ drivers/net/e1000/e1000_82543.c | 1643 ++ drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1127 drivers/net/e1000/e1000_82571.h | 42 drivers/net/e1000/e1000_api.c | 1174 drivers/net/e1000/e1000_api.h | 161 + drivers/net/e1000/e1000_defines.h | 1297 + drivers/net/e1000/e1000_ethtool.c | 470 +- drivers/net/e1000/e1000_hw.c | 9038 - drivers/net/e1000/e1000_hw.h | 3859 ++ drivers/net/e1000/e1000_ich8lan.c | 2427 + drivers/net/e1000/e1000_ich8lan.h | 110 drivers/net/e1000/e1000_mac.c | 1939 +++ drivers/net/e1000/e1000_mac.h | 84 drivers/net/e1000/e1000_main.c| 936 ++- drivers/net/e1000/e1000_manage.c | 388 + drivers/net/e1000/e1000_manage.h | 83 drivers/net/e1000/e1000_nvm.c | 859 +++ drivers/net/e1000/e1000_nvm.h | 61 drivers/net/e1000/e1000_osdep.h | 57 drivers/net/e1000/e1000_param.c | 100 drivers/net/e1000/e1000_phy.c | 1932 +++ drivers/net/e1000/e1000_phy.h | 159 + drivers/net/e1000/e1000_regs.h| 236 + 32 files changed, 19321 insertions(+), 13100 deletions(-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Auke Kok wrote:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 "Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector" and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c "Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips" the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter->pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the moment.
Perhaps Eric Biederman can help?
PS PS
The exact same problem exists when doing "for n in `seq 1 300` ; do modprobe
snd_hda_intel enable_msi ; rmmod snd_hda_intel ; done".
I'm sure it will show up for other msi enabled devices.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 "Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector" and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c "Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips" the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter->pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the moment.
Perhaps Eric Biederman can help?
Cheers,
Auke
---
PS After the msi enable fails, things go horribly wrong (of course...) if we
still try to disable+enable more new msi interrupts, but this may just be the
e1000 driver cleanup missing something. perhaps it's relevant:
e1000: :04:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7f
e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
ACPI: PCI interrupt for device :04:00.1 disabled
ACPI: PCI interrupt for device :04:00.0 disabled
ACPI: PCI interrupt for device :03:00.1 disabled
ACPI: PCI interrupt for device :03:00.0 disabled
ACPI: PCI interrupt for device :00:19.0 disabled
Intel(R) PRO/1000 Network Driver - version 7.2.9-k4-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt :00:19.0[A] -> GSI 20 (level, low) -> IRQ 23
PCI: Setting latency timer of device :00:19.0 to 64
e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 88:88:88:88:87:
88
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device :03:00.0 to 64
e1000: :03:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7c
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :03:00.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :03:00.1 to 64
e1000: :03:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7d
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device :04:00.0 to 64
e1000: :04:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7e
e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :04:00.1[B] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device :04:00.1 to 64
e1000: :04:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7f
e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
irq 214: nobody cared (try booting with the "irqpoll" option)
[] __report_bad_irq+0x2a/0x90
[] note_interrupt+0xaf/0xe0
[] handle_edge_irq+0xd3/0x160
[] do_IRQ+0x68/0xd0
[] common_interrupt+0x1a/0x20
[] snapshot_write_next+0x5b/0x220
[] __do_softirq+0x62/0x100
[] do_softirq+0x35/0x40
[] irq_exit+0x45/0x50
[] do_IRQ+0x6d/0xd0
[] common_interrupt+0x1a/0x20
===
handlers:
[] (e1000_intr+0x0/0x110 [e1000])
Disabling IRQ #214
ACPI: PCI interrupt for device :04:00.1 disabled
ACPI: PCI interrupt for device :04:00.0 disabled
ACPI: PCI interrupt for device :03:00.1 disabled
irq 214, desc: c05cc120, depth: 1, count: 0, unhandled: 0
->handle_irq(): c015a050, handle_bad_irq+0x0/0x380
->chip(): c05453c0, 0xc05453c0
->action():
IRQ_DISABLED set
IRQ_PENDING set
IRQ_MASKED set
unexpected IRQ trap at vector d6
irq 214, desc: c05cc120,
Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter-pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the moment.
Perhaps Eric Biederman can help?
Cheers,
Auke
---
PS After the msi enable fails, things go horribly wrong (of course...) if we
still try to disable+enable more new msi interrupts, but this may just be the
e1000 driver cleanup missing something. perhaps it's relevant:
e1000: :04:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7f
e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
ACPI: PCI interrupt for device :04:00.1 disabled
ACPI: PCI interrupt for device :04:00.0 disabled
ACPI: PCI interrupt for device :03:00.1 disabled
ACPI: PCI interrupt for device :03:00.0 disabled
ACPI: PCI interrupt for device :00:19.0 disabled
Intel(R) PRO/1000 Network Driver - version 7.2.9-k4-NAPI
Copyright (c) 1999-2006 Intel Corporation.
ACPI: PCI Interrupt :00:19.0[A] - GSI 20 (level, low) - IRQ 23
PCI: Setting latency timer of device :00:19.0 to 64
e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 88:88:88:88:87:
88
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :03:00.0[A] - GSI 16 (level, low) - IRQ 16
PCI: Setting latency timer of device :03:00.0 to 64
e1000: :03:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7c
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :03:00.1[B] - GSI 17 (level, low) - IRQ 17
PCI: Setting latency timer of device :03:00.1 to 64
e1000: :03:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7d
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :04:00.0[A] - GSI 17 (level, low) - IRQ 17
PCI: Setting latency timer of device :04:00.0 to 64
e1000: :04:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7e
e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection
ACPI: PCI Interrupt :04:00.1[B] - GSI 18 (level, low) - IRQ 18
PCI: Setting latency timer of device :04:00.1 to 64
e1000: :04:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:0c:0c:7f
e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
irq 214: nobody cared (try booting with the irqpoll option)
[c015b25a] __report_bad_irq+0x2a/0x90
[c015b38f] note_interrupt+0xaf/0xe0
[c015bcf3] handle_edge_irq+0xd3/0x160
[c0105dd8] do_IRQ+0x68/0xd0
[c0103e0a] common_interrupt+0x1a/0x20
[c015007b] snapshot_write_next+0x5b/0x220
[c012e862] __do_softirq+0x62/0x100
[c012e935] do_softirq+0x35/0x40
[c012e985] irq_exit+0x45/0x50
[c0105ddd] do_IRQ+0x6d/0xd0
[c0103e0a] common_interrupt+0x1a/0x20
===
handlers:
[f89df160] (e1000_intr+0x0/0x110 [e1000])
Disabling IRQ #214
ACPI: PCI interrupt for device :04:00.1 disabled
ACPI: PCI interrupt for device :04:00.0 disabled
ACPI: PCI interrupt for device :03:00.1 disabled
irq 214, desc: c05cc120, depth: 1, count: 0, unhandled: 0
-handle_irq(): c015a050, handle_bad_irq+0x0/0x380
-chip(): c05453c0, 0xc05453c0
-action():
IRQ_DISABLED set
IRQ_PENDING set
Re: Possible regression: MSI vector leakage since 2.6.18-rc5ish (Unable to repeatedly allocate/free MSI interrupt)
Auke Kok wrote:
Hi,
I've established a regression in the MSI vector/irq allocation routine for both
i386 and x86_64. Our test labs repeatedly modprobe/rmmod the e1000 driver for
serveral minutes which allocates msi vectors and frees them. These tests have
been running fine until 2.6.19.
git-bisecting I've established that in between commit
04b9267b15206fc902a18de1f78de6c82ca47716 Eric W. Biederman -- genirq: x86_64
irq: Remove the msi assumption that irq == vector and commit
f29bd1ba68c8c6a0f50bd678bbd5a26674018f7c Ingo Molnar -- genirq: convert the
x86_64 architecture to irq-chips the behaviour broke.
The revisions in between seem to be dependent and give all sorts of other
issues, so it's rather hard for me to bisect that and give trustworthy results.
the e1000 driver hits the 256-mark cycle (I think - it consistently refuses to
do 500 msi irq/vector allocations which is my test case) and throws:
e1000: eth4: e1000_request_irq: Unable to allocate MSI interrupt Error: -16
which is caused by a `if ((err = pci_enable_msi(adapter-pdev))) {` call from
the e1000 driver. It's rather easy to hit this mark with the new 4-port e1000
adapters :).
as for the e1000 code, I can say that even our oldest msi-enabled e1000 driver
works fine with 2.6.18 and under. All kernels from 2.6.19 fail consistently.
I mostly suspect commit 7bd007e480672c99d8656c7b7b12ef0549432c37 at the moment.
Perhaps Eric Biederman can help?
PS PS
The exact same problem exists when doing for n in `seq 1 300` ; do modprobe
snd_hda_intel enable_msi ; rmmod snd_hda_intel ; done.
I'm sure it will show up for other msi enabled devices.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Nvidia MCP55 Machine reboots on ixgb driver load
[added netdev to CC] Roger Heflin wrote: I have a machine (actually 2 machines) that upon loading the intel 10GBe driver (ixgb) the machine reboots, I am using a RHAS4.4 based distribution with Vanilla 2.6.19.2 (the RHAS 4.4.03 kernel also reboots with the ixgb load), I don't see any messages on the machine before it reboots, loading the driver with debug does not appear to produce any extra messages. The basic steps are the I load the driver, the machine locks up, and then in a second or 2 it starts to post. some suggestions immediately come to mind: * have you tried the latest driver from http://e1000.sf.net/ ? * what happens when you unplug the card and modprobe the ixgb module? * have you tried capturing a trace with netconsole or serial console? probing the ixgb driver produces at least 1 syslog line that should show up. If nothing shows up on serial or netconsole, the issue may be way outside the ixgb driver. I have tried the default ixgb driver in 2.6.19.2, and I have tried the open source intel driver on RH4.4, both cause the same reboot.I also tried the linux firmware development kit, and booting fc6 causes the same reboot upon the network driver load. just for completeness, which driver versions were this? and when you say "booting fc6" I assume you mean that fc6 boots OK until you modprobe the ixgb driver? I have tried pci=nomsi try compiling your kernel without MSI support alltogether. There have been serious issues found with MSI on certain configurations, and in your case this might be the cause. Allthough passing pci=nomsi should be the same as compiling it out, it can't hurt to try. Also note that the [EMAIL PROTECTED] address is apparently unused and returns an email telling you to use a web page, and so far after using the web page I have not got any response indicating that anything got to anyone. I've taken action to get that straightened out. You're always welcome to mail netdev, the e1000 devel list or even lkml which we will all pick up on. I can't think of a specific reason for the issue right now, other than attempting to get a serial/netconsole attached and trying without any msi support in the kernel. Please give that a try and let us know. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Nvidia MCP55 Machine reboots on ixgb driver load
[added netdev to CC] Roger Heflin wrote: I have a machine (actually 2 machines) that upon loading the intel 10GBe driver (ixgb) the machine reboots, I am using a RHAS4.4 based distribution with Vanilla 2.6.19.2 (the RHAS 4.4.03 kernel also reboots with the ixgb load), I don't see any messages on the machine before it reboots, loading the driver with debug does not appear to produce any extra messages. The basic steps are the I load the driver, the machine locks up, and then in a second or 2 it starts to post. some suggestions immediately come to mind: * have you tried the latest driver from http://e1000.sf.net/ ? * what happens when you unplug the card and modprobe the ixgb module? * have you tried capturing a trace with netconsole or serial console? probing the ixgb driver produces at least 1 syslog line that should show up. If nothing shows up on serial or netconsole, the issue may be way outside the ixgb driver. I have tried the default ixgb driver in 2.6.19.2, and I have tried the open source intel driver on RH4.4, both cause the same reboot.I also tried the linux firmware development kit, and booting fc6 causes the same reboot upon the network driver load. just for completeness, which driver versions were this? and when you say booting fc6 I assume you mean that fc6 boots OK until you modprobe the ixgb driver? I have tried pci=nomsi try compiling your kernel without MSI support alltogether. There have been serious issues found with MSI on certain configurations, and in your case this might be the cause. Allthough passing pci=nomsi should be the same as compiling it out, it can't hurt to try. Also note that the [EMAIL PROTECTED] address is apparently unused and returns an email telling you to use a web page, and so far after using the web page I have not got any response indicating that anything got to anyone. I've taken action to get that straightened out. You're always welcome to mail netdev, the e1000 devel list or even lkml which we will all pick up on. I can't think of a specific reason for the issue right now, other than attempting to get a serial/netconsole attached and trying without any msi support in the kernel. Please give that a try and let us know. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] e100: eth0 appers many times in /proc/interrupts after resume
Frederik Deweerdt wrote: On Sun, Jan 21, 2007 at 01:45:27PM -0800, Auke Kok wrote: Frederik Deweerdt wrote: On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote: It's the 10th resume and in /proc/interrupts eth0 appers 10 times. The e100_resume() function should be calling netif_device_detach and free_irq. Could you try the following (compile tested) patch? I just fixed suspend/shutdown for e100 in 2.6.19, not sure why the problem still shows up. Since it's a driver/net issue, you should CC netdev on it tho, otherwise it might go unnoticed. Thanks for adding the CC I'll open up the can-o-worms on this issue and see what's up with it. I'm not so sure that this patch is OK, and I wonder why it stopped working, because I spent quite some time fixing it only a few months ago. Did swsup change again? sigh... I may well be wrong (It appears that most of the time I am :)), but the unbalanced netif_device_attach (in resume) looks suspicious. resume() also calls request_irq, so calling free_irq on suspend seemed logical. I just tested the patch and looked it over again. The patch works good and indeed fixes the problem, and netconsole works great. It even shows much of the suspend/resume over the wire, something which I can't remember seeing before with netconsole. reboot -f also works OK. I'll push the patch upstream, thanks! Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
Jeff Garzik wrote: Auke Kok wrote: Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. I did pull the tree. The fixes were far more than just obvious one-liners, so they got pulled into #upstream. Forgive me for not seeing the 'pulled' message! I still don't see them in your tree on kernel.org either. Is it just slow again? Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] net driver fixes
Jeff Garzik wrote: Auke Kok wrote: Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. I did pull the tree. The fixes were far more than just obvious one-liners, so they got pulled into #upstream. Forgive me for not seeing the 'pulled' message! I still don't see them in your tree on kernel.org either. Is it just slow again? Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] e100: eth0 appers many times in /proc/interrupts after resume
Frederik Deweerdt wrote: On Sun, Jan 21, 2007 at 01:45:27PM -0800, Auke Kok wrote: Frederik Deweerdt wrote: On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote: It's the 10th resume and in /proc/interrupts eth0 appers 10 times. The e100_resume() function should be calling netif_device_detach and free_irq. Could you try the following (compile tested) patch? I just fixed suspend/shutdown for e100 in 2.6.19, not sure why the problem still shows up. Since it's a driver/net issue, you should CC netdev on it tho, otherwise it might go unnoticed. Thanks for adding the CC I'll open up the can-o-worms on this issue and see what's up with it. I'm not so sure that this patch is OK, and I wonder why it stopped working, because I spent quite some time fixing it only a few months ago. Did swsup change again? sigh... I may well be wrong (It appears that most of the time I am :)), but the unbalanced netif_device_attach (in resume) looks suspicious. resume() also calls request_irq, so calling free_irq on suspend seemed logical. I just tested the patch and looked it over again. The patch works good and indeed fixes the problem, and netconsole works great. It even shows much of the suspend/resume over the wire, something which I can't remember seeing before with netconsole. reboot -f also works OK. I'll push the patch upstream, thanks! Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] e100: eth0 appers many times in /proc/interrupts after resume
Frederik Deweerdt wrote:
On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote:
It's the 10th resume and in /proc/interrupts eth0 appers 10 times.
The e100_resume() function should be calling netif_device_detach and
free_irq. Could you try the following (compile tested) patch?
I just fixed suspend/shutdown for e100 in 2.6.19, not sure why the problem still
shows up. Since it's a driver/net issue, you should CC netdev on it tho,
otherwise it might go unnoticed.
I'll open up the can-o-worms on this issue and see what's up with it.
I'm not so sure that this patch is OK, and I wonder why it stopped working,
because I spent quite some time fixing it only a few months ago. Did swsup
change again? sigh...
Auke
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 2fe0445..0c376e4 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2671,6 +2671,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
del_timer_sync(>watchdog);
netif_carrier_off(nic->netdev);
+ netif_device_detach(netdev);
pci_save_state(pdev);
if ((nic->flags & wol_magic) | e100_asf(nic)) {
@@ -2682,6 +2683,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
}
pci_disable_device(pdev);
+ free_irq(pdev->irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] e100: eth0 appers many times in /proc/interrupts after resume
Frederik Deweerdt wrote:
On Sun, Jan 21, 2007 at 09:17:41PM +0200, Andrei Popa wrote:
It's the 10th resume and in /proc/interrupts eth0 appers 10 times.
The e100_resume() function should be calling netif_device_detach and
free_irq. Could you try the following (compile tested) patch?
I just fixed suspend/shutdown for e100 in 2.6.19, not sure why the problem still
shows up. Since it's a driver/net issue, you should CC netdev on it tho,
otherwise it might go unnoticed.
I'll open up the can-o-worms on this issue and see what's up with it.
I'm not so sure that this patch is OK, and I wonder why it stopped working,
because I spent quite some time fixing it only a few months ago. Did swsup
change again? sigh...
Auke
Signed-off-by: Frederik Deweerdt [EMAIL PROTECTED]
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 2fe0445..0c376e4 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2671,6 +2671,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
del_timer_sync(nic-watchdog);
netif_carrier_off(nic-netdev);
+ netif_device_detach(netdev);
pci_save_state(pdev);
if ((nic-flags wol_magic) | e100_asf(nic)) {
@@ -2682,6 +2683,7 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
}
pci_disable_device(pdev);
+ free_irq(pdev-irq, netdev);
pci_set_power_state(pdev, PCI_D3hot);
return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), I thought that's what I was doing when I applied git-e1000 to 2.6.20-rc5, but I guess not. or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. I'll try to work something out. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. ethtool output attached. that clearly shows that the PHY detected link up status and that all is well as far as the driver and NIC is concerned. This bug really needs to be moved to linux-pci where the folks who know interrupt handling best can handle it. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On 2.6.19 the link status is working (follows cable plug/unplug), but no tx or rx packets get thru. Attempts to transmit occasionally result in tx timed out errors in dmesg, but I cannot seem to generate these at will. On 2.6.20-rc5, the link status does not work (link is always down), and as expected no tx or rx. No tx timed out errors this time, presumably because it thinks the link is down. Note that both the switch and the LEDs on the NIC indicate a good 1000 Mbps link. dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. The data from 2.6.19 is essentially the same. at least your interrupts look sane. I see you are using MSI, but no interrupts arrive at neither OS nor driver. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. More importantly, I suspect that *again* the issue is caused by interrupts not arriving or getting lost. Can you try running with MSI disabled in your kernel config? FYI the driver gives an interrupt to signal to the driver that link is up. no interrupt == no link detected. So that explains the symptom. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On 2.6.19 the link status is working (follows cable plug/unplug), but no tx or rx packets get thru. Attempts to transmit occasionally result in tx timed out errors in dmesg, but I cannot seem to generate these at will. On 2.6.20-rc5, the link status does not work (link is always down), and as expected no tx or rx. No tx timed out errors this time, presumably because it thinks the link is down. Note that both the switch and the LEDs on the NIC indicate a good 1000 Mbps link. dmesg, 'cat /proc/interrupts', and 'lspci -vvv' attached for 2.6.20-rc5. The data from 2.6.19 is essentially the same. at least your interrupts look sane. I see you are using MSI, but no interrupts arrive at neither OS nor driver. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. More importantly, I suspect that *again* the issue is caused by interrupts not arriving or getting lost. Can you try running with MSI disabled in your kernel config? FYI the driver gives an interrupt to signal to the driver that link is up. no interrupt == no link detected. So that explains the symptom. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Auke Kok wrote: Adam Kropelin wrote: I haven't been able to test rc5-mm yet because it won't boot on this box. Applying git-e1000 directly to -rc4 or -rc5 results in a number of rejects that I'm not sure how to fix. Some are obvious, but the others I'm unsure of. that won't work. You either need to start with 2.6.20-rc5 (and pull the changes pending merge in netdev-2.6 from Jeff Garzik), I thought that's what I was doing when I applied git-e1000 to 2.6.20-rc5, but I guess not. or start with 2.6.20-rc4-mm1 and manually apply that patch I sent out on monday. A different combination of either of these two will not work, as they are completely different drivers. I'll try to work something out. can you include `ethtool ethX` output of the link down message and `ethtool -d ethX` as well? I'll need to dig up an 82572 and see what's up with that, I've not seen that problem before. ethtool output attached. that clearly shows that the PHY detected link up status and that all is well as far as the driver and NIC is concerned. This bug really needs to be moved to linux-pci where the folks who know interrupt handling best can handle it. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.20-rc4-mm1: Panic in e1000_write_vfta_82543()
Sukadev Bhattiprolu wrote: I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system. Same basic config file seems to work with 2.6.20-rc2-mm1 on this same system. Have not tried -rc3-mm1 yet. Attached are config file and "lspci -vv" output. Let me know if you need more info. Suka --- [ 168.925840] Freeing unused kernel memory: 320k freed * INIT: version 2.86 booting * Starting basic networking... [ ok ] * Starting kernel event manager... [ ok ] * Loading hardware drivers... [ ok ] * Starting PCMCIA services... * PCMCIA not present * Loading manual drivers... [ ok ] [ 171.575122] Unable to handle kernel paging request at c20100ec55fc RIP: [ 171.584632] [] e1000_write_vfta_82543+0x58/0xd0 [ 171.614833] PGD 114e067 PUD 0 [ 171.633943] Oops: [1] PREEMPT SMP [ 171.654614] last sysfs file: /devices/pci:00/:00:06.0/:01:06.0/host0/target0:0:0/0:0:0:0/rev [ 171.698158] CPU 1 [ 171.698161] Modules linked in: [ 171.698164] Pid: 2173, comm: ifconfig Not tainted 2.6.20-rc4-mm1 #1 * Checking root[ 171.698166] RIP: 0010:[] [] e1000_write_vfta_82543+0x58/0xd0 file system...[ 171.698171] RSP: 0018:81007dfc5cf8 EFLAGS: 00010286 [ 171.698174] RAX: c20100ec55fc RBX: 81003e4c8948 RCX: /dev/shm/root: clean, 662056/2443200 files, 3121107/4883752 bloc[ 171.698176] RDX: RSI: RDI: 81003e4c8948 ks [ ok ] [ 171.698178] RBP: R08: 0010 R09: [ 171.698181] R10: 0002 R11: 804a9800 R12: c2ec [ 171.698183] R13: fffc R14: R15: 81003e4c8000 * Setting up LVM Volume Groups...[ 171.698186] FS: 2ab17ce3f6d0() GS:81007f0b0bc0() knlGS: [ 171.698188] CS: 0010 DS: ES: CR0: 8005003b [ 171.698191] CR2: c20100ec55fc CR3: 7d828000 CR4: 06e0 [ 171.698194] Process ifconfig (pid: 2173, threadinfo 81007dfc4000, task 81007dd957e0) [ 171.698196] Stack: 8000 81003e4c8680 c2ec 81003e4c8000 [ 171.698202] 7fff2dfba960 804c103d 81003e4c8680 [ 171.698205] 81003e4c8680 804c3195 [ 171.698208] Call Trace: [ 171.698216] [] e1000_vlan_rx_register+0x1dd/0x210 [ 171.698219] [] e1000_up+0x35/0x4b0 [ 171.698222] [] e1000_open+0x74/0x100 [ 171.698227] [] dev_open+0x3e/0xa0 [ 171.698230] [] dev_change_flags+0x6f/0x160 [ 171.698234] [] devinet_ioctl+0x2d4/0x6e0 [ 171.698238] [] __up_read+0x21/0xb0 [ 171.698243] [] sock_ioctl+0x1fc/0x230 [ 171.698247] [] do_ioctl+0x2f/0xa0 [ 171.698249] [] vfs_ioctl+0x2bb/0x2f0 [ 171.698252] [] sys_ioctl+0x49/0x80 [ 171.698256] [] error_exit+0x0/0x84 [ 171.698259] [] system_call+0x7e/0x83 [ 171.698261] [ 171.698262] [ 171.698262] Code: 44 8b 20 e8 30 7e 00 00 83 bb 94 01 00 00 03 75 3c 83 e5 01 [ 171.698268] RIP [] e1000_write_vfta_82543+0x58/0xd0 [ 171.698273] RSP [ 171.698274] CR2: c20100ec55fc [ 171.698276] <6>EXT3 FS on sda1, internal journal Hi, I believe this is one of the bugs that is fixed in the patch that I sent monday. Please try again with the patch applied to your tree and re-test. Thanks. I didn't see Andrew merge the patch yet. see: http://lkml.org/lkml/2007/1/16/226 I can mail the patch if you can't find it. Just ping me privately. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.20-rc4-mm1: Panic in e1000_write_vfta_82543()
Sukadev Bhattiprolu wrote: I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system. Same basic config file seems to work with 2.6.20-rc2-mm1 on this same system. Have not tried -rc3-mm1 yet. Attached are config file and lspci -vv output. Let me know if you need more info. Suka --- [ 168.925840] Freeing unused kernel memory: 320k freed * INIT: version 2.86 booting * Starting basic networking... [ ok ] * Starting kernel event manager... [ ok ] * Loading hardware drivers... [ ok ] * Starting PCMCIA services... * PCMCIA not present * Loading manual drivers... [ ok ] [ 171.575122] Unable to handle kernel paging request at c20100ec55fc RIP: [ 171.584632] [804a9858] e1000_write_vfta_82543+0x58/0xd0 [ 171.614833] PGD 114e067 PUD 0 [ 171.633943] Oops: [1] PREEMPT SMP [ 171.654614] last sysfs file: /devices/pci:00/:00:06.0/:01:06.0/host0/target0:0:0/0:0:0:0/rev [ 171.698158] CPU 1 [ 171.698161] Modules linked in: [ 171.698164] Pid: 2173, comm: ifconfig Not tainted 2.6.20-rc4-mm1 #1 * Checking root[ 171.698166] RIP: 0010:[804a9858] [804a9858] e1000_write_vfta_82543+0x58/0xd0 file system...[ 171.698171] RSP: 0018:81007dfc5cf8 EFLAGS: 00010286 [ 171.698174] RAX: c20100ec55fc RBX: 81003e4c8948 RCX: /dev/shm/root: clean, 662056/2443200 files, 3121107/4883752 bloc[ 171.698176] RDX: RSI: RDI: 81003e4c8948 ks [ ok ] [ 171.698178] RBP: R08: 0010 R09: [ 171.698181] R10: 0002 R11: 804a9800 R12: c2ec [ 171.698183] R13: fffc R14: R15: 81003e4c8000 * Setting up LVM Volume Groups...[ 171.698186] FS: 2ab17ce3f6d0() GS:81007f0b0bc0() knlGS: [ 171.698188] CS: 0010 DS: ES: CR0: 8005003b [ 171.698191] CR2: c20100ec55fc CR3: 7d828000 CR4: 06e0 [ 171.698194] Process ifconfig (pid: 2173, threadinfo 81007dfc4000, task 81007dd957e0) [ 171.698196] Stack: 8000 81003e4c8680 c2ec 81003e4c8000 [ 171.698202] 7fff2dfba960 804c103d 81003e4c8680 [ 171.698205] 81003e4c8680 804c3195 [ 171.698208] Call Trace: [ 171.698216] [804c103d] e1000_vlan_rx_register+0x1dd/0x210 [ 171.698219] [804c3195] e1000_up+0x35/0x4b0 [ 171.698222] [804c3724] e1000_open+0x74/0x100 [ 171.698227] [805626fe] dev_open+0x3e/0xa0 [ 171.698230] [8056184f] dev_change_flags+0x6f/0x160 [ 171.698234] [805a5174] devinet_ioctl+0x2d4/0x6e0 [ 171.698238] [803f7e01] __up_read+0x21/0xb0 [ 171.698243] [8055664c] sock_ioctl+0x1fc/0x230 [ 171.698247] [8029dc0f] do_ioctl+0x2f/0xa0 [ 171.698249] [8029df3b] vfs_ioctl+0x2bb/0x2f0 [ 171.698252] [8029dfb9] sys_ioctl+0x49/0x80 [ 171.698256] [805e375d] error_exit+0x0/0x84 [ 171.698259] [802098be] system_call+0x7e/0x83 [ 171.698261] [ 171.698262] [ 171.698262] Code: 44 8b 20 e8 30 7e 00 00 83 bb 94 01 00 00 03 75 3c 83 e5 01 [ 171.698268] RIP [804a9858] e1000_write_vfta_82543+0x58/0xd0 [ 171.698273] RSP 81007dfc5cf8 [ 171.698274] CR2: c20100ec55fc [ 171.698276] 6EXT3 FS on sda1, internal journal Hi, I believe this is one of the bugs that is fixed in the patch that I sent monday. Please try again with the patch applied to your tree and re-test. Thanks. I didn't see Andrew merge the patch yet. see: http://lkml.org/lkml/2007/1/16/226 I can mail the patch if you can't find it. Just ping me privately. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Allen Parker wrote: Allen Parker wrote: From what I've been able to gather, other Intel Pro/1000 chipsets work fine in 2.6.20-rc5. If the e1000 guys need any assistance testing, I'll be more than happy to volunteer myself as a guinea pig for patches. I wasn't aware that I was supposed to post this as a regression, so changed the subject, hoping that someone will pick this up and run with it. Primary issue being that link is not seen on this chipset under 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig $eth up && ethtool $eth | grep link && ifconfig $eth down. Tested on 2 machines with identical hardware. I asked Allen to report this here. I'm working on the issue as we speak but for now I'll treat the link issue as a known regression once I confirm it. If others have seen it then I'd like to know ASAP of course I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Adam Kropelin wrote: Allen Parker wrote: Allen Parker wrote: From what I've been able to gather, other Intel Pro/1000 chipsets work fine in 2.6.20-rc5. If the e1000 guys need any assistance testing, I'll be more than happy to volunteer myself as a guinea pig for patches. I wasn't aware that I was supposed to post this as a regression, so changed the subject, hoping that someone will pick this up and run with it. Primary issue being that link is not seen on this chipset under 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig $eth up ethtool $eth | grep link ifconfig $eth down. Tested on 2 machines with identical hardware. I asked Allen to report this here. I'm working on the issue as we speak but for now I'll treat the link issue as a known regression once I confirm it. If others have seen it then I'd like to know ASAP of course I am experiencing the no-link issue on a 82572EI single port copper PCI-E card. I've only tried 2.6.20-rc5, so I cannot tell if this is a regression or not yet. Will test older kernel soon. Can provide details/logs if you want 'em. we've already established that Allen's issue is not due to the driver and caused by interrupts being mal-assigned on his system, possibly a pci subsystem bug. You also have a completely different board (82572EI instead of 82571EB), so I'd like to see the usual debugging info as well as hearing from you whether 2.6.19.any works correctly. On top of that I posted a patch to rc5-mm yesterday that fixes a few significant bugs in the rc5-mm driver, so please apply that patch too before trying, so we're not wasting our time finding old bugs ;) Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -MM] e1000: update new hardware init layer code with bugfixes
e1000: update new hardware init layer code with bugfixes
From: Jeb Cramer <[EMAIL PROTECTED]>
Replace hard coded RAR numbers with constant. Add several function description
and fix some small copy+paste errors in others. Fix link speed detection on
PCI adapters showing wrong PCI bus speed. Fix laa detection. Rewrite tbi static
for 82543. Fix mta list overflow. Don't unmap skb's twice in occasions, but set
dma=0. Flatten dhcp generic function for readability. Change force phy speed
duplex setup to be void and static.
Depends on git-e1000.patch as present in 2.6.20-rc4-mm1.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jeb Cramer <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_80003es2lan.c | 90 -
drivers/net/e1000/e1000_82540.c | 86 ++--
drivers/net/e1000/e1000_82541.c |6 +-
drivers/net/e1000/e1000_82542.c |6 +-
drivers/net/e1000/e1000_82543.c | 44 +---
drivers/net/e1000/e1000_82571.c | 19 +++
drivers/net/e1000/e1000_api.h |1
drivers/net/e1000/e1000_defines.h |8 +++
drivers/net/e1000/e1000_ich8lan.c | 21 +---
drivers/net/e1000/e1000_ich8lan.h |2 +
drivers/net/e1000/e1000_mac.c |5 ++
drivers/net/e1000/e1000_main.c| 31 ---
drivers/net/e1000/e1000_manage.c | 39 +++---
drivers/net/e1000/e1000_nvm.c |3 -
drivers/net/e1000/e1000_osdep.h |2 -
drivers/net/e1000/e1000_phy.c | 58 +++--
drivers/net/e1000/e1000_phy.h | 64 ---
17 files changed, 316 insertions(+), 169 deletions(-)
diff --git a/drivers/net/e1000/e1000_80003es2lan.c
b/drivers/net/e1000/e1000_80003es2lan.c
index ef5e250..9a89c26 100644
--- a/drivers/net/e1000/e1000_80003es2lan.c
+++ b/drivers/net/e1000/e1000_80003es2lan.c
@@ -131,7 +131,7 @@ out:
}
/**
- * e1000_init_phy_params_80003es2lan - Init ESB2 NVM func ptrs.
+ * e1000_init_nvm_params_80003es2lan - Init ESB2 NVM func ptrs.
* @hw - pointer to the HW structure
*
* This is a function pointer entry point called by the api module.
@@ -187,7 +187,7 @@ e1000_init_nvm_params_80003es2lan(struct e1000_hw *hw)
}
/**
- * e1000_init_phy_params_80003es2lan - Init ESB2 MAC func ptrs.
+ * e1000_init_mac_params_80003es2lan - Init ESB2 MAC func ptrs.
* @hw - pointer to the HW structure
*
* This is a function pointer entry point called by the api module.
@@ -214,7 +214,7 @@ e1000_init_mac_params_80003es2lan(struct e1000_hw *hw)
/* Set mta register count */
mac->mta_reg_count = 128;
/* Set rar entry count */
- mac->rar_entry_count = 16;
+ mac->rar_entry_count = E1000_RAR_ENTRIES;
/* Set if part includes ASF firmware */
mac->asf_firmware_present = TRUE;
/* Set if manageability features are enabled. */
@@ -535,29 +535,48 @@ e1000_read_phy_reg_gg82563_80003es2lan(struct e1000_hw
*hw, u32 offset,
u16 *data)
{
s32 ret_val;
+ u32 page_select;
+ u16 temp;
DEBUGFUNC("e1000_read_phy_reg_gg82563_80003es2lan");
/* Select Configuration Page */
- if ((offset & MAX_PHY_REG_ADDRESS) < GG82563_MIN_ALT_REG) {
- ret_val = e1000_write_phy_reg_m88(hw, GG82563_PHY_PAGE_SELECT,
- (u16)((u16)offset >> GG82563_PAGE_SHIFT));
- } else {
+ if ((offset & MAX_PHY_REG_ADDRESS) < GG82563_MIN_ALT_REG)
+ page_select = GG82563_PHY_PAGE_SELECT;
+ else {
/* Use Alternative Page Select register to access
* registers 30 and 31
*/
- ret_val = e1000_write_phy_reg_m88(hw,
- GG82563_PHY_PAGE_SELECT_ALT,
- (u16)((u16)offset >> GG82563_PAGE_SHIFT));
+ page_select = GG82563_PHY_PAGE_SELECT_ALT;
}
+ temp = (u16)((u16)offset >> GG82563_PAGE_SHIFT);
+ ret_val = e1000_write_phy_reg_m88(hw, page_select, temp);
if (ret_val)
goto out;
+ /* The "ready" bit in the MDIC register may be incorrectly set
+* before the device has completed the "Page Select" MDI
+* transaction. So we wait 200us after each MDI command...
+*/
+ udelay(200);
+
+ /* ...and verify the command was successful. */
+ ret_val = e1000_read_phy_reg_m88(hw, page_select, );
+
+ if (((u16)offset >> GG82563_PAGE_SHIFT) != temp) {
+ ret_val = -E1000_ERR_PHY;
+ goto out;
+ }
+
+ udelay(200);
+
ret_val = e1000_read_phy_reg_m88(hw,
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Allen Parker wrote: Allen Parker wrote: I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier today I reported this to [EMAIL PROTECTED], but thought I should get the word out in case someone else is testing this kernel on this nic chipset. Due to changes between 2.6.19.2 and 2.6.20, Intel driver 7.3.20 will not compile for 2.6.20, nor will the 2.6.19.2 in-tree driver. Affected chipset: lspci -nn output (quad port): 09:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:10a4] (rev 06) lspci -nn output (dual port): 07:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] (rev 06) From what I've been able to gather, other Intel Pro/1000 chipsets work fine in 2.6.20-rc5. If the e1000 guys need any assistance testing, I'll be more than happy to volunteer myself as a guinea pig for patches. I wasn't aware that I was supposed to post this as a regression, so changed the subject, hoping that someone will pick this up and run with it. Primary issue being that link is not seen on this chipset under 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig $eth up && ethtool $eth | grep link && ifconfig $eth down. Tested on 2 machines with identical hardware. I asked Allen to report this here. I'm working on the issue as we speak but for now I'll treat the link issue as a known regression once I confirm it. If others have seen it then I'd like to know ASAP of course ;) Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel 82571EB gigabit fails to see link on 2.6.20-rc5 in-tree e1000 driver (regression)
Allen Parker wrote: Allen Parker wrote: I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier today I reported this to [EMAIL PROTECTED], but thought I should get the word out in case someone else is testing this kernel on this nic chipset. Due to changes between 2.6.19.2 and 2.6.20, Intel driver 7.3.20 will not compile for 2.6.20, nor will the 2.6.19.2 in-tree driver. snip, worthless Affected chipset: lspci -nn output (quad port): 09:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:10a4] (rev 06) lspci -nn output (dual port): 07:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] (rev 06) snip, readability From what I've been able to gather, other Intel Pro/1000 chipsets work fine in 2.6.20-rc5. If the e1000 guys need any assistance testing, I'll be more than happy to volunteer myself as a guinea pig for patches. I wasn't aware that I was supposed to post this as a regression, so changed the subject, hoping that someone will pick this up and run with it. Primary issue being that link is not seen on this chipset under 2.6.20-rc5 via in-tree e1000 driver, despite multiple cycles of ifconfig $eth up ethtool $eth | grep link ifconfig $eth down. Tested on 2 machines with identical hardware. I asked Allen to report this here. I'm working on the issue as we speak but for now I'll treat the link issue as a known regression once I confirm it. If others have seen it then I'd like to know ASAP of course ;) Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -MM] e1000: update new hardware init layer code with bugfixes
e1000: update new hardware init layer code with bugfixes
From: Jeb Cramer [EMAIL PROTECTED]
Replace hard coded RAR numbers with constant. Add several function description
and fix some small copy+paste errors in others. Fix link speed detection on
PCI adapters showing wrong PCI bus speed. Fix laa detection. Rewrite tbi static
for 82543. Fix mta list overflow. Don't unmap skb's twice in occasions, but set
dma=0. Flatten dhcp generic function for readability. Change force phy speed
duplex setup to be void and static.
Depends on git-e1000.patch as present in 2.6.20-rc4-mm1.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_80003es2lan.c | 90 -
drivers/net/e1000/e1000_82540.c | 86 ++--
drivers/net/e1000/e1000_82541.c |6 +-
drivers/net/e1000/e1000_82542.c |6 +-
drivers/net/e1000/e1000_82543.c | 44 +---
drivers/net/e1000/e1000_82571.c | 19 +++
drivers/net/e1000/e1000_api.h |1
drivers/net/e1000/e1000_defines.h |8 +++
drivers/net/e1000/e1000_ich8lan.c | 21 +---
drivers/net/e1000/e1000_ich8lan.h |2 +
drivers/net/e1000/e1000_mac.c |5 ++
drivers/net/e1000/e1000_main.c| 31 ---
drivers/net/e1000/e1000_manage.c | 39 +++---
drivers/net/e1000/e1000_nvm.c |3 -
drivers/net/e1000/e1000_osdep.h |2 -
drivers/net/e1000/e1000_phy.c | 58 +++--
drivers/net/e1000/e1000_phy.h | 64 ---
17 files changed, 316 insertions(+), 169 deletions(-)
diff --git a/drivers/net/e1000/e1000_80003es2lan.c
b/drivers/net/e1000/e1000_80003es2lan.c
index ef5e250..9a89c26 100644
--- a/drivers/net/e1000/e1000_80003es2lan.c
+++ b/drivers/net/e1000/e1000_80003es2lan.c
@@ -131,7 +131,7 @@ out:
}
/**
- * e1000_init_phy_params_80003es2lan - Init ESB2 NVM func ptrs.
+ * e1000_init_nvm_params_80003es2lan - Init ESB2 NVM func ptrs.
* @hw - pointer to the HW structure
*
* This is a function pointer entry point called by the api module.
@@ -187,7 +187,7 @@ e1000_init_nvm_params_80003es2lan(struct e1000_hw *hw)
}
/**
- * e1000_init_phy_params_80003es2lan - Init ESB2 MAC func ptrs.
+ * e1000_init_mac_params_80003es2lan - Init ESB2 MAC func ptrs.
* @hw - pointer to the HW structure
*
* This is a function pointer entry point called by the api module.
@@ -214,7 +214,7 @@ e1000_init_mac_params_80003es2lan(struct e1000_hw *hw)
/* Set mta register count */
mac-mta_reg_count = 128;
/* Set rar entry count */
- mac-rar_entry_count = 16;
+ mac-rar_entry_count = E1000_RAR_ENTRIES;
/* Set if part includes ASF firmware */
mac-asf_firmware_present = TRUE;
/* Set if manageability features are enabled. */
@@ -535,29 +535,48 @@ e1000_read_phy_reg_gg82563_80003es2lan(struct e1000_hw
*hw, u32 offset,
u16 *data)
{
s32 ret_val;
+ u32 page_select;
+ u16 temp;
DEBUGFUNC(e1000_read_phy_reg_gg82563_80003es2lan);
/* Select Configuration Page */
- if ((offset MAX_PHY_REG_ADDRESS) GG82563_MIN_ALT_REG) {
- ret_val = e1000_write_phy_reg_m88(hw, GG82563_PHY_PAGE_SELECT,
- (u16)((u16)offset GG82563_PAGE_SHIFT));
- } else {
+ if ((offset MAX_PHY_REG_ADDRESS) GG82563_MIN_ALT_REG)
+ page_select = GG82563_PHY_PAGE_SELECT;
+ else {
/* Use Alternative Page Select register to access
* registers 30 and 31
*/
- ret_val = e1000_write_phy_reg_m88(hw,
- GG82563_PHY_PAGE_SELECT_ALT,
- (u16)((u16)offset GG82563_PAGE_SHIFT));
+ page_select = GG82563_PHY_PAGE_SELECT_ALT;
}
+ temp = (u16)((u16)offset GG82563_PAGE_SHIFT);
+ ret_val = e1000_write_phy_reg_m88(hw, page_select, temp);
if (ret_val)
goto out;
+ /* The ready bit in the MDIC register may be incorrectly set
+* before the device has completed the Page Select MDI
+* transaction. So we wait 200us after each MDI command...
+*/
+ udelay(200);
+
+ /* ...and verify the command was successful. */
+ ret_val = e1000_read_phy_reg_m88(hw, page_select, temp);
+
+ if (((u16)offset GG82563_PAGE_SHIFT) != temp) {
+ ret_val = -E1000_ERR_PHY;
+ goto out;
+ }
+
+ udelay(200);
+
ret_val = e1000_read_phy_reg_m88(hw,
MAX_PHY_REG_ADDRESS offset,
data);
+ udelay(200
Re: [E1000-devel] e1000 : link down issues
[EMAIL PROTECTED] wrote: Hi, I got a 82566DM e1000 network controller [1] on my motherboard, and most of the time the link go down when doing dhcp. [2] ifconfig eth0 up -> link become up dhclient eth0 -> some packet are transmited and received and the link become down. I'm unsure whether we saw this problem before or not but it does sound familiar. First I would like to ask you to check your motherboards vendor website for a possible BIOS update for your motherboard. The 82566DM chipsets are rather new and we have pushed out NVM changes to vendors for some known issues. I sometimes got e1000_reset: Hardware Error. This happen with vanilla 2.6.19 and e1000-7.3.20 drivers. This is very anoying because I should do rmmod e1000; modprobe e1000; ifup e1000 in loop until the link stay up. I try forcing speed, duplex and flow control, but > nothing solve my issue. The device is working fine on windows. unfortunately that doesn't say that much. I do know that we are queueing some ich8/82566 changes for the kernel and if you're willing to try them I can provide patch to the kernel netdev tree to you (it was posted here 3 days ago) to try. Cheers, Auke PS feel free to trim lkml from the CC to move this discussion further to e1000-devel list only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 : link down issues
[EMAIL PROTECTED] wrote: Hi, I got a 82566DM e1000 network controller [1] on my motherboard, and most of the time the link go down when doing dhcp. [2] ifconfig eth0 up - link become up dhclient eth0 - some packet are transmited and received and the link become down. I'm unsure whether we saw this problem before or not but it does sound familiar. First I would like to ask you to check your motherboards vendor website for a possible BIOS update for your motherboard. The 82566DM chipsets are rather new and we have pushed out NVM changes to vendors for some known issues. I sometimes got e1000_reset: Hardware Error. This happen with vanilla 2.6.19 and e1000-7.3.20 drivers. This is very anoying because I should do rmmod e1000; modprobe e1000; ifup e1000 in loop until the link stay up. I try forcing speed, duplex and flow control, but nothing solve my issue. The device is working fine on windows. unfortunately that doesn't say that much. I do know that we are queueing some ich8/82566 changes for the kernel and if you're willing to try them I can provide patch to the kernel netdev tree to you (it was posted here 3 days ago) to try. Cheers, Auke PS feel free to trim lkml from the CC to move this discussion further to e1000-devel list only. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Sami Farin wrote: On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote: Sami Farin wrote: ... I do "ethtool -K eth0 tso off" now and check if I get the hang again. =) I'm unsure whether v7.2.x already automatically disables TSO for 100mbit speed link, probably not. It should. It disabled it but I enabled it just for fun. Please try our updated driver from http://e1000.sf.net/ (7.3.20) against the same kernel. There are some changes with regard to the ich8/TSO driver that might affect this, so re-testing is worth it for us. I now run 7.3.20-NAPI. BTW. the Makefile is buggy: it does not get CC from kernel's Makefile. Using wrong compiler can cause for example a reboot when loading the module. (At least that's what happened with gcc-2.95.3 vs 3.x.x some years ago...) I'll look into that, do you have any suggestions? also, please always include the full dmesg output. Feel free to CC [EMAIL PROTECTED] on this. I enabled TSO again. I write again if TSO causes problems. There are known problems with that configuration, that's why the newer drivers disable TSO for 10/100 speeds. do you really think that you can see the performance gain fro musing TSO at those speeds anyway? we don't ;). In any case you should keep TSO off for 10/100 speeds. Why shouldn't it work with 100 Mbps? Not that it would help a lot, but I ask this on principle. /* disable TSO for pcie and 10/100 speeds, to avoid * some hardware issues */ Issues on the motherboard or the NIC? we (the e1000 team) don't write drivers for the motherboard, but only for the NIC component, so I hope that answers your question. 2007-01-10 02:39:51.889908500 <6>ACPI: PCI interrupt for device :00:19.0 disabled 2007-01-10 02:39:54.545194500 <6>Intel(R) PRO/1000 Network Driver - version 7.3.20-NAPI 2007-01-10 02:39:54.545198500 <6>Copyright (c) 1999-2006 Intel Corporation. 2007-01-10 02:39:54.545395500 <6>ACPI: PCI Interrupt :00:19.0[A] -> GSI 20 (level, low) -> IRQ 22 2007-01-10 02:39:54.545435500 <7>PCI: Setting latency timer of device :00:19.0 to 64 2007-01-10 02:39:54.562905500 <6>e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:19:d1:00:5f:01 2007-01-10 02:39:54.638093500 <6>e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection 2007-01-10 02:40:07.513619500 <6>ADDRCONF(NETDEV_UP): eth0: link is not ready 2007-01-10 02:40:07.614768500 <6>e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:07.614770500 <6>e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO 2007-01-10 02:40:07.614771500 <6>ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 2007-01-10 02:40:09.271631500 <3>e1000: eth0: e1000_reset: Hardware Error 2007-01-10 02:40:10.93500 <6>e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:10.930049500 <6>e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO PS. please do not delete Mail-Followup-To header field. I hit "reply-all" and I have no control over which field thunderbird removes or adds. I have to manually add your e-mail address too? Maybe your mail client is broken instead? Don't you want to receive replies? Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Sami Farin wrote: Linux 2.6.19.1 SMP on Pentium D, Intel DQ965GF mobo. Got this while bittorrenting knoppix: 2007-01-09 22:53:40.020693500 <4>NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=83.46.5.76 DST=80.223.106.128 LEN=121 TOS=0x00 PREC=0x00 TTL=112 ID=53273 PROTO=ICMP TYPE=3 CODE=3 [SRC=80.223.106.128 DST=192.168.1.37 LEN=93 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=UDP SPT=6881 DPT=6895 LEN=73 ] 2007-01-09 22:53:41.660249500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:41.660253500 <4> Tx Queue <0> 2007-01-09 22:53:41.660254500 <4> TDH <3c> 2007-01-09 22:53:41.660255500 <4> TDT 2007-01-09 22:53:41.660255500 <4> next_to_use 2007-01-09 22:53:41.660256500 <4> next_to_clean<3c> 2007-01-09 22:53:41.660257500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:41.660258500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:41.660259500 <4> next_to_watch<3f> 2007-01-09 22:53:41.660274500 <4> jiffies <8c3bf13> 2007-01-09 22:53:41.660275500 <4> next_to_watch.status <0> 2007-01-09 22:53:42.660365500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:42.660368500 <4> Tx Queue <0> 2007-01-09 22:53:42.660369500 <4> TDH <3c> 2007-01-09 22:53:42.660370500 <4> TDT 2007-01-09 22:53:42.660370500 <4> next_to_use 2007-01-09 22:53:42.660371500 <4> next_to_clean<3c> 2007-01-09 22:53:42.660372500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:42.660373500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:42.660374500 <4> next_to_watch<3f> 2007-01-09 22:53:42.660389500 <4> jiffies <8c3c2fb> 2007-01-09 22:53:42.660390500 <4> next_to_watch.status <0> 2007-01-09 22:53:43.660086500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:43.660089500 <4> Tx Queue <0> 2007-01-09 22:53:43.660090500 <4> TDH <3c> 2007-01-09 22:53:43.660091500 <4> TDT 2007-01-09 22:53:43.660092500 <4> next_to_use 2007-01-09 22:53:43.660093500 <4> next_to_clean<3c> 2007-01-09 22:53:43.660093500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:43.660094500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:43.660095500 <4> next_to_watch<3f> 2007-01-09 22:53:43.660110500 <4> jiffies <8c3c6e3> 2007-01-09 22:53:43.660111500 <4> next_to_watch.status <0> 2007-01-09 22:53:44.660001500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:44.660004500 <4> Tx Queue <0> 2007-01-09 22:53:44.660005500 <4> TDH <3c> 2007-01-09 22:53:44.660006500 <4> TDT 2007-01-09 22:53:44.660007500 <4> next_to_use 2007-01-09 22:53:44.660008500 <4> next_to_clean<3c> 2007-01-09 22:53:44.660009500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:44.660009500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:44.660010500 <4> next_to_watch<3f> 2007-01-09 22:53:44.660026500 <4> jiffies <8c3cacb> 2007-01-09 22:53:44.660027500 <4> next_to_watch.status <0> 2007-01-09 22:53:45.659906500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:45.659909500 <4> Tx Queue <0> 2007-01-09 22:53:45.659909500 <4> TDH <3c> 2007-01-09 22:53:45.659910500 <4> TDT 2007-01-09 22:53:45.659911500 <4> next_to_use 2007-01-09 22:53:45.659912500 <4> next_to_clean<3c> 2007-01-09 22:53:45.659913500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:45.659914500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:45.659915500 <4> next_to_watch<3f> 2007-01-09 22:53:45.659930500 <4> jiffies <8c3ceb3> 2007-01-09 22:53:45.659931500 <4> next_to_watch.status <0> 2007-01-09 22:53:46.659784500 <3>e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:46.659787500 <4> Tx Queue <0> 2007-01-09 22:53:46.659788500 <4> TDH <3c> 2007-01-09 22:53:46.659788500 <4> TDT 2007-01-09 22:53:46.659789500 <4> next_to_use 2007-01-09 22:53:46.659790500 <4> next_to_clean<3c> 2007-01-09 22:53:46.659791500 <4>buffer_info[next_to_clean] 2007-01-09 22:53:46.659792500 <4> time_stamp <8c3b8e4> 2007-01-09 22:53:46.659793500 <4> next_to_watch<3f> 2007-01-09 22:53:46.659807500 <4> jiffies <8c3d29b> 2007-01-09 22:53:46.659808500 <4> next_to_watch.status <0> 2007-01-09 22:53:47.130361500 <6>NETDEV WATCHDOG: eth0: transmit timed out 2007-01-09 22:53:48.771500500 <6>e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex 2007-01-09 22:53:54.838031500 <4>NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=84.49.68.15 DST=80.223.106.128 LEN=56 TOS=0x00 PREC=0x00 TTL=142 ID=55046 PROTO=ICMP
Re: + git-netdev-all-e1000-fix.patch added to -mm tree
[EMAIL PROTECTED] wrote: The patch titled git-netdev-all: e1000 fix has been added to the -mm tree. Its filename is git-netdev-all-e1000-fix.patch See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find out what to do about this -- Subject: git-netdev-all: e1000 fix From: Andrew Morton <[EMAIL PROTECTED]> drivers/net/e1000/e1000_main.c:997:1: error: unterminated #ifdef Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000_main.c |1 - 1 file changed, 1 deletion(-) diff -puN drivers/net/e1000/e1000_main.c~git-netdev-all-e1000-fix drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c~git-netdev-all-e1000-fix +++ a/drivers/net/e1000/e1000_main.c @@ -994,7 +994,6 @@ e1000_probe(struct pci_dev *pdev, (adapter->hw.mac_type != e1000_82547)) netdev->features |= NETIF_F_TSO; -#ifdef NETIF_F_TSO6 if (adapter->hw.mac_type > e1000_82547_rev_2) netdev->features |= NETIF_F_TSO6; if (pci_using_dac) _ doh, I wish I had not included that in my updated patch for -mm right now... I knew I should have posted this to Jeff first when I spotted it myself this morning ;) Ack, of course. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Andrew Morton wrote: On Tue, 09 Jan 2007 09:36:29 -0800 Auke Kok <[EMAIL PROTECTED]> wrote: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000 That tree appears to be based on the -mm git tree? That's a somewhat unusual thing to do - a tree which is based on current Linus mainline would be preferred, please. Or on Jeff's netdev tree. An updated patch is available from git, and applies against netdev-2.6's upstream branch (as of commit 77aab8bf22042d1658d4adbca8b71779e7f2d0ff ) git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 e1000 Again, also available per http: http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite-v2-upstream.patch http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite-v2-upstream.patch.bz2 This version contains a few minor adjustments and updates to the one posted earlier this morning (and replaces that patch): 1) 82541 bitmask issue 2) 80003es2lan timeout value fix 3) added some more kdoc headers to functions 4) removed #ifdef NETIF_F_TSO6 forgotten by cleanup patch I hope this patch works for everyone, please let me know if there are still problems. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18
Jeff V. Merkey wrote: Jeff V. Merkey wrote: root=/dev/hda2 is what was passed to the kernel from grub. Jeff I just finished pulling out a melted IDE flash drive out of a Shuttle motherboard with the intel 945 chipset which claims to support SATA and IDE drives concurrently under Linux 2.6.18. The chip worked for about 30 seconds before liquifying in the chassis. I note that the 945 chipset in the shuttle PC had some serious issues recognizing 2 x SATA devices and a IDE device concurrently. Are there known problems with the Linux drivers with these newer chipsets. One other disturbing issue was the IDE flash drive was configured (and recognized) as /dev/hda during bootup, but when it got to the root mountint, even with root=/dev/hda set, it still kept thinking the drive was at scsi (ATA) device (08,13) and kept crashing with VFS cannot find root FS errors. it sounds like someone switched the BIOS IDE setting from ide-compatible/legacy to AHCI or similar, a not uncommon option in the sata controllers on those boards. None of that would explain the melting of anything of course. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Randy Dunlap wrote: On Tue, 09 Jan 2007 20:16:27 +0100 Krzysztof Halasa wrote: Auke Kok <[EMAIL PROTECTED]> writes: drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 95 drivers/net/e1000/e1000_80003es2lan.c | 1330 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 586 ++ drivers/net/e1000/e1000_82541.c | 1164 drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 466 ++ drivers/net/e1000/e1000_82543.c | 1397 + drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1132 drivers/net/e1000/e1000_82571.h | 42 Perhaps the "e1000_" prefix could be dropped as redundant? -- Yes, that suggestion would agree with what Linus told us about usb file names 7 years ago. (huh? that long?) You'll have to excuse me that I don't remember that anymore, but I'll note the suggestion and see what the team thinks. Thanks, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Andrew Morton wrote: On Tue, 09 Jan 2007 09:36:29 -0800 Auke Kok <[EMAIL PROTECTED]> wrote: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000 That tree appears to be based on the -mm git tree? That's a somewhat unusual thing to do - a tree which is based on current Linus mainline would be preferred, please. Or on Jeff's netdev tree. those are not in sync atm, but I'll get you one against Jeff's upstream tree, that'll take a minute, or five. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Stephen Hemminger wrote: On Tue, 09 Jan 2007 09:36:29 -0800 Auke Kok <[EMAIL PROTECTED]> wrote: Andrew, All, This patch contains a major rewrite to the e1000 driver that groups and separates e1000 hardware by chipset family. It abstracts the hardware specific code into an API that will allow us to continue to maintain the complex e1000 driver and add new hardware support to it without touching code that affects older chipsets. Thats good. but: drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 95 drivers/net/e1000/e1000_80003es2lan.c | 1330 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 586 ++ drivers/net/e1000/e1000_82541.c | 1164 drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 466 ++ drivers/net/e1000/e1000_82543.c | 1397 + drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1132 drivers/net/e1000/e1000_82571.h | 42 drivers/net/e1000/e1000_api.c | 1077 drivers/net/e1000/e1000_api.h | 159 + drivers/net/e1000/e1000_defines.h | 1289 + drivers/net/e1000/e1000_ethtool.c | 470 +- drivers/net/e1000/e1000_hw.c | 9038 - drivers/net/e1000/e1000_hw.h | 3859 ++ drivers/net/e1000/e1000_ich8lan.c | 2353 + drivers/net/e1000/e1000_ich8lan.h | 108 drivers/net/e1000/e1000_mac.c | 1921 +++ drivers/net/e1000/e1000_mac.h | 84 drivers/net/e1000/e1000_main.c| 1002 ++-- drivers/net/e1000/e1000_manage.c | 387 + drivers/net/e1000/e1000_manage.h | 83 drivers/net/e1000/e1000_nvm.c | 860 +++ drivers/net/e1000/e1000_nvm.h | 61 drivers/net/e1000/e1000_osdep.h | 56 drivers/net/e1000/e1000_param.c | 115 drivers/net/e1000/e1000_phy.c | 1932 +++ drivers/net/e1000/e1000_phy.h | 157 + drivers/net/e1000/e1000_regs.h| 236 + 32 files changed, 18538 insertions(+), 13160 deletions(-) Is lots of little files really progress? I can think of a few files that we could merge myself, but we really wanted to get away from the two large (e1000_hw) files that we had, which was far worse. We're open to suggestions as to reduce the amount of files, but since e1000 has it's own subdirectory, and supports a large amount of files, I think we're in the right direction with the amount. We approached it this from a rather superfluous amount of files standpoint knowing we can merge some later anyway. One thing we've contemplated ourselves was to merge the smaller .h files into the .c files where applicable, so your comment goes duly noted Thanks, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -MM] e1000: rewrite hardware initialization code
Andrew, All,
This patch contains a major rewrite to the e1000 driver that groups and separates e1000
hardware by chipset family. It abstracts the hardware specific code into an API that
will allow us to continue to maintain the complex e1000 driver and add new hardware
support to it without touching code that affects older chipsets. It de-complexifies a
significant part of the e1000 driver.
This is the first and largest part of e1000 changes that have been long overdue. Thanks
to Jeb Cramer working on this, as well as our validation team, this code is getting
ready for general consumption. We hope to get started on adding a better way of handling
feature flags and workarounds to the complex e1000 driver quickly.
We're submitting this code to -mm for obvious reasons: we are still testing the code and
want the community feedback on this large change, while giving the linux community an
early chance to test and use the new driver before it goes mainstream.
The patch addresses the following issues:
* separates hardware-specific code by chipset family and provides a single API for all
chipsets (effectively a lib-e1000)
* maintains a single driver for the user, no external changes
* will allow the user in the future to select specific hardware support instead
of all
Some cosmetic changes were also made. This driver adds more header and code files to
separate the new parts of the code (chipsets, api, nvm, mac & phy layers). All
whitespace was changed to linux indentation and integer data types were converted to
{u,s}{8,16,32,64} types instead of uintNN_t types.
The total size of the patch is 1.2mb plaintext, and too large to post to any of the
lists. I've provided several ways of receiving the patch:
(1)
git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000
The patch here applies against 2.6.20-rc3-mm1.
(2)
http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite.patch (1.2mb)
or
http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite.patch.bz2 (162k)
I'll gladly e-mail the patch to anyone who wishes to receive it by e-mail.
Andrew, please pull from our git tree listed above to receive the patch. I expect in the
coming few weeks to provide updates to this patch as issues that come up are resolved.
Cheers,
Auke
---
e1000: rewrite of HW code library
From: Jeb Cramer <[EMAIL PROTECTED]>
This rewrite of the hardware initialization code splits up the driver
low-level initialization code per chipset family. Several families exist
with different initialization code per chipset, revision, and this allows
us later to select only enable certain devices in the driver. The current
code enables all previous drivers and thus doesn't change anything to the
user, but is radically different internally.
Mac and phy layers are also split, and everything is grouped in an API
layer that the driver uses to interface the hardware.
Support was added for a PCI-e 4-port Fibre version of the PRO/1000 PT quad
port adapter (device 0x10a5). MTU changes on a downed interface require
a phy commit to enact the new size immediately.
Signed-off-by: Jeb Cramer <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/Makefile| 19
drivers/net/e1000/e1000.h | 95
drivers/net/e1000/e1000_80003es2lan.c | 1330 +
drivers/net/e1000/e1000_80003es2lan.h | 89
drivers/net/e1000/e1000_82540.c | 586 ++
drivers/net/e1000/e1000_82541.c | 1164
drivers/net/e1000/e1000_82541.h | 86
drivers/net/e1000/e1000_82542.c | 466 ++
drivers/net/e1000/e1000_82543.c | 1397 +
drivers/net/e1000/e1000_82543.h | 45
drivers/net/e1000/e1000_82571.c | 1132
drivers/net/e1000/e1000_82571.h | 42
drivers/net/e1000/e1000_api.c | 1077
drivers/net/e1000/e1000_api.h | 159 +
drivers/net/e1000/e1000_defines.h | 1289 +
drivers/net/e1000/e1000_ethtool.c | 470 +-
drivers/net/e1000/e1000_hw.c | 9038 -
drivers/net/e1000/e1000_hw.h | 3859 ++
drivers/net/e1000/e1000_ich8lan.c | 2353 +
drivers/net/e1000/e1000_ich8lan.h | 108
drivers/net/e1000/e1000_mac.c | 1921 +++
drivers/net/e1000/e1000_mac.h | 84
drivers/net/e1000/e1000_main.c| 1002 ++--
drivers/net/e1000/e1000_manage.c | 387 +
drivers/net/e1000/e1000_manage.h | 83
drivers/net/e1000/e1000_nvm.c | 860 +++
drivers/net/e1000/e1000_nvm.h | 61
drivers/net/e1000/e1000_osdep.h | 56
drivers/net/e1000/e1000_param.c | 115
drivers/net/e1000/e1000_phy.c | 1932 +++
drivers/net/e1000/e1000_phy.h | 157 +
drivers/net/e1000/e1000_regs.h| 236 +
32 files changed, 18538 insertions(+), 13160 deletions(-)
-
To unsubscribe from this list
Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18
Jeff V. Merkey wrote: Jeff V. Merkey wrote: root=/dev/hda2 is what was passed to the kernel from grub. Jeff I just finished pulling out a melted IDE flash drive out of a Shuttle motherboard with the intel 945 chipset which claims to support SATA and IDE drives concurrently under Linux 2.6.18. The chip worked for about 30 seconds before liquifying in the chassis. I note that the 945 chipset in the shuttle PC had some serious issues recognizing 2 x SATA devices and a IDE device concurrently. Are there known problems with the Linux drivers with these newer chipsets. One other disturbing issue was the IDE flash drive was configured (and recognized) as /dev/hda during bootup, but when it got to the root mountint, even with root=/dev/hda set, it still kept thinking the drive was at scsi (ATA) device (08,13) and kept crashing with VFS cannot find root FS errors. it sounds like someone switched the BIOS IDE setting from ide-compatible/legacy to AHCI or similar, a not uncommon option in the sata controllers on those boards. None of that would explain the melting of anything of course. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Sami Farin wrote: Linux 2.6.19.1 SMP on Pentium D, Intel DQ965GF mobo. Got this while bittorrenting knoppix: 2007-01-09 22:53:40.020693500 4NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=83.46.5.76 DST=80.223.106.128 LEN=121 TOS=0x00 PREC=0x00 TTL=112 ID=53273 PROTO=ICMP TYPE=3 CODE=3 [SRC=80.223.106.128 DST=192.168.1.37 LEN=93 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=UDP SPT=6881 DPT=6895 LEN=73 ] 2007-01-09 22:53:41.660249500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:41.660253500 4 Tx Queue 0 2007-01-09 22:53:41.660254500 4 TDH 3c 2007-01-09 22:53:41.660255500 4 TDT ca 2007-01-09 22:53:41.660255500 4 next_to_use ca 2007-01-09 22:53:41.660256500 4 next_to_clean3c 2007-01-09 22:53:41.660257500 4buffer_info[next_to_clean] 2007-01-09 22:53:41.660258500 4 time_stamp 8c3b8e4 2007-01-09 22:53:41.660259500 4 next_to_watch3f 2007-01-09 22:53:41.660274500 4 jiffies 8c3bf13 2007-01-09 22:53:41.660275500 4 next_to_watch.status 0 2007-01-09 22:53:42.660365500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:42.660368500 4 Tx Queue 0 2007-01-09 22:53:42.660369500 4 TDH 3c 2007-01-09 22:53:42.660370500 4 TDT ca 2007-01-09 22:53:42.660370500 4 next_to_use ca 2007-01-09 22:53:42.660371500 4 next_to_clean3c 2007-01-09 22:53:42.660372500 4buffer_info[next_to_clean] 2007-01-09 22:53:42.660373500 4 time_stamp 8c3b8e4 2007-01-09 22:53:42.660374500 4 next_to_watch3f 2007-01-09 22:53:42.660389500 4 jiffies 8c3c2fb 2007-01-09 22:53:42.660390500 4 next_to_watch.status 0 2007-01-09 22:53:43.660086500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:43.660089500 4 Tx Queue 0 2007-01-09 22:53:43.660090500 4 TDH 3c 2007-01-09 22:53:43.660091500 4 TDT ca 2007-01-09 22:53:43.660092500 4 next_to_use ca 2007-01-09 22:53:43.660093500 4 next_to_clean3c 2007-01-09 22:53:43.660093500 4buffer_info[next_to_clean] 2007-01-09 22:53:43.660094500 4 time_stamp 8c3b8e4 2007-01-09 22:53:43.660095500 4 next_to_watch3f 2007-01-09 22:53:43.660110500 4 jiffies 8c3c6e3 2007-01-09 22:53:43.660111500 4 next_to_watch.status 0 2007-01-09 22:53:44.660001500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:44.660004500 4 Tx Queue 0 2007-01-09 22:53:44.660005500 4 TDH 3c 2007-01-09 22:53:44.660006500 4 TDT ca 2007-01-09 22:53:44.660007500 4 next_to_use ca 2007-01-09 22:53:44.660008500 4 next_to_clean3c 2007-01-09 22:53:44.660009500 4buffer_info[next_to_clean] 2007-01-09 22:53:44.660009500 4 time_stamp 8c3b8e4 2007-01-09 22:53:44.660010500 4 next_to_watch3f 2007-01-09 22:53:44.660026500 4 jiffies 8c3cacb 2007-01-09 22:53:44.660027500 4 next_to_watch.status 0 2007-01-09 22:53:45.659906500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:45.659909500 4 Tx Queue 0 2007-01-09 22:53:45.659909500 4 TDH 3c 2007-01-09 22:53:45.659910500 4 TDT ca 2007-01-09 22:53:45.659911500 4 next_to_use ca 2007-01-09 22:53:45.659912500 4 next_to_clean3c 2007-01-09 22:53:45.659913500 4buffer_info[next_to_clean] 2007-01-09 22:53:45.659914500 4 time_stamp 8c3b8e4 2007-01-09 22:53:45.659915500 4 next_to_watch3f 2007-01-09 22:53:45.659930500 4 jiffies 8c3ceb3 2007-01-09 22:53:45.659931500 4 next_to_watch.status 0 2007-01-09 22:53:46.659784500 3e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang 2007-01-09 22:53:46.659787500 4 Tx Queue 0 2007-01-09 22:53:46.659788500 4 TDH 3c 2007-01-09 22:53:46.659788500 4 TDT ca 2007-01-09 22:53:46.659789500 4 next_to_use ca 2007-01-09 22:53:46.659790500 4 next_to_clean3c 2007-01-09 22:53:46.659791500 4buffer_info[next_to_clean] 2007-01-09 22:53:46.659792500 4 time_stamp 8c3b8e4 2007-01-09 22:53:46.659793500 4 next_to_watch3f 2007-01-09 22:53:46.659807500 4 jiffies 8c3d29b 2007-01-09 22:53:46.659808500 4 next_to_watch.status 0 2007-01-09 22:53:47.130361500 6NETDEV WATCHDOG: eth0: transmit timed out 2007-01-09 22:53:48.771500500 6e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex 2007-01-09 22:53:54.838031500 4NETFILTER drop IN=eth0 OUT= MAC=00:19:d1:00:5f:01:00:05:00:1c:58:1c:08:00 SRC=84.49.68.15 DST=80.223.106.128 LEN=56 TOS=0x00 PREC=0x00 TTL=142 ID=55046 PROTO=ICMP TYPE=3 CODE=1 [SRC=80.223.106.128 DST=10.0.0.2 LEN=91 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=UDP SPT=6881 DPT=4412 LEN=71 ] ...and... 2007-01-09 23:40:42.311352500 4NETFILTER drop IN=eth0 OUT=
Re: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Sami Farin wrote: On Tue, Jan 09, 2007 at 15:59:30 -0800, Auke Kok wrote: Sami Farin wrote: ... I do ethtool -K eth0 tso off now and check if I get the hang again. =) I'm unsure whether v7.2.x already automatically disables TSO for 100mbit speed link, probably not. It should. It disabled it but I enabled it just for fun. Please try our updated driver from http://e1000.sf.net/ (7.3.20) against the same kernel. There are some changes with regard to the ich8/TSO driver that might affect this, so re-testing is worth it for us. I now run 7.3.20-NAPI. BTW. the Makefile is buggy: it does not get CC from kernel's Makefile. Using wrong compiler can cause for example a reboot when loading the module. (At least that's what happened with gcc-2.95.3 vs 3.x.x some years ago...) I'll look into that, do you have any suggestions? also, please always include the full dmesg output. Feel free to CC [EMAIL PROTECTED] on this. I enabled TSO again. I write again if TSO causes problems. There are known problems with that configuration, that's why the newer drivers disable TSO for 10/100 speeds. do you really think that you can see the performance gain fro musing TSO at those speeds anyway? we don't ;). In any case you should keep TSO off for 10/100 speeds. Why shouldn't it work with 100 Mbps? Not that it would help a lot, but I ask this on principle. /* disable TSO for pcie and 10/100 speeds, to avoid * some hardware issues */ Issues on the motherboard or the NIC? we (the e1000 team) don't write drivers for the motherboard, but only for the NIC component, so I hope that answers your question. 2007-01-10 02:39:51.889908500 6ACPI: PCI interrupt for device :00:19.0 disabled 2007-01-10 02:39:54.545194500 6Intel(R) PRO/1000 Network Driver - version 7.3.20-NAPI 2007-01-10 02:39:54.545198500 6Copyright (c) 1999-2006 Intel Corporation. 2007-01-10 02:39:54.545395500 6ACPI: PCI Interrupt :00:19.0[A] - GSI 20 (level, low) - IRQ 22 2007-01-10 02:39:54.545435500 7PCI: Setting latency timer of device :00:19.0 to 64 2007-01-10 02:39:54.562905500 6e1000: :00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:19:d1:00:5f:01 2007-01-10 02:39:54.638093500 6e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection 2007-01-10 02:40:07.513619500 6ADDRCONF(NETDEV_UP): eth0: link is not ready 2007-01-10 02:40:07.614768500 6e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:07.614770500 6e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO 2007-01-10 02:40:07.614771500 6ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready 2007-01-10 02:40:09.271631500 3e1000: eth0: e1000_reset: Hardware Error 2007-01-10 02:40:10.93500 6e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None 2007-01-10 02:40:10.930049500 6e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO PS. please do not delete Mail-Followup-To header field. I hit reply-all and I have no control over which field thunderbird removes or adds. I have to manually add your e-mail address too? Maybe your mail client is broken instead? Don't you want to receive replies? Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + git-netdev-all-e1000-fix.patch added to -mm tree
[EMAIL PROTECTED] wrote: The patch titled git-netdev-all: e1000 fix has been added to the -mm tree. Its filename is git-netdev-all-e1000-fix.patch See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find out what to do about this -- Subject: git-netdev-all: e1000 fix From: Andrew Morton [EMAIL PROTECTED] drivers/net/e1000/e1000_main.c:997:1: error: unterminated #ifdef Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |1 - 1 file changed, 1 deletion(-) diff -puN drivers/net/e1000/e1000_main.c~git-netdev-all-e1000-fix drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c~git-netdev-all-e1000-fix +++ a/drivers/net/e1000/e1000_main.c @@ -994,7 +994,6 @@ e1000_probe(struct pci_dev *pdev, (adapter-hw.mac_type != e1000_82547)) netdev-features |= NETIF_F_TSO; -#ifdef NETIF_F_TSO6 if (adapter-hw.mac_type e1000_82547_rev_2) netdev-features |= NETIF_F_TSO6; if (pci_using_dac) _ doh, I wish I had not included that in my updated patch for -mm right now... I knew I should have posted this to Jeff first when I spotted it myself this morning ;) Ack, of course. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -MM] e1000: rewrite hardware initialization code
Andrew, All,
This patch contains a major rewrite to the e1000 driver that groups and separates e1000
hardware by chipset family. It abstracts the hardware specific code into an API that
will allow us to continue to maintain the complex e1000 driver and add new hardware
support to it without touching code that affects older chipsets. It de-complexifies a
significant part of the e1000 driver.
This is the first and largest part of e1000 changes that have been long overdue. Thanks
to Jeb Cramer working on this, as well as our validation team, this code is getting
ready for general consumption. We hope to get started on adding a better way of handling
feature flags and workarounds to the complex e1000 driver quickly.
We're submitting this code to -mm for obvious reasons: we are still testing the code and
want the community feedback on this large change, while giving the linux community an
early chance to test and use the new driver before it goes mainstream.
The patch addresses the following issues:
* separates hardware-specific code by chipset family and provides a single API for all
chipsets (effectively a lib-e1000)
* maintains a single driver for the user, no external changes
* will allow the user in the future to select specific hardware support instead
of all
Some cosmetic changes were also made. This driver adds more header and code files to
separate the new parts of the code (chipsets, api, nvm, mac phy layers). All
whitespace was changed to linux indentation and integer data types were converted to
{u,s}{8,16,32,64} types instead of uintNN_t types.
The total size of the patch is 1.2mb plaintext, and too large to post to any of the
lists. I've provided several ways of receiving the patch:
(1)
git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000
The patch here applies against 2.6.20-rc3-mm1.
(2)
http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite.patch (1.2mb)
or
http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite.patch.bz2 (162k)
I'll gladly e-mail the patch to anyone who wishes to receive it by e-mail.
Andrew, please pull from our git tree listed above to receive the patch. I expect in the
coming few weeks to provide updates to this patch as issues that come up are resolved.
Cheers,
Auke
---
e1000: rewrite of HW code library
From: Jeb Cramer [EMAIL PROTECTED]
This rewrite of the hardware initialization code splits up the driver
low-level initialization code per chipset family. Several families exist
with different initialization code per chipset, revision, and this allows
us later to select only enable certain devices in the driver. The current
code enables all previous drivers and thus doesn't change anything to the
user, but is radically different internally.
Mac and phy layers are also split, and everything is grouped in an API
layer that the driver uses to interface the hardware.
Support was added for a PCI-e 4-port Fibre version of the PRO/1000 PT quad
port adapter (device 0x10a5). MTU changes on a downed interface require
a phy commit to enact the new size immediately.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/Makefile| 19
drivers/net/e1000/e1000.h | 95
drivers/net/e1000/e1000_80003es2lan.c | 1330 +
drivers/net/e1000/e1000_80003es2lan.h | 89
drivers/net/e1000/e1000_82540.c | 586 ++
drivers/net/e1000/e1000_82541.c | 1164
drivers/net/e1000/e1000_82541.h | 86
drivers/net/e1000/e1000_82542.c | 466 ++
drivers/net/e1000/e1000_82543.c | 1397 +
drivers/net/e1000/e1000_82543.h | 45
drivers/net/e1000/e1000_82571.c | 1132
drivers/net/e1000/e1000_82571.h | 42
drivers/net/e1000/e1000_api.c | 1077
drivers/net/e1000/e1000_api.h | 159 +
drivers/net/e1000/e1000_defines.h | 1289 +
drivers/net/e1000/e1000_ethtool.c | 470 +-
drivers/net/e1000/e1000_hw.c | 9038 -
drivers/net/e1000/e1000_hw.h | 3859 ++
drivers/net/e1000/e1000_ich8lan.c | 2353 +
drivers/net/e1000/e1000_ich8lan.h | 108
drivers/net/e1000/e1000_mac.c | 1921 +++
drivers/net/e1000/e1000_mac.h | 84
drivers/net/e1000/e1000_main.c| 1002 ++--
drivers/net/e1000/e1000_manage.c | 387 +
drivers/net/e1000/e1000_manage.h | 83
drivers/net/e1000/e1000_nvm.c | 860 +++
drivers/net/e1000/e1000_nvm.h | 61
drivers/net/e1000/e1000_osdep.h | 56
drivers/net/e1000/e1000_param.c | 115
drivers/net/e1000/e1000_phy.c | 1932 +++
drivers/net/e1000/e1000_phy.h | 157 +
drivers/net/e1000/e1000_regs.h| 236 +
32 files changed, 18538 insertions(+), 13160 deletions(-)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Stephen Hemminger wrote: On Tue, 09 Jan 2007 09:36:29 -0800 Auke Kok [EMAIL PROTECTED] wrote: Andrew, All, This patch contains a major rewrite to the e1000 driver that groups and separates e1000 hardware by chipset family. It abstracts the hardware specific code into an API that will allow us to continue to maintain the complex e1000 driver and add new hardware support to it without touching code that affects older chipsets. Thats good. but: drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 95 drivers/net/e1000/e1000_80003es2lan.c | 1330 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 586 ++ drivers/net/e1000/e1000_82541.c | 1164 drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 466 ++ drivers/net/e1000/e1000_82543.c | 1397 + drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1132 drivers/net/e1000/e1000_82571.h | 42 drivers/net/e1000/e1000_api.c | 1077 drivers/net/e1000/e1000_api.h | 159 + drivers/net/e1000/e1000_defines.h | 1289 + drivers/net/e1000/e1000_ethtool.c | 470 +- drivers/net/e1000/e1000_hw.c | 9038 - drivers/net/e1000/e1000_hw.h | 3859 ++ drivers/net/e1000/e1000_ich8lan.c | 2353 + drivers/net/e1000/e1000_ich8lan.h | 108 drivers/net/e1000/e1000_mac.c | 1921 +++ drivers/net/e1000/e1000_mac.h | 84 drivers/net/e1000/e1000_main.c| 1002 ++-- drivers/net/e1000/e1000_manage.c | 387 + drivers/net/e1000/e1000_manage.h | 83 drivers/net/e1000/e1000_nvm.c | 860 +++ drivers/net/e1000/e1000_nvm.h | 61 drivers/net/e1000/e1000_osdep.h | 56 drivers/net/e1000/e1000_param.c | 115 drivers/net/e1000/e1000_phy.c | 1932 +++ drivers/net/e1000/e1000_phy.h | 157 + drivers/net/e1000/e1000_regs.h| 236 + 32 files changed, 18538 insertions(+), 13160 deletions(-) Is lots of little files really progress? I can think of a few files that we could merge myself, but we really wanted to get away from the two large (e1000_hw) files that we had, which was far worse. We're open to suggestions as to reduce the amount of files, but since e1000 has it's own subdirectory, and supports a large amount of files, I think we're in the right direction with the amount. We approached it this from a rather superfluous amount of files standpoint knowing we can merge some later anyway. One thing we've contemplated ourselves was to merge the smaller .h files into the .c files where applicable, so your comment goes duly noted Thanks, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Andrew Morton wrote: On Tue, 09 Jan 2007 09:36:29 -0800 Auke Kok [EMAIL PROTECTED] wrote: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000 That tree appears to be based on the -mm git tree? That's a somewhat unusual thing to do - a tree which is based on current Linus mainline would be preferred, please. Or on Jeff's netdev tree. those are not in sync atm, but I'll get you one against Jeff's upstream tree, that'll take a minute, or five. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Randy Dunlap wrote: On Tue, 09 Jan 2007 20:16:27 +0100 Krzysztof Halasa wrote: Auke Kok [EMAIL PROTECTED] writes: drivers/net/e1000/Makefile| 19 drivers/net/e1000/e1000.h | 95 drivers/net/e1000/e1000_80003es2lan.c | 1330 + drivers/net/e1000/e1000_80003es2lan.h | 89 drivers/net/e1000/e1000_82540.c | 586 ++ drivers/net/e1000/e1000_82541.c | 1164 drivers/net/e1000/e1000_82541.h | 86 drivers/net/e1000/e1000_82542.c | 466 ++ drivers/net/e1000/e1000_82543.c | 1397 + drivers/net/e1000/e1000_82543.h | 45 drivers/net/e1000/e1000_82571.c | 1132 drivers/net/e1000/e1000_82571.h | 42 Perhaps the e1000_ prefix could be dropped as redundant? -- Yes, that suggestion would agree with what Linus told us about usb file names 7 years ago. (huh? that long?) You'll have to excuse me that I don't remember that anymore, but I'll note the suggestion and see what the team thinks. Thanks, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -MM] e1000: rewrite hardware initialization code
Andrew Morton wrote: On Tue, 09 Jan 2007 09:36:29 -0800 Auke Kok [EMAIL PROTECTED] wrote: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.6 e1000 That tree appears to be based on the -mm git tree? That's a somewhat unusual thing to do - a tree which is based on current Linus mainline would be preferred, please. Or on Jeff's netdev tree. An updated patch is available from git, and applies against netdev-2.6's upstream branch (as of commit 77aab8bf22042d1658d4adbca8b71779e7f2d0ff ) git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 e1000 Again, also available per http: http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite-v2-upstream.patch http://foo-projects.org/~sofar/e1000_hw_init_layer_rewrite-v2-upstream.patch.bz2 This version contains a few minor adjustments and updates to the one posted earlier this morning (and replaces that patch): 1) 82541 bitmask issue 2) 80003es2lan timeout value fix 3) added some more kdoc headers to functions 4) removed #ifdef NETIF_F_TSO6 forgotten by cleanup patch I hope this patch works for everyone, please let me know if there are still problems. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
Renato S. Yamane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 05-01-2007 10:04, Akula2 escreveu: On 1/5/07, Auke Kok <[EMAIL PROTECTED]> wrote: Steve Brueggeman wrote: gcc 3.4.x works great on both 2.6 and 2.4, no issues whatsoever. Do you mean I need to discard gcc 4.1.x on the distro? Or keep both? I use GCC 4.1.2 with vendor Kernel (OpenSuSE) 2.6.18.2 with no problem. In next weekend I will compile a new Kernel. 2.6.19.1 I was not saying that *other* compilers don't work, but merely stating that a certain version of gcc does really well with BOTH (and most) 2.4 and 2.6 kernel sources. I doubt that gcc-4.1.x works all that great with some of the not-so-recent 2.4 kernels. Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
Renato S. Yamane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Em 05-01-2007 10:04, Akula2 escreveu: On 1/5/07, Auke Kok [EMAIL PROTECTED] wrote: Steve Brueggeman wrote: gcc 3.4.x works great on both 2.6 and 2.4, no issues whatsoever. Do you mean I need to discard gcc 4.1.x on the distro? Or keep both? I use GCC 4.1.2 with vendor Kernel (OpenSuSE) 2.6.18.2 with no problem. In next weekend I will compile a new Kernel. 2.6.19.1 I was not saying that *other* compilers don't work, but merely stating that a certain version of gcc does really well with BOTH (and most) 2.4 and 2.6 kernel sources. I doubt that gcc-4.1.x works all that great with some of the not-so-recent 2.4 kernels. Auke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
Steve Brueggeman wrote: There are some difficulties with gcc versions between linux-2.4 and linux-2.6, but I do not recall all of the details off of the top of my head. If I recall correctly, one of the issues is, linux-2.4 ?prefers? gcc-2.96, while newer linux-2.6 support/prefer gcc-3.? or greater. gcc 3.4.x works great on both 2.6 and 2.4, no issues whatsoever. At any rate, what I've done is create a chroot environment. I created this chroot directory by installing an older distribution that was created with linux-2.4 in mind (example, RedHat v8.2) into that at chroot directory. The easiest way to do this that I'm aware of is to install the older distribution (minimal development, no server junk, no X junk) on another computer, then copy from that computer to a directory on your development computer. it's even easier to not do that and install and compile everything in one rootfs, which is perfectly possible and I have done so many times. You can leave away the chroot and any possible security issues that you fear, allthough those are pretty much nonexistant. The only real bottom line issue is that module-init-tools cannot load modules on a 2.4 kernel, and modutils doesn't do that on 2.6, so you will have to switch or wrap them to detect the running kernel. The same goes for udev vs. devfs. of course, setting up a qemu image or separate partition is easier, but that was not the question I think. Most binary distro's won't support this, but I think all of the source distro's and more specific ones support it and a few handle it out of the box. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
Akula2 wrote: Hello All, I am looking to use multiple kernel trees on the same distro. Example:- 2.6.19.1 for - software/tools development 2.4.34for - embedded systems development. I do know that 2.6 supports embedded in a big waybut still requirement demands to work with such boards as an example:- http://www.embeddedarm.com/linux/ARM.htm My question is HOW-TO enable a distro with multi kernel trees? Presently am using Fedora Core 5/6 for much of the development activities (Cell BE SDK related at Labs). Any hints/suggestions would be a great leap for me to do this on my own. this is really no big problem (as in: works OOTB), except that if you want to boot & run both kernels on the same (rootfs) installation, you will need to create wrappers around modutils and module-init-tools, as well as udev/devfs, or whichever device file system you prefer to use for each kernel. There are a few minor other details but none really shocking. We've done this for "our" source distro, and it works just fine. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
