On Thu, Jun 28, 2007 at 02:55:51PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > On Thu, Jun 28, 2007 at 02:23:36PM +0200, Patrick McHardy wrote:
> >
> >>Jarek Poplawski wrote:
> >>
> @@ -202,7 +201,6 @@ void gen_kill_estimator(struct gnet_stats_basic
> *bstats,
> struc
Hi Jeff,
Any update on these patch submission? Is it in queue?
Thanks,
~Siva
-Original Message-
From: Veena Parat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 19, 2007 3:27 PM
To: netdev@vger.kernel.org; [EMAIL PROTECTED]
Cc: Leonid Grossman; Ramkrishna Vepa; Rastapur Santosh; Sivakum
Please pull from 'for_linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus
to receive the following updates:
drivers/net/gianfar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Kumar Gala (1):
gianfar: Fix typo bug introduced by move
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 10:34:57 -0400
>
> Hi David
>
> Please pull the following changes:
>
> The following changes since commit 19e6454ca778e11e81497bd87c930dc0defd03d7:
> David Howells (1):
> [AF_RXRPC]: Return the number of bytes buffered in
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 21:24:37 +0200
> Waskiewicz Jr, Peter P wrote:
> >>[...]
> >>The only reasonable thing it can do is not care about
> >>multiqueue and just dequeue as usual. In fact I think it
> >>should be an error to configure multiqueue on a non
From: PJ Waskiewicz <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 09:21:13 -0700
> -struct net_device *alloc_netdev(int sizeof_priv, const char *name,
> - void (*setup)(struct net_device *))
> +struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
> + void (*se
On Thursday 28 June 2007 10:01:08 am Kok, Auke wrote:
> Marian Balakowicz wrote:
> > I am enabling and testing PCI on tqm5200 mpc5200 based board where I
> > faced the following issue.
> >
> > I am using EEPRO100 PCI card for which there is specific
> > quirk_e100_interrupt that tries to disable i
Send to the lists on behalf on Jing, Any comment is welcome. Thanks -stanley
--
hi,
Here's one patch for cdc subset to support new vendor/product ID.
Could you help to check whether it is accaptable or not? Thanks a lot!
Signed-off-by: Jing Xiang<[EMAIL PROTECTED]>
diff -u
On Thu, Jun 28, 2007 at 11:10:37PM +0200, Francois Romieu wrote:
> > I have an Asrock ConRoe945G-DVI motherboard with a RTL8111/8168B in
> > it. The stock r8159 driver locks up from time to time. I've
> > described it here: https://launchpad.net/bugs/121815 . The patchset
> > at http://www.fr.zore
The latest serie of r8169 changes is available against 2.6.22-rc6 as:
http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
or (tarball sits one level higher):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/
or (rebase prone branch)
git
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 16:08:43 -0700
> Thanks Patrick for taking care of this. I am totally fine with this
> patch; if anyone else has feedback, please send it. If not, I'm excited
> to see if these can be considered for 2.6.23 now. :) Thanks
> Waskiewicz Jr, Peter P wrote:
> >>
> >> Looking at Peter's multiqueue patch, which should include all
> >> hard_start_xmit users (I'm not seeing sch_teql though,
> >> Peter?) the only other one is pktgen.
> >>
> >
> > Ugh. That is another netif_queue_stopped() that needs
> > netif_subqueu
Jens Stroebel <[EMAIL PROTECTED]> :
[...]
> Is there any possibility to get this fix working in 2.6.21.5? Would it
> be possible to apply the single patch to 2.6.21.5 and get a working
> driver? Or would it be possible to create the fixing patch for the
> driver in 2.6.21.5?
Mantra: mainline first
David Miller wrote:
From: David Stevens <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 11:17:51 -0700
Comments?
I think sysfs is a better model for MIBs, the extensibility we
get for free since each SNMP MIB entry we want to add is simply
a new file.
I'd be quite thrilled to apply a patch whic
Waskiewicz Jr, Peter P wrote:
Looking at Peter's multiqueue patch, which should include all
hard_start_xmit users (I'm not seeing sch_teql though,
Peter?) the only other one is pktgen.
Ugh. That is another netif_queue_stopped() that needs
netif_subqueue_stopped(). I can send an update
(netdev Cced. People, please, please Cc: netdev)
Soren Hansen <[EMAIL PROTECTED]> :
[...]
> I have an Asrock ConRoe945G-DVI motherboard with a RTL8111/8168B in it.
> The stock r8159 driver locks up from time to time. I've described it
> here: https://launchpad.net/bugs/121815 . The patchset at
> h
> -Original Message-
> From: Patrick McHardy [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 28, 2007 12:37 PM
> To: Jeff Garzik
> Cc: Waskiewicz Jr, Peter P; [EMAIL PROTECTED];
> netdev@vger.kernel.org; Kok, Auke-jan H; [EMAIL PROTECTED]
> Subject: Re: [PATCH 2/3] NET: [CORE] Stack chan
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 29 Jun 2007 03:18:31 +0800
> On Thu, Jun 28, 2007 at 09:13:38AM +, Andrew Morton wrote:
> >
> > With the full -mm lineup, my tg3-using powerpc g5 spits lots of these:
> >
> > windfarm: Drive bay control loop started.
> > audit(1183017094.732:2)
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 15:32:40 -0400
> Patrick McHardy wrote:
> > Yes, but there are users that don't go through qdiscs, like netpoll,
> > Having them check the QDISC_RUNNING bit seems ugly.
>
> Is netpoll the only such user?
>
> netpoll tends to be a speci
From: David Stevens <[EMAIL PROTECTED]>
Date: Thu, 28 Jun 2007 11:17:51 -0700
> Comments?
I think sysfs is a better model for MIBs, the extensibility we
get for free since each SNMP MIB entry we want to add is simply
a new file.
I'd be quite thrilled to apply a patch which implemented this.
-
To
On Thu, Jun 28, 2007 at 09:13:38AM +, Andrew Morton wrote:
>
> With the full -mm lineup, my tg3-using powerpc g5 spits lots of these:
>
> windfarm: Drive bay control loop started.
> audit(1183017094.732:2): audit_pid=2117 old=0 by auid=4294967295
> [ cut here ]
> Badne
Jeff Garzik wrote:
> Patrick McHardy wrote:
>
>> Yes, but there are users that don't go through qdiscs, like netpoll,
>> Having them check the QDISC_RUNNING bit seems ugly.
>
>
> Is netpoll the only such user?
I'm not sure, I just remembered that one :)
Looking at Peter's multiqueue patch, whi
Patrick McHardy wrote:
Yes, but there are users that don't go through qdiscs, like netpoll,
Having them check the QDISC_RUNNING bit seems ugly.
Is netpoll the only such user?
netpoll tends to be a special case in every sense of the word, and I
wish it was less so :/
Jeff
-
To unsu
> Waskiewicz Jr, Peter P wrote:
> >>[...]
> >>The only reasonable thing it can do is not care about
> multiqueue and
> >>just dequeue as usual. In fact I think it should be an error to
> >>configure multiqueue on a non-root qdisc.
> >
> >
> > Ack. This is a thought process that trips me up fr
Waskiewicz Jr, Peter P wrote:
>>[...]
>>The only reasonable thing it can do is not care about
>>multiqueue and just dequeue as usual. In fact I think it
>>should be an error to configure multiqueue on a non-root qdisc.
>
>
> Ack. This is a thought process that trips me up from time to time...I
Waskiewicz Jr, Peter P wrote:
>>Waskiewicz Jr, Peter P wrote:
>>
>>Yes, I noticed that now. Doesn't seem right though as long as
>>queueing while queue is stopped is treated as a bug by the
>>drivers.
>>
>>But I vaguely recall seeing a discussion about this, I'll check
>>the archives.
>
>
> The b
> Absolutely not. First of all, its perfectly valid to use
> non-multiqueue qdiscs on multiqueue devices. Secondly, its
> only the root qdisc that has to know about multiqueue since
> that one controls the child qdiscs.
>
> Think about it, it makes absolutely no sense to have the
> child qdisc
Waskiewicz Jr, Peter P wrote:
>>PJ Waskiewicz wrote:
>>
>>>+#ifdef CONFIG_NET_SCH_MULTIQUEUE
>>>+if (q->mq)
>>>+skb->queue_mapping =
>>>+
>>
>>q->prio2band[band&TC_PRIO_MAX];
>>
>>>+else
> Waskiewicz Jr, Peter P wrote:
> >>Quick question: where are the sch_generic changes? :)
> >>
> >>If you hold for ten minutes I'll post a set of slightly changed
> >>patches with the NETDEVICES_MULTIQUEUE option and a fix for this.
> >
> >
> > Jamal's and KK's qdisc_restart() rewrite took the
> PJ Waskiewicz wrote:
> > +#ifdef CONFIG_NET_SCH_MULTIQUEUE
> > + if (q->mq)
> > + skb->queue_mapping =
> > +
> q->prio2band[band&TC_PRIO_MAX];
> > + else
> > + skb->
Waskiewicz Jr, Peter P wrote:
>>Quick question: where are the sch_generic changes? :)
>>
>>If you hold for ten minutes I'll post a set of slightly
>>changed patches with the NETDEVICES_MULTIQUEUE option and a
>>fix for this.
>
>
> Jamal's and KK's qdisc_restart() rewrite took the netif_queue_st
> PJ Waskiewicz wrote:
> > include/linux/etherdevice.h |3 +-
> > include/linux/netdevice.h | 62
> ++-
> > include/linux/skbuff.h |4 ++-
> > net/core/dev.c | 27 +--
> > net/core/netpoll.c |8 ++
Please pull from 'for_linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus
to receive the following updates:
drivers/net/phy/mdio_bus.c |3 ++-
drivers/net/phy/vitesse.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
Kumar Gala (1):
I think there's a more general problem that's a huge hassle. There are
lots of
new SNMP MIB's, but no conventions (that I'm aware of, at least) to allow
for
changes to the /proc entries that get them to applications. For example,
the
route age data recently submitted. I agree that existing apps
Hello.
The hardware involved:
Motherboard: Asus P5B
lspci:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet
controller (rev 01)
First the non-working scenario (2.6.21.5, 2.6.22rc6 unpatched):
During the use of networ
This is an slightly changed version of Peter's patch.
Changes are:
- introduce NETDEVICES_MULTIQUEUE config option instead of
NET_SCH_MULTIQUEUE. Schedulers build in multiqueue support
automatically when that option is selected.
- make netif_*_subqueue functions NOPs for the
!NETDEVICES_MUL
Updated version of Peter's patch, changes:
- remove NET_SCH_MULTIQUEUE
- remove all ifdefs, the price is 4-8 bytes additional
memory usage per prio qdisc.
- return -EOPNOTSUPP when multiqueue is requested but not supported
on the device or not compiled in
- clean up prio_classify, only a singl
Chris Snook wrote:
Rick Jones wrote:
It seems that every driver, when providing support for ethtool -S
functionality, has considerable lattitude when it comes to the stats
provided. Clearly this is very nice for the driver writer(s) as it
allows them to provide whatever stats they feel are m
PJ Waskiewicz wrote:
> +#ifdef CONFIG_NET_SCH_MULTIQUEUE
> + if (q->mq)
> + skb->queue_mapping =
> + q->prio2band[band&TC_PRIO_MAX];
> + else
> + skb->queue_m
PJ Waskiewicz wrote:
> include/linux/etherdevice.h |3 +-
> include/linux/netdevice.h | 62
> ++-
> include/linux/skbuff.h |4 ++-
> net/core/dev.c | 27 +--
> net/core/netpoll.c |8 +++---
> net/
Waskiewicz Jr, Peter P wrote:
> Thanks for fixing; however, the current sch_prio doesn't unregister the
> qdisc if register_qdisc() on prio fails, or does that happen implicitly
> because the module will probably unload?
It failed, there's nothing to unregister. But when you register two
qdiscs a
> Its not error handling. You do:
>
> err = register qdisc 1
> if (err)
> return err;
> err = register qdisc 2
> if (err)
> unregister qdisc 2
> return err
>
> anyways, I already fixed that and cleaned up prio_classify
> the way I suggested. Will send shortly.
Thanks for fixing; ho
Patrick McHardy wrote:
> PJ Waskiewicz wrote:
>
>> +
>> static int __init prio_module_init(void)
>> {
>> -return register_qdisc(&prio_qdisc_ops);
>> +int err;
>> +err = register_qdisc(&prio_qdisc_ops);
>> +if (!err)
>> +err = register_qdisc(&rr_qdisc_ops);
>> +return
Waskiewicz Jr, Peter P wrote:
>>PJ Waskiewicz wrote:
>>
>>
>>>+
>>> static int __init prio_module_init(void) {
>>>-return register_qdisc(&prio_qdisc_ops);
>>>+int err;
>>>+err = register_qdisc(&prio_qdisc_ops);
>>>+if (!err)
>>>+err = register_qdisc(&rr_qdisc_ops);
>>>+
> Since rr is not built as a module you could actually put
> everything in q_prio and share the code. But I don't really care :)
I tried doing this, but I couldn't get things working quite right with
selecting the correct module from sch_prio to sch_rr. So I just added
the q_rr.c portion of tc,
> PJ Waskiewicz wrote:
>
> > +
> > static int __init prio_module_init(void) {
> > - return register_qdisc(&prio_qdisc_ops);
> > + int err;
> > + err = register_qdisc(&prio_qdisc_ops);
> > + if (!err)
> > + err = register_qdisc(&rr_qdisc_ops);
> > + return err;
> > }
> >
>
PJ Waskiewicz wrote:
> This patch applies on top of Patrick McHardy's RTNETLINK
> patches to add nested compat attributes. This is needed to maintain
> ABI for sch_{rr|prio} in the kernel with respect to tc. A new option,
> namely multiqueue, was added to sch_prio and sch_rr. This will allow
> a
PJ Waskiewicz wrote:
+
static int __init prio_module_init(void)
{
- return register_qdisc(&prio_qdisc_ops);
+ int err;
+ err = register_qdisc(&prio_qdisc_ops);
+ if (!err)
+ err = register_qdisc(&rr_qdisc_ops);
+ return err;
}
Thats still broken
PJ Waskiewicz wrote:
Updated: Fixed allocation of subqueues in alloc_netdev_mq() to
allocate all subqueues, not num - 1.
Added checks for netif_subqueue_stopped() to netpoll,
pktgen, and software device dev_queue_xmit(). This will ensure
external events to these subsystems will be handled corre
This patch applies on top of Patrick McHardy's RTNETLINK
patches to add nested compat attributes. This is needed to maintain
ABI for sch_{rr|prio} in the kernel with respect to tc. A new option,
namely multiqueue, was added to sch_prio and sch_rr. This will allow
a user to turn multiqueue suppor
Updated: Fixed allocation of subqueues in alloc_netdev_mq() to
allocate all subqueues, not num - 1.
Added checks for netif_subqueue_stopped() to netpoll,
pktgen, and software device dev_queue_xmit(). This will ensure
external events to these subsystems will be handled correctly if
a subqueue is s
Add a brief howto to Documentation/networking for multiqueue. It
explains how to use the multiqueue API in a driver to support
multiqueue paths from the stack, as well as the qdiscs to use for
feeding a multiqueue device.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
Documentatio
Updated: Cleaned up Kconfig options for multiqueue. Cleaned up
sch_rr and sch_prio multiqueue handling. Added nested compat netlink
options for new options. Allowing a 0 band option for prio and rr when
in multiqueue mode so it defaults to the number of queues on the NIC.
Add the new sch_rr qdi
Please consider these patches for 2.6.23 inclusion.
Updates since the last submission:
1. Fixed alloc_netdev_mq() queue_count bug.
2. Fixed the TCA_PRIO_MQ options layout.
3. Protected sch_prio and sch_rr multiqueue code with NET_SCH_MULTIQUEUE.
4. Added RTA_{GET|PUT}_FLAG in place of RTA_DATA
Marian Balakowicz wrote:
I am enabling and testing PCI on tqm5200 mpc5200 based board where I
faced the following issue.
I am using EEPRO100 PCI card for which there is specific
quirk_e100_interrupt that tries to disable interrupts if
they were left enabled by the firmware. quirk_e100_interrupts
SET_NETDEV_DEV() in myri10ge to create the "/sys/class/net//device"
symlink.
Signed-off-by: Maik Hampel <[EMAIL PROTECTED]>
diff -Naur a/drivers/net/myri10ge/myri10ge.c
b/drivers/net/myri10ge/myri10ge.c
--- a/drivers/net/myri10ge/myri10ge.c 2007-06-28 16:04:41.0
+0200
+++ b/drivers/net/
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>Eric W. Biederman wrote:
>>
>>>-- The basic design
>>>
>>>There will be a network namespace structure that holds the global
>>>variables for a network namespace, making those global variables
>>>per network namespace.
>>
Hi David
Please pull the following changes:
The following changes since commit 19e6454ca778e11e81497bd87c930dc0defd03d7:
David Howells (1):
[AF_RXRPC]: Return the number of bytes buffered in rxrpc_send_data()
are found in the git repository at:
master.kernel.org:/pub/scm/linux/kern
On Thu, Jun 28, 2007 at 02:55:51PM +0200, Patrick McHardy wrote:
...
> Its overkill in that case. The concurrent additions and removals
> can't happen.
>
Then the changelog needs one more change. Plus, maybe - btw,
1 line about this at the beginning of the file?
Jarek P.
-
To unsubscribe from th
Jarek Poplawski wrote:
> On Thu, Jun 28, 2007 at 02:24:55PM +0200, Patrick McHardy wrote:
>
>>Jarek Poplawski wrote:
>>
>>>BTW #2, I hope it's about some new policy, but I cannot see
>>>any #ifdef CONFIG_NET_ESTIMATOR in this sch_htb patch.
>>
>>One of my previous patches for 2.6.23 killed that op
Ben Greear wrote:
> Kirill Korotaev wrote:
>
>>Patrick McHardy wrote:
>>
>>
>>>I believe OpenVZ stores the current namespace somewhere global,
>>>which avoids passing the namespace around. Couldn't you do this
>>>as well?
>>>
>>
>>yes, we store a global namespace context on current
>>(can be
On Thu, Jun 28, 2007 at 02:24:55PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> >BTW #2, I hope it's about some new policy, but I cannot see
> >any #ifdef CONFIG_NET_ESTIMATOR in this sch_htb patch.
>
> One of my previous patches for 2.6.23 killed that option,
> the code was always com
Jarek Poplawski wrote:
> On Thu, Jun 28, 2007 at 02:23:36PM +0200, Patrick McHardy wrote:
>
>>Jarek Poplawski wrote:
>>
@@ -202,7 +201,6 @@ void gen_kill_estimator(struct gnet_stats_basic
*bstats,
struct gen_estimator *est, **pest;
for (idx=0; idx <= EST_MAX_INTERVAL;
On Thu, Jun 28, 2007 at 02:23:36PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> >>@@ -202,7 +201,6 @@ void gen_kill_estimator(struct gnet_stats_basic
> >>*bstats,
> >>struct gen_estimator *est, **pest;
> >>
> >>for (idx=0; idx <= EST_MAX_INTERVAL; idx++) {
> >>- int
Rick Jones wrote:
It seems that every driver, when providing support for ethtool -S
functionality, has considerable lattitude when it comes to the stats
provided. Clearly this is very nice for the driver writer(s) as it
allows them to provide whatever stats they feel are most "natural" for
th
Jarek Poplawski wrote:
@@ -202,7 +201,6 @@ void gen_kill_estimator(struct gnet_stats_basic *bstats,
struct gen_estimator *est, **pest;
for (idx=0; idx <= EST_MAX_INTERVAL; idx++) {
- int killed = 0;
pest = &elist[idx].list;
while ((est=*p
Jarek Poplawski wrote:
BTW #2, I hope it's about some new policy, but I cannot see
any #ifdef CONFIG_NET_ESTIMATOR in this sch_htb patch.
One of my previous patches for 2.6.23 killed that option,
the code was always compiled in anyways.
-
To unsubscribe from this list: send the line "unsubscri
On Thu, Jun 28, 2007 at 08:54:48AM +0200, Jarek Poplawski wrote:
...
> > @@ -215,10 +213,7 @@ void gen_kill_estimator(struct gnet_stats_basic
> > *bstats,
> > write_unlock_bh(&est_lock);
> >
> > kfree(est);
> > - killed++;
> >
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
> On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote:
>
> > I wonder if we should hold off on this API until we've worked out the
> > multicast issue.
>
> Even if the ACPI thing goes in first, you will have to change a few
> others that are exis
With the full -mm lineup, my tg3-using powerpc g5 spits lots of these:
windfarm: Drive bay control loop started.
audit(1183017094.732:2): audit_pid=2117 old=0 by auid=4294967295
[ cut here ]
Badness at net/core/dev.c:1303
Call Trace:
[cb45ead0] [c00108c8] .
On Wed, Jun 27, 2007 at 05:25:45PM +0200, Patrick McHardy wrote:
...
> Additionally there are a few more related problems that seem to be
> relicts from the timer when the estimator was qdisc specific and
> could rely on the rtnl or dev->qdisc_lock:
>
> - the check whether the list is empty and a
On Wed, Jun 27, 2007 at 04:53:48PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> >On Wed, Jun 27, 2007 at 01:44:08PM +0200, Patrick McHardy wrote:
> >
> >>>BTW, maybe I look at this too short, but is this del_timer()
> >>>in gen_kill_estimator() enough? I cannot see nothing against
> >
David Miller wrote:
This is going to cause problems on compat platforms where
__u64 is aligned on an 8-byte boundary on the 64-bit
variant but it is not on the 32-bit cpu variant.
A way to avoid this is to use the aligned_u64 type from
linux/types.h which ensures 8-byte alignment on all
platfor
David Miller wrote:
Patch applied, thanks.
Note that we could use the callback pointer for the XFRM
case too, and I kind of thought you would understand that
logical progression and implement that too :-/
I spotted it but didn't want to risk an error that would lead to the
patch being bounce
74 matches
Mail list logo
