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
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
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]>
---
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
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 ++
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
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]>
---
d
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
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
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/CodingS
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
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
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: Au
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 &
;
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
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
-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
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
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)
+
[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
[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
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)
+
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
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
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
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
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 @@
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 @@
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
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 ther
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
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
: 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 d
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
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
: 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
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
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
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.
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
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
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
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 free
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
irsher <[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_
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 s
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 free
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
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
-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
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
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
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
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
[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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
ed-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 -
d
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
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
-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
[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
[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
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.
I
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
[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
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
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
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
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
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
e 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]>
---
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
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
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
[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
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
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
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
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
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
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
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
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
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
1 - 100 of 116 matches
Mail list logo
