Writing BMCR_RESET bit will reset MII_BMCR to default values. This is
clearly not what we want.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
drivers/net/phy/phy_device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: work-powerpc.git/drivers/net/phy/phy_device.c
===
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile" generally screws up is a simple
>
On Fri, 17 Aug 2007, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
> >
> > The cost of doing so seems to me to be well down in the noise - 44
> > bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> > the extra few cycles for the occasional
Hi Dave,
> I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will
> run a longer one tonight). The results are (results in KB/s, and %):
I ran a 8.5 hours run with no batching + another 8.5 hours run with
batching (Buffer sizes: "32 128 512 4096 16384", Threads: "1 8 32",
Each test
Hi Linus,
[ and others; I think there's a communication gap in a lot of this
thread, and a little summary would be useful. Hence this posting. ]
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I tr
Herbert Xu writes:
> On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> > Herbert Xu writes:
> >
> > > Can you find an actual atomic_read code snippet there that is
> > > broken without the volatile modifier?
> >
> > There are some in arch-specific code, for example line 1073 of
>
On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > Can you find an actual atomic_read code snippet there that is
> > broken without the volatile modifier?
>
> There are some in arch-specific code, for example line 1073 of
> arch/mips/kernel/smtc.c. On mips
On Thu, Aug 16, 2007 at 08:42:23PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I tried it on powerpc
> > and it only saved 40 bytes (10 instructions) for a G5 config.
>
> One of the things that "volatile" g
Herbert Xu writes:
> Can you find an actual atomic_read code snippet there that is
> broken without the volatile modifier?
There are some in arch-specific code, for example line 1073 of
arch/mips/kernel/smtc.c. On mips, cpu_relax() is just barrier(), so
the empty loop body is ok provided that at
On Fri, Aug 17, 2007 at 09:28:00AM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
> >
> > Yep. Or you can use atomic_dec_return() instead of using a barrier.
>
> Or you could use smp_mb__{before,after}_atomic_dec.
Yep. That would be an example of a
Herbert Xu writes:
> So the point here is that if you don't mind getting a stale
> value from the CPU cache when doing an atomic_read, then
> surely you won't mind getting a stale value from the compiler
> "cache".
No, that particular argument is bogus, because there is a cache
coherency protocol
Paul Mackerras wrote:
Nick Piggin writes:
Why are people making these undocumented and just plain false
assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
Hmm, although I don't think it has ever been guara
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Here, I should obviously admit that the semantics of *(volatile int *)&
> > aren't any neater or well-defined in the _language standard_ at all. The
> > standard does say (verbatim) "precisely what constitutes as access to
> > object of volatile
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Note that "volatile"
> > is a type-qualifier, not a type itself, so a cast of the _object_ itself
> > to a qualified-type i.e. (volatile int) would not make the access itself
> > volatile-qualified.
>
> There is no such thing as "volatile-quali
Nick Piggin writes:
> Why are people making these undocumented and just plain false
> assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
> If they're using lockless code (ie.
> which they must be if using atomics
On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
>
> The cost of doing so seems to me to be well down in the noise - 44
> bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> the extra few cycles for the occasional extra load would be measurable
> (they should all h
On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> I'm surprised too. Numbers were from the "...use asm() like the other
> atomic operations already do" thread. According to them,
>
> textdata bss dec hex filename
> 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
> 3436
Linus Torvalds writes:
> In general, I'd *much* rather we used barriers. Anything that "depends" on
> volatile is pretty much set up to be buggy. But I'm certainly also willing
> to have that volatile inside "atomic_read/atomic_set()" if it avoids code
> that would otherwise break - ie if it hi
On Fri, 17 Aug 2007, Paul Mackerras wrote:
>
> I'm really surprised it's as much as a few K. I tried it on powerpc
> and it only saved 40 bytes (10 instructions) for a G5 config.
One of the things that "volatile" generally screws up is a simple
volatile int i;
i++;
which a c
Paul Mackerras wrote:
Nick Piggin writes:
So i386 and x86-64 don't have volatiles there, and it saves them a
few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions) f
Nick Piggin writes:
> So i386 and x86-64 don't have volatiles there, and it saves them a
> few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions) for a G5 config.
Paul.
-
Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 06:42:50PM +0800, Herbert Xu wrote:
In fact, volatile doesn't guarantee that the memory gets
read anyway. You might be reading some stale value out
of the cache. Granted this doesn't happen on x86 but
when you're coding for the kernel you can't
On Fri, 17 Aug 2007, Paul Mackerras wrote:
>
> Volatile doesn't mean it can't be reordered; volatile means the
> accesses can't be eliminated.
It also does limit re-ordering.
Of course, since *normal* accesses aren't necessarily limited wrt
re-ordering, the question then becomes one of "with
Christoph Lameter writes:
> No it does not have any volatile semantics. atomic_dec() can be reordered
> at will by the compiler within the current basic unit if you do not add a
> barrier.
Volatile doesn't mean it can't be reordered; volatile means the
accesses can't be eliminated.
Paul.
-
To
Chris Snook wrote:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start
Segher Boessenkool wrote:
Part of the motivation here is to fix heisenbugs. If I knew where
they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would f
On Thu, Aug 16, 2007 at 10:04:24PM -0400, Chris Snook wrote:
>
> >Could you please cite the file/function names so we can
> >see whether removing the barrier makes sense?
>
> At a glance, several architectures' implementations of smp_call_function()
> have one or more legitimate atomic_read() bus
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we start removing barriers that
On Thu, Aug 16, 2007 at 06:02:32PM -0700, Paul E. McKenney wrote:
>
> Yep. Or you can use atomic_dec_return() instead of using a barrier.
Or you could use smp_mb__{before,after}_atomic_dec.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
H
On Thu, Aug 16, 2007 at 01:20:26PM -0700, Christoph Lameter wrote:
> On Thu, 16 Aug 2007, Chris Snook wrote:
>
> > atomic_dec() already has volatile behavior everywhere, so this is
> > semantically
> > okay, but this code (and any like it) should be calling cpu_relax() each
> > iteration through
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
> >
> > The compiler can also reorder non-volatile accesses. For an example
> > patch that cares about this, please see:
> >
> > http://lkml.org/lkml/2007/8/7/280
>
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
>
> >Can you find an actual atomic_read code snippet there that is
> >broken without the volatile modifier?
>
> A whole bunch of atomic_read uses will be broken without the volatile
> modifier once we start removing barriers that aren't
On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
>
> The compiler can also reorder non-volatile accesses. For an example
> patch that cares about this, please see:
>
> http://lkml.org/lkml/2007/8/7/280
>
> This patch uses an ORDERED_WRT_IRQ() in rcu_read_lock() and
> rcu_r
On Thu, Aug 16, 2007 at 05:40:44PM +0200, Eric Dumazet wrote:
>
> So do you think this patch is enough or should we convert dst_run_gc
> processing from softirq to workqueue too ?
I think a workqueue would be the best solution since with
that you wouldn't have to worry about processing things in
On 8/16/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> The problem with socket options is how does the application know
> the correct policy? Pushing configuration to application is just deferring
> the problem, not solving it. You want some policy to be done by the
> infrastructure; that mean
On Thu, 16 Aug 2007 12:21:14 -0700
"Luis Carlos Cobo" <[EMAIL PROTECTED]> wrote:
> On 7/30/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > it would need an IP ttl to mesh mapping. The fundamental thing is to try
> > and avoid topology specific options bleeding all the way up the socket
> > l
From: Tom Tucker <[EMAIL PROTECTED]>
Date: Thu, 16 Aug 2007 08:43:11 -0500
> Isn't RDMA _part_ of the "software net stack" within Linux?
It very much is not so.
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've
>> 6674: while (atomic_read(&j->DSPWrite) > 0)
>> 6675- atomic_dec(&j->DSPWrite);
>
> If the maintainer of this code doesn't see a compelling reason to add
> cpu_relax() in this loop, then it should be patched.
Shouldn't it be just re-written without the loop:
if ((tmp = atom
I did some testing today and found that the error occurs after
applying some of the patches. However I did not figure out the exact
patch in which the error "starts" since it sometimes occurs immediatly
when moving some data over the net and sometimes it takes 30 min till
I get the transmit timeout
Here, I should obviously admit that the semantics of *(volatile int *)&
aren't any neater or well-defined in the _language standard_ at all.
The
standard does say (verbatim) "precisely what constitutes as access to
object of volatile-qualified type is implementation-defined", but GCC
does help u
Note that "volatile"
is a type-qualifier, not a type itself, so a cast of the _object_
itself
to a qualified-type i.e. (volatile int) would not make the access
itself
volatile-qualified.
There is no such thing as "volatile-qualified access" defined
anywhere; there only is the concept of a "vo
I can't speak for this particular case, but there could be similar
code
examples elsewhere, where we do the atomic ops on an atomic_t object
inside a higher-level locking scheme that would take care of the kind
of
problem you're referring to here. It would be useful for such or
similar
code if
On Thu, 16 Aug 2007, Chris Snook wrote:
> atomic_dec() already has volatile behavior everywhere, so this is semantically
> okay, but this code (and any like it) should be calling cpu_relax() each
> iteration through the loop, unless there's a compelling reason not to. I'll
> allow that for some h
On Thu, 16 Aug 2007 12:24:05 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8895
>
>Summary: An ioctl to delete an ipv6 tunnel leads to a kernel
> panic
>Product: Networking
>Version: 2.5
> KernelVersi
On Thu, Aug 16, 2007 at 11:54:54AM -0700, Christoph Lameter wrote:
> On Thu, 16 Aug 2007, Paul Mackerras wrote:
> > So I don't see any good reason to make the atomic API more complex by
> > having "volatile" and "non-volatile" versions of atomic_read. It
> > should just have the "volatile" behavio
Ilpo Järvinen wrote:
On Thu, 16 Aug 2007, Herbert Xu wrote:
We've been through that already. If it's a busy-wait it
should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
./drivers/
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
Do you (or anyone else for that matter) have an example of this?
The only code I somewhat know, the ieee1394 subsystem, was perhaps
authored and is currently maintained with the expectation that each
occurrence of
Ilpo Järvinen wrote:
On Thu, 16 Aug 2007, Herbert Xu wrote:
We've been through that already. If it's a busy-wait it
should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
./drivers/
I'd go so far as to say that anywhere where you want a non-"volatile"
atomic_read, either your code is buggy, or else an int would work just
as well.
Even, the only way to implement a "non-volatile" atomic_read() is
essentially as a plain int (you can do some tricks so you cannot
assign to the r
Folks -
I was trying to look at bonding vs discrete links and so put a couple dual-port
e1000-driven NICs:
4a:01.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet
Controller (rev 03)
Subsystem: Hewlett-Packard Company HP Dual Port 1000Base-T [A9900A]
into a pair of 8
The only thing volatile on an asm does is create a side effect
on the asm statement; in effect, it tells the compiler "do not
remove this asm even if you don't need any of its outputs".
It's not disabling optimisation likely to result in bugs,
heisen- or otherwise; _not_ putting the volatile on a
Part of the motivation here is to fix heisenbugs. If I knew where
they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would find disabling all compiler
op
On 7/30/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> it would need an IP ttl to mesh mapping. The fundamental thing is to try
> and avoid topology specific options bleeding all the way up the socket layer,
> especially since the network layer is involved and may need to multipath.
I think th
On Thu, 16 Aug 2007, Paul Mackerras wrote:
> The uses of atomic_read where one might want it to allow caching of
> the result seem to me to fall into 3 categories:
>
> 1. Places that are buggy because of a race arising from the way it's
>used.
>
> 2. Places where there is a race but it doesn
On Thu, 16 Aug 2007, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > It doesn't matter. The memory pressure flag is an *advisory*
> > flag. If we get it wrong the worst that'll happen is that we'd
> > waste some time doing work that'll be thrown away.
>
> Ah, so it's the "racy but I don't car
On Thu, 16 Aug 2007, Paul Mackerras wrote:
>
> It seems that there could be a lot of places where atomic_t is used in
> a non-atomic fashion, and that those uses are either buggy, or there
> is some lock held at the time which guarantees that other CPUs aren't
> changing the value. In both cases
Tejun Heo wrote:
Brandon Philips wrote:
- mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
You don't need mmio_len either.
- err = -EIO;
- adapter->hw.hw_addr = ioremap(mmio_start, mmio_len);
+ adapter->hw.hw_addr = pcim_
> Now if I insert a return -ENOMEM right after allocating tx_ring:
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -1356,6 +1356,8 @@ e1000_alloc_queues(struct e1000_adapter
> *adapter) {
> adapter->tx_ring = kcalloc(adapter->num_tx_queues,
>
On 01:38 Thu 16 Aug 2007, Waskiewicz Jr, Peter P wrote:
> > - err = -ENOMEM;
> > - netdev = alloc_etherdev(sizeof(struct e1000_adapter));
> > + netdev = devm_alloc_etherdev(&pdev->dev, sizeof(struct
> > +e1000_adapter));
> > if (!netdev)
> > - goto err_alloc_etherdev;
> > +
On Thu, Aug 16, 2007 at 10:16:08AM +0200, Laurent Pinchart wrote:
> This patch adds a flag to the DM9000 platform data which, when set,
> configures the device to use an external PHY.
>
> Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
Acked-by: Ben Dooks <[EMAIL PROTECTED]>
> ---
> drivers/n
On Thu, Aug 16, 2007 at 10:15:35AM +0200, Laurent Pinchart wrote:
> This patch splits the receive status in 8bit wide fields and convert the
> packet length from little endian to CPU byte order.
>
> Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
Acked-by: Ben Dooks <[EMAIL PROTECTED]>
> ---
>
On Thu, Aug 16, 2007 at 06:42:50PM +0800, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 12:31:03PM +0200, Stefan Richter wrote:
> >
> > PS: Just to clarify, I'm not speaking for the volatile modifier. I'm
> > not speaking for any particular implementation of atomic_t and its
> > accessors at all.
A Fedora users reported this against our 2.6.23-rc3 build
Dave
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0
On Wed, Aug 15, 2007 at 05:40:11PM -0700, Joe Perches wrote:
> $ egrep -r --include=*.c "\bif[[:space:]]*\([^\)]*\)[[:space:]]*\;" *
> arch/sh/boards/se/7343/io.c:if (0) ;
> drivers/atm/iphase.c: if (!desc1) ;
> drivers/infiniband/hw/mlx4/mad.c: if (!err);
> drivers/isdn/capi/capiuti
Ilpo Järvinen wrote:
> I looked around a bit by using some command lines and ended up wondering
> if these are equal to busy-wait case (and should be fixed) or not:
>
> ./drivers/telephony/ixj.c
> 6674: while (atomic_read(&j->DSPWrite) > 0)
> 6675- atomic_dec(&j->DSPWrite);
>
> ...be
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
>
> There seem to be some unbalanced rcu_read_{,un}lock() issues of late,
> how about doing something like this:
This will break when rcu_read_lock() and rcu_read_unlock() are invoked
from NMI/SMI handlers -- the raw_local_irq_save()
* Richard MUSIL <[EMAIL PROTECTED]> 2007-07-24 13:09
> Thomas Graf wrote:
> > Please provide a new overall patch which is not based on your
> > initial patch so I can review your idea properly.
>
> Here it goes (merging two previous patches). I have diffed
> against v2.6.22, which I am using curre
On 20:34 Thu 16 Aug 2007, Tejun Heo wrote:
> Brandon Philips wrote:
> > @@ -2554,8 +2547,10 @@ static int __devinit e100_probe(struct p
> > struct net_device *netdev;
> > struct nic *nic;
> > int err;
> > + void __iomem **iomap;
> > + int bar;
> >
> > - if(!(netdev = alloc_ether
On Thu, 16 Aug 2007 21:59:43 +0800
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> > Yes, I already did this (with the current softirq based timer model),
> > but how can dst_dev_event() do its work, since the GC is using
> > a private list. (In my patch, ti
On Wed, Aug 15, 2007 at 05:40:11PM -0700, Joe Perches wrote:
> fs/hostfs/hostfs_user.c:if(attrs->ia_valid & HOSTFS_ATTR_CTIME) ;
This one can be deleted, but I think I did it for documentation
reasons, to make it clear that ctime handling wasn't left out by
mistake.
On Wed, 2007-08-15 at 11:18 +0200, Johannes Berg wrote:
> There is no point in trying to handle source MAC address based VLANs in
> the wireless stack, something like "smacvlan" modeled after macvlan
> should be sufficient.
Whoops. I only forgot the use with encryption. Please consider this
patch
On Thu, 16 Aug 2007, Herbert Xu wrote:
> We've been through that already. If it's a busy-wait it
> should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
./drivers/telephony/ixj.c
6674:
There seem to be some unbalanced rcu_read_{,un}lock() issues of late,
how about doing something like this:
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/lockdep.h |7 +++
include/linux/rcupdate.h | 12
kernel/rcupdate.c|8
3 file
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> Yes, I already did this (with the current softirq based timer model),
> but how can dst_dev_event() do its work, since the GC is using
> a private list. (In my patch, time to GC process XXX.000 entries is about XX
> seconds.)
>
> We would have to chan
(please do not remove the netdev Cc:)
Francois Romieu <[EMAIL PROTECTED]> :
[...]
> If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944
> tomorrow.
You will find a tgz archive in attachment which contains a serie of patches
(0001-... to 0005-...) to walk from 6dccd16b7c2703e
Kok, Auke wrote:
> Joe Perches wrote:
>> On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote:
>>> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
>>>
>>> diff --git a/drivers/infiniband/hw/mlx4/mad.c
>>> b/drivers/infiniband/hw/mlx4/mad.c
>>> index 3330917..0ed02b7 100644
>>> --- a/drivers/infiniband
From: Marcus Meissner <[EMAIL PROTECTED]>
Use correct array index (goes from 0-6 instead of 10-16).
Signed-Off-By: Marcus Meissner <[EMAIL PROTECTED]>
---
drivers/net/tokenring/3c359.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tokenring/3c359.c b/drive
On Wed, 2007-08-15 at 22:26 -0400, Jeff Garzik wrote:
[...snip...]
> > I think removing the RDMA stack is the wrong thing to do, and you
> > shouldn't just threaten to yank entire subsystems because you don't like
> > the technology. Lets keep this constructive, can we? RDMA should get
> > t
Trivial patch, move netdev_budget declaration out of netdevice.h
to a new home with the other sysctl externs.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/netdevice.h 2007-08-16 06:38:33.0 -0400
+++ b/include/linux/netdevice.h 2007-08-16 09:24:08.0 -040
On Thu, 16 Aug 2007 20:41:58 +0800
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Eric Dumazet <[EMAIL PROTECTED]> wrote:
> >
> > I am wondering how to really solve the problem. Could a workqueue be used
> > here instead of a timer ?
>
> I think so.
>
> A mutex would separate the GC and dst_ifdown. Y
Deinline dev_kfree_skb_irq. This saves about 100bytes per call
site on UP, probably more on SMP.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/netdevice.h 2007-08-06 09:26:41.0 +0100
+++ b/include/linux/netdevice.h 2007-08-15 14:12:32.0 +0100
@@ -793,29 +
Remove unneeded declaration.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/netdevice.h 2007-08-15 14:29:02.0 +0100
+++ b/include/linux/netdevice.h 2007-08-15 14:35:25.0 +0100
@@ -833,8 +833,6 @@ extern int dev_set_mac_address(struct n
extern in
These cleanups should go in 2.6.24. Hope they don't conflict too bad
with the NAPI stuff.
--
-
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
Since we now have internal stats, it cleans up code to have a
dev_get_stats() interface. This allows for future patches where
'network device ops' patch where get_stats is immutable.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/netdevice.h 2007-08-16 06:34:25.
On Wed, 15 Aug 2007 21:20:37 + (UTC)
Sébastien Judenherc <[EMAIL PROTECTED]> wrote:
> Hello,
> I can see some very strange problem with sky2 and skge interfaces with 2.6.22,
> and also 2.6.23-rc2/3.
> After 8-9 minutes, the interfaces stop working. ethtool reports that the link
> is
> down a
backport of commit 55d7b4e6ed6ad3ec5e5e30b3b4515a0a6a53e344
Make sky2 handle carrier similar to other drivers,
eliminate some possible races in carrier state transistions.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-08 22:01:00.0 +
Backport of commit 5c11ce700f77fada15b6264417d72462da4bbb1c
This patch avoids generating another IRQ if more packets
arrive while in the NAPI poll routine. Before marking device as
finished, it rechecks that the status ring is empty.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
-
Backport of commit 71749531f2d1954137a1a77422ef4ff29eb102dd
If packet larger than MTU is received, the driver uses hardware to
truncate the packet. Use the status registers to catch/drop them.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-08
These are bugfixes that happened late in 2.6.22 cycle that missed
getting merged.
--
-
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
Backport of commit c59697e06058fc2361da8cefcfa3de85ac107582
This patch restores a couple of workarounds from 2.6.16:
* restart transmit moderation timer in case it expires during IRQ routine
* default to having 10 HZ watchdog timer.
At this point it more important not to hang than to worry about
On Thu, 16 Aug 2007 10:25:45 +0200
"Michal Piotrowski" <[EMAIL PROTECTED]> wrote:
> [Adding Stephen and netdev to CC]
>
> On 15/08/07, James Corey <[EMAIL PROTECTED]> wrote:
> >
> > I tried running a D-link gig card on kernel 2.6.21.1
> > and it came up fine, but when I did a sftp of
> > an linux
Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> I am wondering how to really solve the problem. Could a workqueue be used
> here instead of a timer ?
I think so.
A mutex would separate the GC and dst_ifdown. You'd take the
spin lock in the GC only to replace the garbage list with NULL.
You then dro
Hi Ilpo,
On Thu, 16 Aug 2007, Ilpo Järvinen wrote:
>
> ...I guess those guys hunting for broken busyloops in the other thread
> could also benefit from similar searching commands introduced in this
> thread... ...Ccing Satyam to caught their attention too.
>
>
> > On Wed, Aug 15, 2007 at 05
Hi all
When the periodic route cache flush is done, this machine suffers a lot and
eventually triggers the "soft lockup" message.
dst_run_gc() is doing a scan of a possibly huge list of dst_entries, eventually
freeing some (less than 1%) of them, but holding the dst_lock spinlock for the
whole
Brandon Philips wrote:
> - mmio_start = pci_resource_start(pdev, BAR_0);
> mmio_len = pci_resource_len(pdev, BAR_0);
You don't need mmio_len either.
> - err = -EIO;
> - adapter->hw.hw_addr = ioremap(mmio_start, mmio_len);
> + adapter->hw.hw_addr = pcim_iomap(pdev, BAR_0, mmi
Brandon Philips wrote:
> @@ -2554,8 +2547,10 @@ static int __devinit e100_probe(struct p
> struct net_device *netdev;
> struct nic *nic;
> int err;
> + void __iomem **iomap;
> + int bar;
>
> - if(!(netdev = alloc_etherdev(sizeof(struct nic {
> + if (!(netdev
On Thu, Aug 16, 2007 at 01:22:04PM +0300, Ilpo Järvinen wrote:
>
> ...I guess those guys hunting for broken busyloops in the other thread
> could also benefit from similar searching commands introduced in this
> thread... ...Ccing Satyam to caught their attention too.
>
>
> ./drivers/isdn/hisa
On Thu, Aug 16, 2007 at 12:31:03PM +0200, Stefan Richter wrote:
>
> PS: Just to clarify, I'm not speaking for the volatile modifier. I'm
> not speaking for any particular implementation of atomic_t and its
> accessors at all. All I am saying is that
> - we use atomically accessed data types b
On Thu, Aug 16, 2007 at 11:54:44AM +0200, Stefan Richter wrote:
>
> One example was discussed here earlier: The for (;;) loop in
> nodemgr_host_thread. There an msleep_interruptible implicitly acted as
> barrier (at the moment because it's in a different translation unit; if
> it were the same,
I wrote:
> Herbert Xu wrote:
>> On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
[...]
>>> expectation that each
>>> occurrence of atomic_read actually results in a load operation, i.e. is
>>> not optimized away.
[...]
>> Can you find an actual atomic_read code snippet there that is
1 - 100 of 116 matches
Mail list logo
