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
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
x86
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:
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
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
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 once ;)
I'd
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
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
Likely
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. Since
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 -
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 ...
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 causes
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
spelling
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 software
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 # CONFIG_NET_NS is
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 are
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
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 C level
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:
Well, if you insist on having it again:
Waiting for atomic value
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 that?
is
...
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
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/bnx2.c.org
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 (because
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 case is an SMP
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 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 6 and 8 byte values, that can easily
be optimized
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
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 unsubscribe from this list: send the line unsubscribe netdev in
the body
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
=
[ 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: [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
this is a
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
matters.
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: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 patches to
Jeff Garzik wrote:
I'll leave the first two to Auke; the discussion I had with Auke on
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
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
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 general
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
+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
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
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
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
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);
can you create a pci_set_latency_timer() for this please?
[...]
+if (tp
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
+ 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?
-
To
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
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
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?\
that's known
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. The lockdep
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 @@
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 the
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
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...
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) linux.intel.com
Test the interaction between Linux and your BIOS via
http://www.linuxfirmwarekit.org
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 submitted.
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
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
which interface triggered the softirq if 2
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's
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...
The problem with irqbalance when i last
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 this list: send the line unsubscribe netdev in
the body
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 (since
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.
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.
adding
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 need
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
+/*
+ * 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
returning
+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 you want to
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
see if there is link
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.
I'm
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's a network topology/hardware
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 for you
AvdV That's what I was trying to say; your criteria is unrealistic
-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
===
--- linux-2.6.orig/drivers/net/e1000
[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/net/e1000/e1000_ethtool.c
. 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]
---
drivers/net/e1000
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 |5 -
drivers/net/e1000
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.c |6 ++
1 file changed
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 file changed, 14 insertions(+)
Index
-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/drivers/net/e1000/e1000_main.c
. 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 insertions(+), 3 deletions
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/net/e1000/e1000_param.c
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/e1000/e1000_main.c | 99 +++--
2
]
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/drivers/net/e1000/e1000_main.c
]
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/drivers/net/e1000/e1000_main.c
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 have
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
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
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
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/net/bnx2.c
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 error
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 you want to mail me
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 the interaction between Linux and your BIOS
On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
Now that it seems to be ok to use these openbsd sources, should I port
them to my driver framework?
I looked over the ar5k code and, well, I don't like it. ;)
I
On Tue, 2006-11-07 at 10:32 -0800, Tim Chen wrote:
The patch
[TCP]: Send ACKs each 2nd received segment
commit: 1ef9696c909060ccdae3ade245ca88692b49285b
http://kernel.org/git/?
p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ef9696c909060ccdae3ade245ca88692b49285b
reduced
On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
The ipw3945 driver has been out for a while and is not yet upstream.
It requires a binary only daemon to work, but I still see no reason not
to merge it.
Many wlan drivers require binary firmware anyway, so I don't see a
reason not to merge
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: round_jiffies users
CC: [EMAIL PROTECTED]
CC: netdev@vger.kernel.org
This patch introduces users of the round_jiffies() function in the networking
code.
These timers all were of the about once a second or about once every X
seconds
variety
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: round_jiffies users
CC: [EMAIL PROTECTED]
CC: netdev@vger.kernel.org
This patch introduces users of the round_jiffies() function.
These timers all were of the about once a second or about once every X
seconds
variety and several showed up
On Tue, 2006-10-10 at 18:47 +0200, Ingo Oeser wrote:
Hi Arjan,
Arjan van de Ven wrote:
Index: linux-2.6.19-rc1-git6/mm/slab.c
===
--- linux-2.6.19-rc1-git6.orig/mm/slab.c
+++ linux-2.6.19-rc1-git6/mm/slab.c
@@ -926,7
Paul Dickson wrote:
On Tue, 10 Oct 2006 18:04:23 +0200, Arjan van de Ven wrote:
+ mod_timer(adapter-phy_info_timer,
round_jiffies(jiffies + 2 * HZ));
Shouldn't round_jiffies_relative be used for some of these, a la:
+ mod_timer(adapter
(interrupts get enabled
unconditionally) so it is generally safer to use
spin_lock_irqsave()/spin_unlock_irqrestore() API.
If you have more questions please do not hesitate to ask!
Greetings,
Arjan van de Ven
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
);
+ }
hmm some places take phy_lock with disabling interrupts, while others
don't. I sort of fear the others may be buggy are you sure those
are ok?
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
1 - 100 of 179 matches
Mail list logo
