On 12/17/2018 3:29 AM, Paul E. McKenney wrote:
As does this sort of report on a line that contains simple integer
arithmetic and boolean operations.;-)
Any chance of a bisection?
btw this looks like something caused a stack overflow and thus all the
weirdness that then happens
It sounds like Coverity was used to produce these patches? If so, is
there a plan to have smatch (hey Dan) or other open source static
analysis tool be possibly enhanced to do a similar type of work?
I'd love for that to happen; the tricky part is being able to have even a
sort of sensible conce
On Sat, 16 Feb 2008 11:26:18 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > indirect functions calls are everywhere in kernel, network, fs,
> > everywhere.
>
> That doesn't make them fast.
just to emphasize this: an indirect function call is at least as expensive as
an atomic operation on
Johannes Berg wrote:
Rank 1: __ieee80211_rx
Warning at net/mac80211/rx.c:1672
Reported 6 times (11 total reports)
Same issue that was ranked 2nd last week
Johannes has diagnosed this as a driver bug in the iwlwifi drivers
More info: http://www.kerneloops.or
Linus Torvalds wrote:
On Tue, 8 Jan 2008, Arjan van de Ven wrote:
the database has the information so it's just a matter of slightly different
php code ;)
Before I do that... do you want the BUG's separate, part of the warnings or
part of the oopses?
(I rather make this change onc
Linus Torvalds wrote:
Cool.
One thing I wonder about - could you separate out the bug-ons and warnings
from the oopses? They really are different issues, and an oops with
register information etc is very different from a BUG() with line numbers,
which in turn is very different from a WARN_ON(
Randy Dunlap wrote:
(You can do it other and smarter ways too, I'm not claiming that's a
particularly good way to do it, and the old "ksymoops" program used to do
a pretty good job of this, but I'm used to that particular idiotic way
myself, since it's how I've basically always done it)
One
Andi Kleen wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
Rank 4: remove_proc_entry
Was also ranked 4th last week
Only in tainted oopses
Reported 3 times (12 total reports)
More info: http://www.kerneloops.org/search.php?search=remove_proc_entry
Li
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in
Linus Torvalds wrote:
On Sat, 29 Dec 2007, Arjan van de Ven wrote:
It has been a quiet week due to the holidays, only 55 oops traces
have been collected.
This would be more useful if it was more readable. As it is, you seem to
have some formatting errors in your automation, where the things
Linus Torvalds wrote:
On Sat, 29 Dec 2007, Arjan van de Ven wrote:
It has been a quiet week due to the holidays, only 55 oops traces
have been collected.
This would be more useful if it was more readable. As it is, you seem to
have some formatting errors in your automation, where the things
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in
Andi Kleen wrote:
Arjan van de Ven <[EMAIL PROTECTED]> writes:
Rank 8: __change_page_attr
BUG at arch/x86/mm/pageattr_64.c:176
Reported 2 times
Reported this week for 2.6.24-rc5; history goes back to 2.6.15
There is no BUG on this line on 2.6.24-rc5.
The http://www.kerneloops.org website collects kernel oops and
warning reports from various mailing lists and bugzillas as well as
with a client users can install to auto-submit oopses.
Below is a top 10 list of the oopses collected in the last 7 days.
(Reports prior to 2.6.23 have been omitted in
Parag Warudkar wrote:
On Dec 20, 2007 2:22 PM, Kok, Auke <[EMAIL PROTECTED]> wrote:
ok, that's just bad and if there's no user-defineable limit to the deferral I
definately don't like this change.
Can I safely assume that any irq will cause all deferred timers to run?
I think even other cause
Kok, Auke wrote:
ok, that's just bad and if there's no user-defineable limit to the deferral I
definately don't like this change.
Can I safely assume that any irq will cause all deferred timers to run?
*on that cpu*. Timers are per cpu, as are interrupts. Just not per se the same
one ...
--
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 scheduled on the hour
* deferrable - tim
On Mon, 17 Dec 2007 20:28:00 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>
> btw, I cheerfully skipped all your spelling-fixes patches. Some will
> have stuck via subsystem maintainers but I have a secret "no spelling
> fixes unless they're end-user-visible" policy. That means I'll take
>
On Mon, 03 Dec 2007 09:24:15 +0100
Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote:
> > Stephen Hemminger wrote:.
> > >>
> > > I spoke too soon earlier, ndiswrapper builds and loads against
> > > current 2.6.24-rc3. Vmware and proprietary VPN
On Sat, 01 Dec 2007 15:21:12 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman wrote:
> > Stephen Hemminger <[EMAIL PROTECTED]> writes:
> > Sure. We keep the updated dev_get_by_ that takes a network
> > namespace parameter.
> ..
>
> And what should code be passing in when "# CON
On Mon, 26 Nov 2007 10:25:33 -0800
>
> Agreed. On first glance, I was intrigued but:
>
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
yes. about 120 bytes per symbol
> - does it cause bugs?
yes, bad apis are causing bugs
On Thu, 22 Nov 2007 03:43:06 +0100 (CET)
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> There seems to be rough consensus that the kernel currently has too
> many exported symbols. A lot of these exports are generally usable
> utility functions or important driver interfaces; but another large
> part
David Miller wrote:
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 18:28:56 +1000
Allright, so that's an out of tree userland thingy... (which may well
work on ppc too I suppose). Definitely not installed by default by my
distro so IRQs from the network cards on all x86
On Mon, 10 Sep 2007 15:38:23 +0100
Denys Vlasenko <[EMAIL PROTECTED]> wrote:
> On Monday 10 September 2007 15:51, Arjan van de Ven wrote:
> > On Mon, 10 Sep 2007 11:56:29 +0100
> > Denys Vlasenko <[EMAIL PROTECTED]> wrote:
> >
> > >
&g
On Mon, 10 Sep 2007 11:56:29 +0100
Denys Vlasenko <[EMAIL PROTECTED]> wrote:
>
> Well, if you insist on having it again:
>
> Waiting for atomic value to be zero:
>
> while (atomic_read(&x))
> continue;
>
and this I would say is buggy code all the way.
Not from a pure
exactly this same patch...
Acked-by: Arjan van de Ven <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 9 Sep 2007 19:02:54 +0100
Denys Vlasenko <[EMAIL PROTECTED]> wrote:
> Why is all this fixation on "volatile"? I don't think
> people want "volatile" keyword per se, they want atomic_read(&x) to
> _always_ compile into an memory-accessing instruction, not register
> access.
and ... why is
bnx2.c (incorrectly) sets current->state directly to
TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
all the code wants to do is an msleep so just make it do that instead...
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
--- linux-2.6.23-rc2/drivers/net/b
On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> On Fri, 17 Aug 2007 18:49:34 -0700
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> > > Tne network code does memset for
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> Tne network code does memset for 6 and 8 byte values, that can easily
> be optimized into simple assignments without string instructions.
so... question.
Why are we doing this by hand? Wouldn't gcc just generate this code in
the first
On Fri, 2007-08-17 at 12:49 -0700, Paul E. McKenney wrote:
> > > What about reading values modified in interrupt handlers, as in your
> > > "random" case? Or is this a bug where the user of atomic_read() is
> > > invalidly expecting a read each time it is called?
> >
> > the interrupt handler
On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:
> Linus Torvalds wrote:
>
> > - in other words, the *only* possible meaning for "volatile" is a purely
> >single-CPU meaning. And if you only have a single CPU involved in the
> >process, the "volatile" is by definition pointless
Hi,
please in the future send just one patch for this; there's no real
reason to split this up this finegrained...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
because this is done in
> alloc_netdev() already.
Looks good
Acked-by: Arjan van de Ven <[EMAIL PROTECTED]>
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
-
To unsubscri
Kok, Auke wrote:
Andi Kleen wrote:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
All,
Another update on e1000e. Many thanks to Jeff for helping out and
getting this going forward. The driver is unfortunately still too
large to post, so please use the URL's below to review:
Just some things I noti
> =
> [ INFO: inconsistent lock state ]
> 2.6.22 #1
> -
> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> (&rp->lock){++..}, at: [] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
this is
On Mon, 2007-07-30 at 21:23 -0400, jamal wrote:
> On Mon, 2007-30-07 at 21:17 -0400, jamal wrote:
>
> > Actually iirc, hpet is not even enabled in the
> > kernel -
>
> Sorry, i lied - the config file is on my laptop - it is enabled.
is it also on in the bios? (and if not, can you grab the patch
On Mon, 2007-07-30 at 18:37 -0700, David Miller wrote:
> There really isn't much that can be done by any of this. These issues
> exist because of hardware limitations, nobody bothered to build
> x86/x86_64 systems with a system wide TICK register that is both
> impervious to cpu frequence scaling
On Mon, 2007-07-30 at 21:10 -0400, jamal wrote:
> Folks,
>
> I have posted this before but got no good response and i havent had time
> to chase it.
> While doing some batching tests with pktgen and then with a simple
> client server app with udp, it does appear that the clock source used
> matte
Jeff Garzik wrote:
Friday was that he felt that a lot of the "ugly" stuff you complained
about will go away if there is a PCI-E/older split, the PCI-E cards
are more or less of the same "major generation", while pre-PCI-E is
different>
3) Looming over everything else, is I wonder if Intel ha
I reject the notion that a "flag day" switchover for a huge mass of
e1000 users is the correct path. I do not think that best serves Linux
users.
so the options we have is do it one pci id a time; and the suggestion
by others like Christoph has been to make the split at the PCI Express
swi
Jeff Garzik wrote:
Arjan van de Ven wrote:
I'd second this; also lets be honest and fair about things and use a
similar standard for all drivers; are we going to ask all driver
submitters to remove NAPI, TSO and other stuff? I would hope not. Are
That was merely a suggestion. My ge
Stephen Hemminger wrote:
I would really like to continue with my original plan that I posted that follows
Christoph's idea. I hope you can all agree with that so we can get on with this.
I think rather than having a meta-discussion, which always seems to degenerate
into finger pointing. Let's l
Jeff Garzik wrote:
It's simple logic: using machine integers are the easiest for the
compiler to Do The Right Thing, the easiest way to eliminate endian
problems, the easiest way for programmers to read and understand struct
alignment.
using integers pure is obviously natural..
but using int
Jeff Garzik wrote:
I'm not sure whether gcc is confused about ABI alignment or such, on
various platforms, but every time I look at the asm generated it is
/not/ equivalent to open-coded feature flags and bitwise logic. Often
it is demonstrably worse.
(I can imagine this being different if y
Jeff Garzik wrote:
always avoid bitfields. They generate horrible code, and endian
problems abound (though no endian problems are apparent here).
they generate no worse code than open coding the checks for these
feature flags...
That would be the logical assumption, but reality does not bea
>> +u32 alloc_rx_buff_failed;
+struct {
+unsigned int rx_csum_enabled:1;
+unsigned int msi_capable:1;
+unsigned int msi_enabled:1;
+unsigned int msix_capable:1;
+unsigned int msix_enabled:1;
+unsigned int imir_enabled
Matthew Garrett wrote:
On Sat, Jun 30, 2007 at 02:47:35PM +0300, Török Edvin wrote:
When the interface is down (or driver removed), the BroadCom 44xx card
remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is
On Sat, 2007-06-30 at 05:47 -0400, Jeff Garzik wrote:
> Francois Romieu wrote:
> > Jeff Garzik <[EMAIL PROTECTED]> :
> >> Arjan van de Ven wrote:
> >>>> +pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
> >>> ca
Kok, Auke wrote:
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into the kernel with the c
> + pci_write_config_byte(tp->pci_dev, PCI_LATENCY_TIMER, 0x40);
can you create a pci_set_latency_timer() for this please?
> +
> + if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
> + pci_write_config_byte(tp->pci_dev, PCI_CACHE_LINE_SIZE, 0x08);
and something for this as well?
-
Vlad Yasevich wrote:
Hm... This is another case of of two different sockets taking the same lock...
Arjan, did this every get fixed, or is the nested locking the right solution
to this?
for this specific case it's ok and the nested solution is right.
In the general case it's obviously not sa
On Mon, 2007-05-07 at 13:53 -0700, Rick Jones wrote:
> Folks -
>
> Is it a bug, or a feature that after changing a device's smp_affinity via
> echo
> "N" >> /proc/irq/M/smp_affinity that the new mask isn't visible via cat
> /proc/irq/M/smp_affinity until after actual interrupts are taken?\
tha
On Thu, 2007-04-05 at 10:44 +1000, Herbert Xu wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > Thanks Dave, there is a classic AB BA deadlock here.
> > We should break the dependency like this.
> >
> > Could someone who uses proxy ARP test this?
>
> Sorry Stephen, this isn't necessary.
On Thu, 2007-02-22 at 10:16 +0100, Peter Zijlstra wrote:
> On Wed, 2007-02-21 at 16:53 +0100, Arjan van de Ven wrote:
> > > Index: linux-2.6-git/kernel/softirq.c
> > > ===
> > > --- linux-2.6-git.orig/ke
> Index: linux-2.6-git/kernel/softirq.c
> ===
> --- linux-2.6-git.orig/kernel/softirq.c 2006-12-14 10:02:18.0
> +0100
> +++ linux-2.6-git/kernel/softirq.c2006-12-14 10:02:52.0 +0100
> @@ -209,6 +209,8 @@ asm
> I'm trying to figure out which processes have the most impact, I had already
> killed anything non-essential. But that still leaves 140 pids.
btw if you have systemtap on your system you can see who is doing evil
with
http://www.fenrus.org/cstop.stp
also.. running "vmstat 3" and looking at th
On Tue, 2007-01-30 at 19:44 -0800, Divy Le Ray wrote:
> Dual licensing, needed for OFED 1.2
Hi,
did you get permission from all the people who contributed code to your
driver ? If not.. that'd be a problem
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test t
On Sun, 2007-01-21 at 15:06 -0600, Jay Cliburn wrote:
> +
> + /* PCI config space info */
> + pci_read_config_byte(pdev, PCI_REVISION_ID, &hw->revision_id);
> + pci_read_config_word(pdev, PCI_COMMAND, &hw->pci_cmd_word);
I'm highly suspicious of drivers that use the PCI_COMMAND word...
ortunately you didn't provide your driver code or a link to it, so
people who want to help you would have to guess in the dark... could you
reply to this email with the pointer to the code?
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at
On Wed, 2006-12-27 at 09:44 -0500, jamal wrote:
> On Wed, 2006-27-12 at 14:08 +0100, Arjan van de Ven wrote:
>
> > sure; however the kernel doesn't provide more accurate information
> > currently (and I doubt it could even, it's not so easy to figure out
> > whi
> Although still insufficient in certain cases. All flows are not equal; as an
> example, an IPSEC flow with 1000 packets bound to one CPU will likely
> utilize more cycles than 5000 packets that are being plain forwarded on
> another CPU.
sure; however the kernel doesn't provide more accurate i
On Wed, 2006-12-27 at 00:52 -0800, Divy Le Ray wrote:
> Jeff,
>
> You can grab the monolithic patch at this URL:
> http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
>
> This patch adds support for the latest 1G/10G Chelsio adapter, T3.
> It is required by the T3 RDMA driver Steve Wise submitt
On Tue, 2006-12-26 at 17:46 -0500, jamal wrote:
> On Tue, 2006-26-12 at 23:06 +0100, Arjan van de Ven wrote:
>
> > it is; that's why irqbalance tries really hard (with a few very rare
> > exceptions) to keep networking irqs to the same cpu all the time...
> >
>
On Tue, 2006-12-26 at 13:44 -0500, jamal wrote:
> If you compile in PCI-E support you should have more control of the
> MSI-X, no? I would tie the MSI to a specific processor statically; my
> past experiences with any form of interupt balancing with network loads
> has been horrible.
it is; that'
On Mon, 2006-12-25 at 13:26 +0200, Robert Iakobashvili wrote:
>
> > Am I understanding you correctly that you want to spread the load of the
> > networking IRQ roughly equally over 2 cpus (or cores or ..)?
>
> Yes, 4 cores.
>
> > If so, that is very very suboptimal, especially for networking (si
ty you seem to want
is both not practical and too expensive anyway
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
-
To unsubscribe from th
> Using request_firmware assumes that the driver knows the FW file name
no it knows an ALIAS for it.
> and the driver initiates the load. That's not our model where we work
> with different FWs, don't know what the names are,
you can have the user make a symlink to the one he wants. No Big Deal
> Is there some reason why we can't have the OS just do the D3
> transition for all drivers that register support? I mean, this power
> management using D states is actually driver *independent* and at
> least way back in the day was supposed to be implemented for "OS power
> management"
all you
> They are used to parameter the HW:
> register access,
ethtool supports that, so shouldn't be an ioctl for sure
> configuration of queue sets, on board memory
> configuration,
I'm sure ethtool can do that too
> firmware load, etc ...
and for this we have request_firmware() interface.
add
On Wed, 2006-12-20 at 21:40 +0100, Benny Amorsen wrote:
> >>>>> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> AvdV> even if you have NO power savings you still don't meet your
> AvdV> criteria. That's basic ethernet f
On Wed, 2006-12-20 at 17:40 +0100, Olivier Galibert wrote:
> On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote:
> > 5 seconds is unfair and unrealistic though. The *hardware* negotiation
> > before link is seen can easily take upto 45 seconds already.
> > That
> Yeah, I guess that's a problem. From a user perspective, the
> functionality is only really useful if the latency is very small. I
> think where possible we'd want to power down the chip while keeping the
> phy up, but it would be nice to know how much power that would actually
> cost us.
On Wed, 2006-12-20 at 16:27 +0100, Olivier Galibert wrote:
> On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote:
> > [1] What kind of latency would be allowed? Would an implementation be
> > allowed to power up the phy say once per minute or once per 5 minutes to
>
> +void t3_port_intr_disable(struct adapter *adapter, int idx)
> +{
> + struct cphy *phy = &adap2pinfo(adapter, idx)->phy;
> +
> + t3_write_reg(adapter, XGM_REG(A_XGM_INT_ENABLE, idx), 0);
> + phy->ops->intr_disable(phy);
you seem to be missing a pci posting flush here
--
if yo
> +/*
> + * Interrupt handler for asynchronous events used with MSI-X.
> + */
> +static irqreturn_t t3_async_intr_handler(int irq, void *cookie)
> +{
> + t3_slow_intr_handler(cookie);
> + return IRQ_HANDLED;
> +}
this looks very wrong; why is t3_slow_intr_handler a void rather than
returni
about your driver list;
do you have an idea of what the top 5 relevant ones would be?
I'd be surprised if the top 5 together had less than 95% market share,
so if we fix those we'd be mostly done already.
> The situation is more complicated for wireless. Userspace expects to be
> able to get scan
t bugfixes; I don't think it's fair to hold these
hostage..
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff Garzik wrote:
ACK, though you can also just schedule the timer to run immediately, or
even run it yourself inside spin_lock_bh()
sure but this is very simple, clean and obvious ;)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECT
Jeff Garzik wrote:
They didn't get applied because the patches need the revisions I requested.
the patches I posted are cleaned up subset...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
Jeff Garzik wrote:
Arjan van de Ven wrote:
Hi,
this patch series contains critical bugfixes to the e1000 driver for
2.6.20 (and 3 very low intrusive features that help in testing). Without
these patches e1000 is totally unusable on my test machine.
Didn't Auke just submit these, and
lt;[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6/driver
urg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 43 +
1 file changed, 25 insertions(+), 16 deletions(-)
Index: linux-2.6/d
lt;[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_param.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers
BA was misallocated
in the old algorithm.
Signed-off-by: Bruce Allan <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.h |1
drivers/net/e
value. This caused 1.45Mpps
to be sent instead of 1.487Mpps.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |6 +++---
1 file changed, 3 in
oss of link. This loss of link breaks
Wake-on-Lan and IPMI.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 14 ++
1 fil
PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/driver
t used for performance sensitive
cases, the simplest fix is to disable TSO in this special situation.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main
cases. In addition, this parameter allows us
to force never/always during testing to get full and predictable coverage of
both code paths.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]&
m from appropriate locations. This fixes several
BMC packet redirect issues and powerup/down hiccups.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.c
by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c |3 +++
drivers/net/e1000/e1000_main.c|7 +++
2 files changed, 10 insertions(+)
Index: linux-2.6/drivers/n
EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |5 +
1 file changed, 5 insertions(+), 0 deletion(-)
Index: linux-2.6/drivers/net/e1000/e1000_main.c
===
--- li
Hi,
this patch series contains critical bugfixes to the e1000 driver for
2.6.20 (and 3 very low intrusive features that help in testing). Without
these patches e1000 is totally unusable on my test machine.
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubs
>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/drivers/net/e1000/e1000_hw.c
===
--- linux-2.6.orig/driv
off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6/drivers/net/e1000/e1000_main.c
=
Hi,
this patch removes the NETIF_F_TSO #ifdef-ery in drivers/net; this was
for old-old-2.4 compat (even current 2.4 has NETIF_F_TSO)
but it's time to get rid of it by now.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Index: linux-2.6/drivers
r
it? What guarantees that the readers of it don't get the value changed
underneath them between looking at the value and doing whatever action
depends on it's value ?
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test th
On Sun, 2006-12-03 at 19:36 +0100, Ivo van Doorn wrote:
> +
> + down(&master->key_sem);
> +
Hi,
this one seems to be used as a mutex only, please consider using a mutex
instead, as is the default for new code since 2.6.16 or so
Greetings,
Arjan van de Ven
--
if
On Sat, 2006-12-02 at 16:49 -0600, Steve Wise wrote:
> +
> +static struct ib_ah *iwch_ah_create(struct ib_pd *pd,
> + struct ib_ah_attr *ah_attr)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
-ENOSYS is just about ALWAYS a bug in that it's guaranteed to be the
wrong
1 - 100 of 195 matches
Mail list logo
