Brandeburg, Jesse wrote:
> Wolfgang Walter wrote:
>> it seems that e1000 enables flow-control (rx pause frames) even if
>> the switch does not advertise flow control. This seems to get a
>> problem as (at least some) switches then forward pause frames
>> directed to the card from other hosts. We th
Wolfgang Walter wrote:
> Hello,
>
> it seems that e1000 enables flow-control (rx pause frames) even if the switch
> does not advertise flow control. This seems to get a problem as (at least
> some) switches then forward pause frames directed to the card from other
> hosts. We think there are ho
Kok, Auke wrote:
> Kok, Auke wrote:
>> Andrew Morton wrote:
>>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>>&g
Kok, Auke wrote:
> Andrew Morton wrote:
>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
>> wrote:
>>
>>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>>
>>> [ 8803.850634] ACPI: Prep
Andrew Morton wrote:
> On Sun, 17 Feb 2008 13:20:59 + "Daniel J Blueman" <[EMAIL PROTECTED]>
> wrote:
>
>> I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again.
are you sure? I don't think that's the case and you're seeing e1000 dumps
here...
>> It's clearly non-fatal, but then
Andrew Morton wrote:
> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
>
>> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>>
>> [ 8803.850634] ACPI: Preparing to enter system sleep state S3
>> [ 8803.853141] Suspending console(s)
>> [ 8805.28
Bernd Schubert wrote:
> On Saturday 16 February 2008, Kok, Auke wrote:
>> Bernd Schubert wrote:
>>> Hello,
>>>
>>> I can't login to one of our servers and just got this in an ipmi sol
>>> session:
>>>
>>> [18169.209181] e1000: eth
Bernd Schubert wrote:
> Hello,
>
> I can't login to one of our servers and just got this in an ipmi sol
> session:
>
> [18169.209181] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [18169.209183] Tx Queue <0>
> [18169.209184] TDH
> [18169.209185] TDT
Jeff Garzik wrote:
> Andy Gospodarek wrote:
>> I booted an igb kernel with the option pci=nomsi and instantly noticed
>> that interrupts no longer worked on my igb device. I took a look at the
>> interrupt initialization and quickly discovered a comment stating:
>>
>> "DO NOT USE EIAME or IAME in
Andy Gospodarek wrote:
> I booted an igb kernel with the option pci=nomsi and instantly noticed
> that interrupts no longer worked on my igb device. I took a look at the
> interrupt initialization and quickly discovered a comment stating:
>
> "DO NOT USE EIAME or IAME in legacy mode"
>
> It seem
Prakash Punnoor wrote:
> On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
>> Hi,
>>
>> Is it a known problem?
>> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
>> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
>> e1000e).
your card wi
Daniel Drake wrote:
> Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> stripping enabled by e1000e breaks bridging because sometimes the CRC is
> not stripped:
> https://bugs.gentoo.org/show_bug.cgi?id=209235
>
> Apparently "upstream" are aware but I couldn't find any mails
Johan Andersson wrote:
> Hi,
>
> In commit 140a74802894e9db57e5cd77ccff77e590ece5f3 a workaround for crc
> stripping was removed.
> However, the hardware supported crc stripping now in use doesn't seem to
> work with the following chip:
> Intel Corporation 82566DM-2 Gigabit Network Connection (rev
[Added Ingo, Thomas, Justin who signed off on the patch/tested it]
Pavel Emelyanov wrote:
> The commit
>
> 093af8d7f0ba3c6be1485973508584ef081e9f93
> x86_32: trim memory by updating e820
>
> broke my e1000 card: on loading driver says that
>
> e1000: probe of :04:03.0 fai
Andy Gospodarek wrote:
> (Reposted with the version I intended -- added ',' so it compiles!)
>
> There's too much noise on systems that don't support MSI. Let's get rid
> of a few and make the real error message more specific.
>
> Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>
thanks Andy,
Bruce Allen wrote:
> Hi Auke,
>
> Important note: we ARE able to get full duplex wire speed (over 900
> Mb/s simulaneously in both directions) using UDP. The problems occur
> only with TCP connections.
That eliminates bus bandwidth issues, probably, but small packets take
>>
Rick Jones wrote:
>> A lot of people tend to forget that the pci-express bus has enough
>> bandwidth on
>> first glance - 2.5gbit/sec for 1gbit of traffix, but apart from data
>> going over it
>> there is significant overhead going on: each packet requires transmit,
>> cleanup and
>> buffer transac
Carsten Aulbert wrote:
> Hi Andi,
>
> Andi Kleen wrote:
>> Another issue with full duplex TCP not mentioned yet is that if TSO is
>> used the output will be somewhat bursty and might cause problems with
>> the TCP ACK clock of the other direction because the ACKs would need
>> to squeeze in betwe
Bruce Allen wrote:
> Hi Jesse,
>
>>> It's good to be talking directly to one of the e1000 developers and
>>> maintainers. Although at this point I am starting to think that the
>>> issue may be TCP stack related and nothing to do with the NIC. Am I
>>> correct that these are quite distinct parts
Adrian Bunk wrote:
> This patch makes the needlessly global e1000_dump_eeprom() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
yes, thanks, I'll push it to Jeff.
Auke
>
> ---
> b5fd924a1388d4aaa94cf05e42e317c2b1fb5748
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e10
Adrian Bunk wrote:
> This patch makes the needlessly global reg_pattern_test_array() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
stephen hemminger already pointed this out to me... I'll certainly push this
upstream, thanks Adrian!
Auke
>
> ---
> ed72e457f06311390d9a9e51a00c9049
Denys Fedoryshchenko wrote:
> Sorry. that i interfere in this subject.
>
> Do you recommend CONFIG_IRQBALANCE to be enabled?
I certainly do not. Manual tweaking and pinning the irq's to the correct CPU
will
give the best performance (for specific loads).
The userspace irqbalance daemon tries ve
Andreas Mohr wrote:
> Hi,
>
> On Tue, Jan 29, 2008 at 03:09:25PM -0800, Kok, Auke wrote:
>> Andreas Mohr wrote:
>>> Perhaps it's useful to file a bug/patch
>>> on http://sourceforge.net/projects/e1000/ ? Perhaps -mm testing?
>> I wanted to push this
Jeff Garzik wrote:
> Linus Torvalds wrote:
>>
>> On Tue, 29 Jan 2008, Randy Dunlap wrote:
>>> Andrew was concerned about this when the driver was in -mm.
>>> He asked for a patch that would set E1000E to same value as E1000
>>> and I supplied that. Auke acked it IIRC. Other people vetoed it. :(
Andreas Mohr wrote:
> Hi,
>
> On Tue, Jan 01, 2008 at 09:09:08PM +0100, Andreas Mohr wrote:
>> Thanks for your quick reply!
>>
>> OK, here's part 1, the MII-less support stuff.
>> (preliminary posting, for review only)
>>
>> Note that these diffs apply to 2.6.24-rc6-mm1 without much trouble,
>> th
Matheos Worku wrote:
> Jeff Garzik wrote:
>> Auke Kok wrote:
>>> From: Matheos Worku <[EMAIL PROTECTED]>
>>>
>>> Implement support for a SUN-specific PHY.
>>>
>>> SUN provides a modified 82597-based board with their own
>>> PHY that works with very little modification to the code. This
>>> patch im
Jeff Garzik wrote:
> Auke Kok wrote:
>> From: Jesse Brandeburg <[EMAIL PROTECTED]>
>>
>> fix the typo in speed 1 setting.
>>
>> Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
>> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
>> ---
>>
>> ethtool.c |2 +-
>> 1 files changed, 1 insertions(
Jeba Anandhan wrote:
> Hi all,
> i have doubt in e1000_io_write().
>
> void
> e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value)
> {
> outl(value, port);
> }
>
>
> kernel version: 2.6.12.3
>
>
> Even hw structure has not been used, why it has been passed into
> e10
Jeff Garzik wrote:
> Kok, Auke wrote:
>> All,
>>
>> here is the third version of the igb (82575) ethernet controller
>> driver. This
>> driver was previously posted 2007-07-13 and 2007-12-11. Many comments
>> received
>> were addressed:
>>
&
Jeff Garzik wrote:
> Looks pretty decent. Main comments (style mostly, driver operation path
> seems sound):
thanks again for the comments. I am about to send an updated patch just before
my
vacation and before I do let me just quickly touch on your comments below:
> * kill the bitfields and un
Rick Jones wrote:
>> 1) Interrupts are being processed on both cpus:
>>
>> [EMAIL PROTECTED]:/root> cat /proc/interrupts
>>CPU0 CPU1
>> 30:17037564530785 U3-MPIC Level eth0
>
> IIRC none of the e1000 driven cards are multi-queue
the pci-express variants are, but th
Chris Friesen wrote:
> Kok, Auke wrote:
>
>> You're using 2.6.10... you can always replace the e1000 module with the
>> out-of-tree version from e1000.sf.net, this might help a bit - the
>> version in the
>> 2.6.10 kernel is very very old.
>
> Do you have
Breno Leitao wrote:
> On Thu, 2008-01-10 at 16:36 +, Ben Hutchings wrote:
>>> When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
>>> of transfer rate. If I run 4 netperf against 4 different interfaces, I
>>> get around 720 * 10^6 bits/sec.
>>
>>
>> I take it that's the aver
Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 10, 2008 at 03:26:59PM +, Jeba Anandhan escreveu:
>> Hi Eric,
>> Thanks for the reply. I have one more doubt. For example, if we have 2
>> processor and 4 ethernet cards. Only CPU0 does all work through 8 cards.
>> If we set the affinity to each eth
Chris Friesen wrote:
> Hi all,
>
> I've got an issue that's popped up with a deployed system running
> 2.6.10. I'm looking for some help figuring out why incoming network
> packets aren't being processed fast enough.
>
> After a recent userspace app change, we've started seeing packets being
> d
David Miller wrote:
> [NET]: Make ->poll() breakout consistent in Intel ethernet drivers.
>
> This makes the ->poll() routines of the E100, E1000, E1000E, IXGB, and
> IXGBE drivers complete ->poll() consistently.
>
> Now they will all break out when the amount of RX work done is less
> than 'budg
[EMAIL PROTECTED] wrote:
> I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
> after everyboot, when the ethernet traffic starts i get this warning.
>
> All the ports in the system are e1000 and i am using the kernel e1000
> driver.
[added netdev to the Cc:]
can you repro th
Badalian Vyacheslav wrote:
> Hello all.
> Some time in dmesg i see this:
>
> [16121.400422] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [16121.400426] Tx Queue <0>
> [16121.400427] TDH <28>
> [16121.400429] TDT <28>
> [16121.400430]
Andreas Mohr wrote:
> Hi all,
>
> I was mildly annoyed when rebooting my _headless_ internet gateway after a
> hotplug -> udev migration and witnessing it not coming up again,
> which turned out to be due to an eepro100 / e100 loading conflict
> since eepro100 supported both of my Intel-based netw
Auke Kok wrote:
> From: Parag Warudkar <[EMAIL PROTECTED]>
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
> ---
Jeff,
given the discussion with Stephen I'd like to skip merging this patch and the
e100
Stephen Hemminger wrote:
> On Thu, 20 Dec 2007 15:36:13 -0500
> "Parag Warudkar" <[EMAIL PROTECTED]> wrote:
>
>> On Dec 20, 2007 3:04 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
I think it is reasonable for Network driver watchdogs to use a
deferrable timer - if the machine is 100% I
Arjan van de Ven wrote:
>
My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise
about when so schedule
on next second when system will wake up anyway;
e.g why meetings are usually sc
Parag Warudkar wrote:
> On Dec 20, 2007 12:05 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> I can't even apply this patch and the e1000 one... not only is it whitespace
>> damaged it is also not properly formatted as patch at all. If you want me to
>> take
>>
Stephen Hemminger wrote:
> On Thu, 20 Dec 2007 17:29:23 +
>
>> -Original Message-
>> From: Stephen Hemminger <[EMAIL PROTECTED]>
>>
>> Date: Thu, 20 Dec 2007 09:16:03
>> To:[EMAIL PROTECTED]
>> Cc:netdev@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
>> Subject: Re: [PATC
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
> 10:04:39.0 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
> 20:45:59.0 -0500
>
Parag Warudkar wrote:
> On Dec 19, 2007 4:38 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> Parag Warudkar wrote:
>>> On 12/19/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> why would this patch reduce wakeups even more than round_jiffies()? Does it
>> make
>
Parag Warudkar wrote:
> On 12/19/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> [snip]
>
>> I can't possibly see any benefit from this other than that you just add up
>> to a
>> whole second to the initialization cycle, which is bad.
>>
> Well, Ok b
Parag Warudkar wrote:
>
> Use deferrable timer for watchdog. Reduces wakeups from idle per second.
no, we don't want this. We already allow the re-scheduling of the watchdog to be
round_jiffies() modified so that it coincides with other interrupts.
but at load time we don't want the timer to be
Parag Warudkar wrote:
>
> Reduce wakeups from idle per second.
>
> Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
>
> --- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
> 10:04:39.0 -0500
> +++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
> 20:45:59.0 -0500
>
Denys Fedoryshchenko wrote:
> At the beginning - kernel is with "gentoo patched", but i checked, there is
> nothing major and almost none from patched code used on this router (there is
> almost no networking patches, except e1000e support, small GRE fix and few
> wireless things, which is not u
Joe Perches wrote:
> On Fri, 2007-12-14 at 15:35 -0800, Auke Kok wrote:
>> +printk(KERN_ERR "/*/\n");
>> +printk(KERN_ERR "Current EEPROM: 0x%04x\nCalculated: 0x%04x\n",
>> + csum_old, csum_new);
>
> Multiline printks need a KERN_ after every newline. Pe
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 09:13:54 -0500
>
>> If the netif_running() check is indeed required to make a device break
>> out of napi polling and respond to an ifconfig down, then I think the
>> netif_running() check should be moved up i
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Wed, 12 Dec 2007 12:29:23 -0500
>
>> Is the netif_running() check even required?
>
> No, it is not.
>
> When a device is brought down, one of the first things
> that happens is that we wait for all pending NAPI polls
> to co
Kok, Auke wrote:
> All,
>
> here is the second version of the igb (82575) ethernet controller driver. This
> driver was previously posted 2007-07-13. Many comments received were
> addressed:
>
> - removed indirection wrappers in the same way as e1000e and ixgbe.
> - cl
Andrew Morton wrote:
> On Tue, 11 Dec 2007 13:26:58 -0800
> "Kok, Auke" <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[EMAIL PROTECTED]> wrote:
>>>
>>>>> -
Kok, Auke wrote:
> Andrew Morton wrote:
>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[EMAIL PROTECTED]> wrote:
>>
>>>> - Lots of device IDs have been removed from the e1000 driver and moved
>>>> over
>>>> to e1000e. S
David Miller wrote:
> From: Joe Perches <[EMAIL PROTECTED]>
> Date: Tue, 11 Dec 2007 13:04:59 -0800
>
>> On Tue, 2007-12-11 at 11:56 -0800, David Miller wrote:
>>> The rebase of net-2.6.25 is complete
>> I have an earlier unmodified git repository of net-2.6.25.
>> Does anyone know the appropriate
Andrew Morton wrote:
> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[EMAIL PROTECTED]> wrote:
>
>>>
>>> - Lots of device IDs have been removed from the e1000 driver and moved
>>> over
>>> to e1000e. So if your e1000 stops working, you forgot to set
>>> CONFIG_E1000E.
>>>
>>>
>> Wouldn't it
Tomohiro Kusumi wrote:
> Dear Auke and e1000 maintainers
>
> Hi, this is the patch which makes the e1000 driver legacy I/O port free.
>
> I've received some advice from Auke quite long time ago, and submitted
> a patch (http://lkml.org/lkml/2007/8/10/11) which I think meets what Auke
> had told m
Lukas Hejtmanek wrote:
> On Tue, Dec 04, 2007 at 09:19:11AM -0800, Kok, Auke wrote:
>> if you "just" want to disable gigabit speed, get the latest ethtool and run:
>>
>>ethtool -s eth0 advertise 0x0f
>>
>
> thanks. You may then let know people behind
Lukas Hejtmanek wrote:
> On Tue, Dec 04, 2007 at 11:02:23AM -0500, Matt Mathis wrote:
>> This is probably not an e1000 problem, but a general Ethernet "feature".
>> If you defeat auto-negotiation to force the data rate, you implicitly
>> defeat duplex negotiation as well. You need to explicitly
Lukas Hejtmanek wrote:
> On Tue, Nov 27, 2007 at 10:23:00AM -0800, Kok, Auke wrote:
>> can you see if your problem goes away with this patch?
>
> I cannot test it right now but friend of mine has the same card with 2.6.23.1
> kernel. it does not. he also tried module 7.6.12
Robert Olsson wrote:
> Hello!
>
> After further investigations. The bug was just in front of us...
>
> ifconfig down in combination with the test for || !netif_running() can
> return a full quota and netif_rx_complete() done which causes the oops
> in net_rx_action. Of course the load must
David Acker wrote:
> What is the status of this patch? Is there anything folks would like me
> to do in order to move it forward? As an FYI, my company has been using
> this patch since I posted it and so far we have not had any problems
> with it.
> -Ack
Jeff merged it in netdev-2.6#upstream s
Stephen Hemminger wrote:
> On Tue, 27 Nov 2007 14:34:44 -0800
> "Kok, Auke" <[EMAIL PROTECTED]> wrote:
>
>> Stephen Hemminger wrote:
>>> On Tue, 27 Nov 2007 19:52:24 +0100
>>> Robert Olsson <[EMAIL PROTECTED]> wrote:
>>>
>>
Stephen Hemminger wrote:
> On Tue, 27 Nov 2007 19:52:24 +0100
> Robert Olsson <[EMAIL PROTECTED]> wrote:
>
>> Hello!
>>
>> I've discovered a bug while testing the new multiQ NAPI code. In hi-load
>> situations when we take down an interface we get a kernel panic. The
>> oops is below.
>>
>> From
Lukas Hejtmanek wrote:
> On Tue, Nov 27, 2007 at 09:40:08AM -0800, Kok, Auke wrote:
>>> I'm afraid, I'm missing the point as you have stated that in-kernel drivers
>>> have problem with suspicious board hang...
>> my mistake, sorry for that confusion.
>>
[moving this discussion to netdev, dropping lkml]
Lukas Hejtmanek wrote:
> On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote:
>>> unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2
>>> kernel due to compilation errors.
>> but the in-kerne
Joe Perches wrote:
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> ---
> drivers/net/ixgbe/ixgbe_common.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_common.c
> b/drivers/net/ixgbe/ixgbe_common.c
> index 512e3b2..b7e50bc 100644
> ---
Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
>> The e1000 driver stores the content of the PCI resources into
>> unsigned long's before ioremapping. This breaks on 32 bits
>> platforms that support 64 bits MMIO resources such as ppc 44x.
>>
>> This fixes it by removing those temporary variabl
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
>>>> Patrick McHardy wrote:
>>>>
>>>>> I already posted a patch for this, not sure what happened to it.
>>>>> Auke, any news on mergin
Denys Vlasenko wrote:
> On Wednesday 14 November 2007 00:27, Adrian Bunk wrote:
>> You missed the following in my email:
>> "we slowly scare them away due to the many bug reports without any
>> reaction."
>>
>> The problem is that bug reports take time. If you go away from easy
>> things like comp
Joonwoo Park wrote:
> 2007/11/14, Kok, Auke <[EMAIL PROTECTED]>:
>> Patrick McHardy wrote:
>>> Kok, Auke wrote:
>>>> Patrick McHardy wrote:
>>>>
>>>>> I already posted a patch for this, not sure what happened to it.
>>>&g
Krishna Kumar wrote:
> E1000: Implement batching capability (ported thanks to changes taken from
> Jamal).
>
> Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
this doesn't apply anymore and it would help if you could re-spin this for
e1000e.
I don't know what the status for merging of th
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care
Patrick McHardy wrote:
> Herbert Xu wrote:
>> On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which cas
Willy Tarreau wrote:
> On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
>> From: Willy Tarreau <[EMAIL PROTECTED]>
>> Date: Tue, 13 Nov 2007 00:15:16 +0100
>>
>>> I can say that sometimes you'd like to be aware that one of your
>>> VLANs is wrong and you'd simply like to sniff the wire
Chris Friesen wrote:
> David Miller wrote:
>
>> When you select VLAN, you by definition are asking for non-VLAN
>> traffic to be elided. It is like plugging the ethernet cable
>> into one switch or another.
>
> For max functionality it seems like the raw eth device should show
> everything on th
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Joonwoo Park wrote:
>>> IMHO even though netdevice is in the promiscuous mode, we should receive
>>> all of ingress packets.
>>> This disable the vlan filtering feature when a vlan hw accel configured
>>
Joonwoo Park wrote:
> IMHO even though netdevice is in the promiscuous mode, we should receive all
> of ingress packets.
> This disable the vlan filtering feature when a vlan hw accel configured e1000
> device goes into promiscuous mode.
> This make packets visible to sniffers though it's not vla
[adding netdev, jeff G to the Cc]
Linas Vepstas wrote:
> On Wed, Nov 07, 2007 at 01:50:17PM -0800, Kok, Auke wrote:
>> Linas Vepstas wrote:
>>> If a PCI bus error is encountered during device open, the
>>> error recovery routines will attempt to close the device.
&
Ben Hutchings wrote:
> Auke Kok wrote:
>> From: Jesse Brandeburg <[EMAIL PROTECTED]>
>>
>> there is missing support in ethtool for reporting 1baseT
>> as SUPPORTED_1baseT_Full. The code seems to be half
>> implemented because the "advertising" field has the implementation.
>
> I reported
David Acker wrote:
> On the systems that have cache incoherent DMA, including ARM, there is a
> race condition between software allocating a new receive buffer and hardware
> writing into a buffer. The two race on touching the last Receive Frame
> Descriptor (RFD). It has its el-bit set and its n
David Acker wrote:
> On the systems that have cache incoherent DMA, including ARM, there is a
> race condition between software allocating a new receive buffer and hardware
> writing into a buffer. The two race on touching the last Receive Frame
> Descriptor (RFD). It has its el-bit set and its n
Joe Perches wrote:
> Minimal macro to function conversion in e1000_ethtool.c
>
> Adds functions reg_pattern_test and reg_set_and_check
> Changes REG_PATTERN_TEST and REG_SET_AND_CHECK macros
> to call these functions.
>
> Saves ~2.5KB
>
> Compiled x86, untested (no hardware)
>
> old:
>
> $ siz
David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 22:20:30 -0400
>
>> David Miller wrote:
>>> From: Jeff Garzik <[EMAIL PROTECTED]>
>>> Date: Tue, 23 Oct 2007 21:03:36 -0400
>>>
I'm wondering if there is a way to avoid adding
if (!is_valid_ether
Joe Perches wrote:
> Add functions for reg_pattern_test and reg_set_and check
> Changed macros to use these functions
>
> Compiled x86, untested
>
> Size decreased ~2K
>
> old:
>
> $ size drivers/net/e1000e/ethtool.o
>textdata bss dec hex filename
> 14461 0 0
Joe Perches wrote:
> On Wed, 2007-10-31 at 14:30 -0700, Kok, Auke wrote:
>> Joe Perches wrote:
>> that's not a bad idea, however see below:
>> can't we keep the macro here (and just make it call the function instead of
>> expanding). the resulting code is muc
Joe Perches wrote:
> Convert REG_PATTERN_TEST and REG_SET_AND_CHECK macros to functions
> Reduces x86 defconfig image by about 3k
>
> compiled, untested (no hardware)
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> New:
>
> $ size vmlinux
>textdata bss dec hex filenam
Andy Gospodarek wrote:
> Auke,
>
> It has become clear that this patch resolves some tx-lockups on the ixgb
> driver. IBM did some checking and realized this hunk is in your
> sourceforge driver, but not anywhere else. Mind if we add it?
I'll quickly double check where this came from in the fi
Jeff Garzik wrote:
> Auke Kok wrote:
>> Since data can never exceed u32, it can't even be larger than
>> LONG_MAX/HZ.
>>
>> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
>> Cc: [EMAIL PROTECTED]
>> ---
>>
> Two comments:
>
> 1) I would prefer to pick a sane limit, like "1 day". The unit of
> 'data'
David A. Ranch wrote:
>>> e1000 is being frozen in time as "pre-PCI Express e1000's".
>>
> Asking the question a different way, will the current e1000 driver
> continue to get new features, performance / power / optimization tweaks,
> etc. or is most of the primary development be moving only o
Stephen Hemminger wrote:
> On Fri, 26 Oct 2007 15:10:28 -0700
> Auke Kok <[EMAIL PROTECTED]> wrote:
>
>> Trivial replacement - use INT_MAX instead here.
>>
>> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
>> Cc: [EMAIL PROTECTED]
>
> Acked-by: Stephen Hemminger <[EMAIL PROTECTED]>
>
> Sure that wo
Roel Kluin wrote:
> Kok, Auke wrote:
>
>> Ack this e1000e change here!
>
>> (PS since there was only 1 netdriver patch here and the rest is wireless, I
>> would
>> have suggested splitting this patch up in two and sending them to the
>> wireless
Roel Kluin wrote:
> A few patches with changes to net code. I have sent these to the lkml
> previously, but they were not yet merged. I am fairly new to kernel
> programming, so it is possible that I make some mistakes. I'll explain my
> rationale, please nack if incorrect, an additional bit of ex
Jeff Garzik wrote:
> Bill Davidsen wrote:
>> Adrian Bunk wrote:
>>> This patch contains the planned removal of the eepro100 driver.
>>>
>> Are the e100 people satisfied that e100 now handles all known cases? I
>
> Nope. There are still e100 work outstanding that means we cannot kill
> eepro100.
Auke Kok wrote:
> Fix allocation and freeing of jumbo frames where several bugs
> were recently introduced by cleanups after we forked this code
> from e1000. This moves ps_pages to buffer_info where it really
> belongs and makes it a dynamically allocated array. The penalty
> is not that high sinc
David Miller wrote:
> From: Dave Jones <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 17:20:26 -0400
>
>> Indeed. This is a common enough problem that not including it causes
>> more pain than its worth. I have two affected boxes myself that I
>> actually thought the hardware was dead before I trie
Dave Jones wrote:
> On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
>
> > > In any case, this patch should not be merged. We often send it around to
> users to
> > > debug their issue in case it involves eeproms, but merging it will just
> conceal
> > > the real issue and all of
1 - 100 of 500 matches
Mail list logo
