* Re: Netlink usage question (for bonding comm with userspace)
From: Patrick McHardy @ 2010-01-26 11:25 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <15914.1264466901@death.nxdomain.ibm.com>
Jay Vosburgh wrote:
> Could any netlink gurus comment on my questions? I'm hoping to
> figure out the right way to do what I need without working up patches
> that end up being excellent examples of the wrong way. I've looked
> through the kernel, and it's almost a cases of too many choices (private
> netlink, rtnetlink, connector, genetlink) to sort through.
>
> Background: I'm working on a bonding mode that involves two-way
> communication between bonding itself and a user-space daemon, and I'm
> trying to determine the best way to utilize netlink for this project
> with an eye towards forwards compatibility with future expansion (e.g.,
> general bonding setup via netlink). For purposes of discussion, the
> communication requires that bonding-specific requests, responses and
> asynchronous events flow in both directions.
>
> I could, for this project, use a netlink_kernel_create and
> socket(AF_NETLINK) pair to perform the communication (presumably adding
> a NETLINK_BONDING or the like to <linux/netlink.h>).
>
> That, however, wouldn't dovetail with moving control of bonding
> into iproute2 ("ip link add link bond0 type bond mode whatever"), and it
> seems suboptimal to have two independent netlink gizmos in bonding. I'm
> not planning to implement full bonding control via netlink at this time,
> but I don't want to do anything that would cause difficulty for doing so
> in the future.
I actually have an 75% finished patchset for rtnl_link support.
> I've done some prototyping with working through the existing
> rtnetlink infrastructure, adding an RTNLGRP_BONDING, AF_BONDING, etc,
> vaguely paralleling how the bridge code is architected. What's unclear
> to me is how to insert the bonding-specific request / response message
> types into the rtnetlink infrastructure, or, indeed, if this is simply
> not the right way to go about this.
>
> So, in summary:
>
> For user / kernel communications via netlink: private socket,
> add to rtnetlink API, or something else (connector, genetlink, ...)?
>
> Is having private socket netlink and rtnetlink in the same
> module a reasonable methodology?
It depends. If your requests and responses can be expressed as
device configuration and state changes then you could include them
in the bonding specific part of an rtnetlink message. Otherwise
you should use a private netlink family or genetlink.
> If rtnetlink is suitable, basic "do this" or "don't do this"
> thoughts? The various HOWTOs google finds for me concentrate on the
> mechanisms, less so on interface selection / design.
>
> Thoughts?
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Deadlock in IPv6 code while garbage collection on the rwlock protecting the routing tree.
From: Jarek Poplawski @ 2010-01-26 10:35 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, djohnson, sakkiped, netdev
In-Reply-To: <20100126094817.GA7780@ff.dom.local>
On Tue, Jan 26, 2010 at 09:48:17AM +0000, Jarek Poplawski wrote:
> On 23-01-2010 11:22, David Miller wrote:
> > This is all well and good, but meanwhile someone does need to
> > fix the deadlock originally reported here :-)
>
> I hope I miss something ;-) but I can't see this deadlock; the
> write_lock_bh(&table->tb6_lock) is taken from a timer in this case,
> not from the thread holding read_lock_bh(&table->tb6_lock).
I missed again! Yes, I can see this deadlock now.
Sorry,
Jarek P.
^ permalink raw reply
* Re: [PATCH v2 0/3] e1000e,igb,ixgbe: add registers etc. printout code just before resetting adapters
From: Taku Izumi @ 2010-01-26 10:21 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: netdev@vger.kernel.org, Allan, Bruce W, David S. Miller,
Ronciak, John, Kirsher, Jeffrey T, Waskiewicz Jr, Peter P,
Koki Sanagi, Kenji Kaneshige, chavey@google.com, e1000-devel
In-Reply-To: <alpine.WNT.2.00.1001221345580.6104@jbrandeb-desk1.amr.corp.intel.com>
Hi Jesse,
(2010/01/23 6:54), Brandeburg, Jesse wrote:
> Taku, thanks for these, we are talking the patches over and reviewing
> them. While I agree with the idea of these patches is good, I still don't
> agree with the default being enabled. Usually if someone is getting tx
> hangs they are repeatable and we can work with them to get the debug
> turned on. I DO think it is useful to have the feature available by
> default but NOT enabled.
>
> If we wanted to enable something by default it might be useful to print
> something that actually draws some conclusions from known failure modes,
> like if TDH!=TDT after some amount of time. I think one or two lines
> maximum for default printing.
>
> If you're working in this area I had an idea. I had wanted to be able to
> print the large amount of ring information (especially in the ixgbe case
> with many rings) to the ftrace buffers in order to not overrun the syslog
> daemon. Not sure if you're interested in more new features, it certainly
> is separate but related to this patch.
I thought similar things, that is, all information should be dumped to
the private ring buffer to avoid filling syslog up with driver messages.
But I didn't have any good idea to extract information from ring buffers,
so as the first step, I decided to printout it by using printk().
Is there the easy way to extract it from ring buffers?
Best regards,
Taku Izumi
^ permalink raw reply
* Re: Deadlock in IPv6 code while garbage collection on the rwlock protecting the routing tree.
From: Jarek Poplawski @ 2010-01-26 9:48 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, djohnson, sakkiped, netdev
In-Reply-To: <20100123.022210.56302976.davem@davemloft.net>
On 23-01-2010 11:22, David Miller wrote:
> This is all well and good, but meanwhile someone does need to
> fix the deadlock originally reported here :-)
I hope I miss something ;-) but I can't see this deadlock; the
write_lock_bh(&table->tb6_lock) is taken from a timer in this case,
not from the thread holding read_lock_bh(&table->tb6_lock).
Jarek P.
^ permalink raw reply
* [PATCH] bonding: bond_open error return value
From: Stephen Hemminger @ 2010-01-26 9:34 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: bonding-devel, netdev
The convention for API functions in kernel is to return errno value;
bond_open would return -1 if alb setup failed. The only reason that
could happen is if kmalloc() failed.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/drivers/net/bonding/bond_main.c 2010-01-26 01:28:18.281568331 -0800
+++ b/drivers/net/bonding/bond_main.c 2010-01-26 01:29:58.101099312 -0800
@@ -3650,7 +3650,7 @@ static int bond_open(struct net_device *
*/
if (bond_alb_initialize(bond, (bond->params.mode == BOND_MODE_ALB))) {
/* something went wrong - fail the open operation */
- return -1;
+ return -ENOMEM;
}
INIT_DELAYED_WORK(&bond->alb_work, bond_alb_monitor);
^ permalink raw reply
* drivers/net/ariadne.c:165: error: 'set_multicast_list' undeclared here (not in a function)
From: Geert Uytterhoeven @ 2010-01-26 8:57 UTC (permalink / raw)
To: Alexey Dobriyan, David S. Miller; +Cc: Linux-Next, netdev, linux-kernel
http://kisskb.ellerman.id.au/kisskb/buildresult/2076964/
drivers/net/ariadne.c:165: error: 'set_multicast_list' undeclared here
(not in a function)
Seems to be broken by:
commit a271623f871dda970319ca15dfad3a8c8c36249f
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Fri Jan 22 10:13:10 2010 +0000
netdev: remove certain HAVE_ macros
After netdev_ops compat code HAVE_* macros aren't needed, in fact
they _will_ result in compile breakage for out of tree drivers.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
From: Anders Boström @ 2010-01-26 8:34 UTC (permalink / raw)
To: Jie.Yang; +Cc: ben, netdev, 565404, Xiong.Huang
In-Reply-To: <CDAFEDABF718A54BABD0DA5476695307475CCFF8@SHEXMB-01.global.atheros.com>
>>>>> "JY" == Jie Yang <Jie.Yang@Atheros.com> writes:
JY> Anders Boström <anders@netinsight.net> wrote:
JY> following is my test cese,
>>
JY> a nfs server server with ar8131chip, device id 1063.
>> export /tmp/ dir as the nfs share directory, JY> the client,
>> mount the server_ip:/tmp to local dir /mnt/nfs, ust a python
>> script to write and read data on the JY>
>> /mnt/nfs/testnfs.log. it works fine.
>>
>> OK, the device-ID in our NFS-server is 1026, rev. b0. So it
>> is possible that the problem is specific to that chip/version.
JY> oops, its my mistake in writing, my case is 1026 device ID
>>
JY> Can you give me some advice on how to reproduce this bug??
>>
>> The only suggestion I have is to try to find a board with a
>> 1026-chip on it.
>>
>> My test-case is just copy of a 1 Gbyte file from the
>> NFS-server to /dev/null , after making sure that the file
>> isn't cached on the client by reading huge amounts of other data.
>>
JY> just to check, if the kernel version is 2.6.26-2 ??
I've tested with
Debian linux-image-2.6.26-2-amd64 version 2.6.26-19lenny2,
Debian linux-image-2.6.30-bpo.2-amd64 version 2.6.30-8~bpo50+2 and
kernel.org 2.6.30.10 amd64 with ethtool patch for setting of tso. Same
result.
/ Anders
^ permalink raw reply
* Network QoS support in applications
From: Kalle Valo @ 2010-01-26 8:27 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hello,
I have been trying to understand how applications should use network
QoS. My interest have been mostly from wireless perspective,
especially how to utilise WMM and U-APSD properly, but naturally this
applicable to all networks.
I have done some research about this, but I haven't managed to get
anywhere. For example, from my point of view DiffServ is just one big
mess and I can't see how in practise it can help applications.
I wrote a small wiki page to sum up my findings:
http://wireless.kernel.org/en/developers/Documentation/qos
I would like to clear up all this by and I'm willing to write a
document for application developers about network QoS. But I need help
to understand what's the proper way to mark different QoS
prioritities.
In the wiki page I have tried to come up with different possible
solutions (copied below), but I'm sure there are even more ways.
Please comment. I would like to get some understanding about this.
----------------------------------------------------------------------
Solution 1: SO_PRIORITY with values 0-7
Easy, applications need to just use setsockopt() and be done with it.
It's unknown how widely supported values 0-7 are and the exact meaning
of them, but at least they make sense (0 default, 1 lowest priority
and 7 highest priority). The problem is that the priority is used only
in the first link, rest of the route is not able to benefit from the
classification.
Pros:
* easy for applications
* works with both IPv4 and IPv6
Cons:
* only visible in in the first L2 link, not visible to upper
layers (IP)
* no well defined meaning for the priority values
Solution 2: SO_PRIORITY with values 256-263
mac80211 uses these values to map the packets to DSCP classes. Most
probably non other stack or driver (even non-wifi ones) use these
values. Otherwise similar as Solution 1.
Pros:
* easy for applications
* works with both IPv4 and IPv6
Cons:
* only visible in in the first L2 link, not visible to upper
layers (IP)
* no well defined meaning for the priority values
* using values over 256 is not intuitive
Solution 3: IPv4 DSCP field with values 0-7
Most, if not all, wifi drivers should use it. And, in theory, the
receiver should also benefit from the classification, unless ISPs
modify it of course. But the standardisation for IPv4 QoS bits is a
mess.
Pros:
* visible in IP layer (but ISPs change the value often?)
Cons:
* applications need to handle IPv4 and IPv6 separately
----------------------------------------------------------------------
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 01/25 v2] mlx4_core: identify function as pf or vf
From: Yevgeny Petrilin @ 2010-01-26 8:21 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Liran Liss,
Tziporet Koren
In-Reply-To: <adar5peouu3.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
> I'm a bit confused by these flags. As far as I can tell, the SRIOV flag will be set if and > only if MASTER is set too... so in other words we might as well just have the MASTER and > > SLAVE flags and not have the SRIOV flag at all.
We could have a situation where we have multiple physical functions, without SRIOV.
In this case one of the functions would be MASTER, but not SRIOV
Yevgeny
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/11] Update support for MPC512x
From: Anatolij Gustschin @ 2010-01-26 8:06 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A, dzu-ynQEQJNshbs,
wd-ynQEQJNshbs, Grant Likely, John Rigby, Dan Williams,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100120112232.GD5041-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Wed, 20 Jan 2010 12:22:32 +0100
Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>
> > The patches are based on v2.6.33-rc4 and cover the following
> > items:
>
> The USB-patch needs two patches from linux-next. For convenience, don't you
> have a git-tree somewhere? :)
No, I don't have a git tree for this now, sorry.
Anatolij
^ permalink raw reply
* Re: [PATCH] tcp: fix ICMP-RTO war
From: David Miller @ 2010-01-26 7:45 UTC (permalink / raw)
To: damian; +Cc: denys, ilpo.jarvinen, netdev
In-Reply-To: <4B5DB3BF.1080409@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Mon, 25 Jan 2010 16:07:43 +0100
> @@ -530,7 +530,11 @@ static inline void tcp_bound_rto(const struct sock *sk)
>
> static inline u32 __tcp_set_rto(const struct tcp_sock *tp)
> {
> - return (tp->srtt >> 3) + tp->rttvar;
> + u32 rto = (tp->srtt >> 3) + tp->rttvar;
> + if (unlikely(rto < TCP_RTO_MIN))
> + return TCP_RTO_MIN;
> + else
> + return rto;
> }
The min RTO is now a runtime variable, TCP_RTO_MIN is merely the
default, so we should use tcp_rto_min() for obtaining that value.
And if we make this change, we might want to delete the comment in
tcp_set_rto() which claims:
/* NOTE: clamping at TCP_RTO_MIN is not required, current algo
* guarantees that rto is higher.
*/
tcp_bound_rto(sk);
And we have shown here at least one case where that is not true.
:-)
I've looked at Denys's traces and your analysis, and I still
can't figure out who the true culprit is that lets us get into
such a state that RTO is evaluated so low...
^ permalink raw reply
* Re: [PATCH 2/2] IPv6: conntrack: Use protocol-related match routine in IPv6 connection track
From: David Miller @ 2010-01-26 7:35 UTC (permalink / raw)
To: shanwei; +Cc: kaber, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <4B5E53F4.4020106@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Tue, 26 Jan 2010 10:31:16 +0800
>
> IPv6 connection track and IPv6 stack separately use a different queue to
> manage received fragments. So using protocol-related match routine.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
This problem was also introduced by:
commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Dec 15 16:59:18 2009 +0100
ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery
Currently the same reassembly queue might be used for packets reassembled
by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
as well as local delivery. This can cause "packet jumps" when the fragment
completing a reassembled packet is queued from a different position in the
stack than the previous ones.
Add a "user" identifier to the reassembly queue key to seperate the queues
of each caller, similar to what we do for IPv4.
Signed-off-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* Re: [PATCH 1/2] IPv6: conntrack: Use protocol-related initialization routine to initial queues of IPv6 connection track
From: David Miller @ 2010-01-26 7:32 UTC (permalink / raw)
To: shanwei; +Cc: kaber, yasuyuki.kozakai, netfilter-devel, netdev
In-Reply-To: <4B5E53EE.9010703@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Tue, 26 Jan 2010 10:31:10 +0800
> IPv6 connection track and IPv6 stack separately use a different queue to
> manage received fragments. The former uses nf_ct_frag6_queue structure,
> the latter uses frag_queue structure.
>
> When creating new queue for IPv6 connection track, ip6_frag_init()
> that belongs to IPv6 stack is called to initial nf_ct_frag6_queue structure.
> This broken the saddr&daddr member in nf_ct_frag6_queue, and then hash value
> generated by nf_hashfn() is not equal with that generated by fq_find().
> So, a new received fragment can't be inserted to right queue.
>
> The patch fixes the bug with protocol-related initialization routine.
> The patch-set have been tested.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
This breakage was recently introduced by:
commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Dec 15 16:59:18 2009 +0100
ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery
Currently the same reassembly queue might be used for packets reassembled
by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
as well as local delivery. This can cause "packet jumps" when the fragment
completing a reassembled packet is queued from a different position in the
stack than the previous ones.
Add a "user" identifier to the reassembly queue key to seperate the queues
of each caller, similar to what we do for IPv4.
Signed-off-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* Re: [GIT]: Networking
From: Jarek Poplawski @ 2010-01-26 7:30 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20100125.231735.216761126.davem@davemloft.net>
On Mon, Jan 25, 2010 at 11:17:35PM -0800, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Tue, 26 Jan 2010 06:33:26 +0000
>
> > On 26-01-2010 01:56, David Miller wrote:
> >> are available in the git repository at:
> >>
> >> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
> >
> > David, I hope I miss something, but there seem to be older things too:
> > ...
> >> Jarek Poplawski (1):
> >> ax25: netrom: rose: Fix timer oopses
>
> That was commited on January 16th.
>
> commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d
> Author: Jarek Poplawski <jarkao2@gmail.com>
> Date: Sat Jan 16 01:04:04 2010 -0800
...
> And I haven't sent a pull request to Linus since around
> January 13th
Right! (I was mislead a bit by the numbered list at the beginning.;-)
Thanks,
Jarek P.
^ permalink raw reply
* Re: [GIT]: Networking
From: David Miller @ 2010-01-26 7:17 UTC (permalink / raw)
To: jarkao2; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20100126063326.GA6360@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Tue, 26 Jan 2010 06:33:26 +0000
> On 26-01-2010 01:56, David Miller wrote:
>> are available in the git repository at:
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
>
> David, I hope I miss something, but there seem to be older things too:
> ...
>> Jarek Poplawski (1):
>> ax25: netrom: rose: Fix timer oopses
That was commited on January 16th.
commit d00c362f1b0ff54161e0a42b4554ac621a9ef92d
Author: Jarek Poplawski <jarkao2@gmail.com>
Date: Sat Jan 16 01:04:04 2010 -0800
ax25: netrom: rose: Fix timer oopses
Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905
Reported-by: Bernard Pidoux <bpidoux@free.fr>
Tested-by: Bernard Pidoux <bpidoux@free.fr>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
And I haven't sent a pull request to Linus since around
January 13th
^ permalink raw reply
* Re: [GIT]: Networking
From: Jarek Poplawski @ 2010-01-26 6:52 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20100126063326.GA6360@ff.dom.local>
On Tue, Jan 26, 2010 at 06:33:26AM +0000, Jarek Poplawski wrote:
> David, I hope I miss something, but there seem to be older things too:
> ...
> > Jarek Poplawski (1):
> > ax25: netrom: rose: Fix timer oopses
Hmm... Probably OK! I'm glad I missed it only waited longer.
Sorry,
Jarek P.
^ permalink raw reply
* Re: [GIT]: Networking
From: Jarek Poplawski @ 2010-01-26 6:33 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20100125.165634.92235663.davem@davemloft.net>
On 26-01-2010 01:56, David Miller wrote:
> 1) SKY2 revert to fix a resume regression, from Stephem Hemminger
>
> 2) We can end up trying to remove/proc/net/rt_acct when exiting
> a namespace even when we didn't create it in the first place.
> Fix from Alexey Dobriyan.
...
> Please pull, thanks a lot!
>
> The following changes since commit f6760aa024199cfbce564311dc4bc4d47b6fb349:
> Linus Torvalds (1):
> Merge branch 'timers-fixes-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
David, I hope I miss something, but there seem to be older things too:
...
> Jarek Poplawski (1):
> ax25: netrom: rose: Fix timer oopses
Jarek P.
^ permalink raw reply
* Re: [PATCH] starfire: Clean up properly if firmware loading fails
From: Andrew Morton @ 2010-01-26 5:57 UTC (permalink / raw)
To: Michael
Cc: Ben Hutchings, netdev, bugzilla-daemon, bugme-daemon, Alan Cox,
stable, David S. Miller
In-Reply-To: <4B5E82CB.6040001@moffatt.org.nz>
On Tue, 26 Jan 2010 18:51:07 +1300 Michael <michael@moffatt.org.nz> wrote:
> Yep, OK, I hadn't seen that log in dmesg.
>
> That driver is new to me, it's never turned up (or been required) before
> so that must be new between 2.6.24 and 2.6.32.
>
> As this is a root over nfs system, the kernel is compiled elsewhere and
> then installed manually. What I was missing was that there is a new
> adaptec directory that needed to be copied from
> /usr/src/linux-2.6.32/firmware/ to /lib/2.6.32. Actually, I am not sure
> that this is the right place for it (rather than say
> /lib/firmware/2.6.32|, but it seems to work anyway.
>
> Quite a gotchya. After compiling a kernel on a separate compiling
> system, I don't actually run the 'make install' on the nfs system.
> Previously I used to run the 'make install' on a dedicated compiling
> server and then just copy the modules from that system into the root
> over nfs exported /lib/modules directory. That'd worked fine up until now.
>
> I will have to find a cleverer way to copy over the new firmware libs
> for future compiles. The 'make install' seems to copy firmware objects
> into the compiling system's /lib/firmware/ directory without
> distinguishing the kernel version. So I can't easily tell which ones I'm
> supposed to be copying into the nfs export.
>
> Many thanks for all your help. The interfaces are up and apparently you
> understand where the kernel BUG came from.
>
> So does that complete the story now? In other words, is there anything
> further you need from me.
Well, it'd be great if you could test Ben's patch with the firmware
file inaccessible, and confirm that the kernel doesn't crash/freeze/etc.
Thanks.
^ permalink raw reply
* Re: [PATCH] starfire: Clean up properly if firmware loading fails
From: Michael @ 2010-01-26 5:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Hutchings, netdev, bugzilla-daemon, bugme-daemon, Alan Cox,
stable, David S. Miller
In-Reply-To: <20100125192839.7eaceb2b.akpm@linux-foundation.org>
Hi Andrew,
Yep, OK, I hadn't seen that log in dmesg.
That driver is new to me, it's never turned up (or been required) before
so that must be new between 2.6.24 and 2.6.32.
As this is a root over nfs system, the kernel is compiled elsewhere and
then installed manually. What I was missing was that there is a new
adaptec directory that needed to be copied from
/usr/src/linux-2.6.32/firmware/ to /lib/2.6.32. Actually, I am not sure
that this is the right place for it (rather than say
/lib/firmware/2.6.32|, but it seems to work anyway.
Quite a gotchya. After compiling a kernel on a separate compiling
system, I don't actually run the 'make install' on the nfs system.
Previously I used to run the 'make install' on a dedicated compiling
server and then just copy the modules from that system into the root
over nfs exported /lib/modules directory. That'd worked fine up until now.
I will have to find a cleverer way to copy over the new firmware libs
for future compiles. The 'make install' seems to copy firmware objects
into the compiling system's /lib/firmware/ directory without
distinguishing the kernel version. So I can't easily tell which ones I'm
supposed to be copying into the nfs export.
Many thanks for all your help. The interfaces are up and apparently you
understand where the kernel BUG came from.
So does that complete the story now? In other words, is there anything
further you need from me.
Many thanks,
Michael.
|
Andrew Morton wrote:
> On Tue, 26 Jan 2010 15:58:39 +1300 Michael <michael@moffatt.org.nz> wrote:
>
>
>> Hi guys,
>>
>> I think I'm the submitter that Ben is referring to.
>>
>> So that could be the answer to the kernel BUG I have reported, but I
>> don't think that it will answer why the interface doesn't come up... or
>> does it?
>>
>
> >From this:
>
> Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
> Jan 21 05:08:26 172 kernel: device eth4 entered promiscuous mode
> Jan 21 05:08:26 172 kernel: starfire 0000:03:06.0: firmware: requesting adaptec/starfire_rx.bin
> Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
> Jan 21 05:08:26 172 kernel: device eth5 entered promiscuous mode
> Jan 21 05:08:26 172 kernel: starfire 0000:03:07.0: firmware: requesting adaptec/starfire_rx.bin
> Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
> Jan 21 05:08:26 172 kernel: device eth6 entered promiscuous mode
> Jan 21 05:08:26 172 kernel: starfire 0000:04:04.0: firmware: requesting adaptec/starfire_rx.bin
>
> I assume that it can't find the firmware?
>
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Al Viro @ 2010-01-26 3:56 UTC (permalink / raw)
To: Tejun Heo
Cc: H. Peter Anvin, Frederic Weisbecker, linux-kernel, axboe, rusty,
akpm, ebiederm, tytso, Trond.Myklebust, aelder, hch, davem,
netdev, x86, mingo, dan.j.williams, borislav.petkov, ying.huang,
lenb, neilb, cl
In-Reply-To: <4B5E5D3B.7040102@kernel.org>
On Tue, Jan 26, 2010 at 12:10:51PM +0900, Tejun Heo wrote:
> Hello,
>
> On 01/26/2010 11:48 AM, Al Viro wrote:
> > On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:
> >
> >>> Eh... You are leaving that noderef in place in case of array. And _that_
> >>> is not an address space, so casts to AS 0 won't do you any good.
> >>
> >> Any ideas on how to fix it?
> >
> > BTW, before we go any further, which warnings are you getting from sparse
> > and which version of sparse are you using?
> >
> > noderef is one thing; address_space mess is a different story. The version
> > I have here steps into the former, but not the latter; what are you seeing?
>
> Oops, I too am seeing the noderef thing not the address space warning.
OK... So all messing around __kernel __force is actually a red herring.
Frankly, for now I'd keep it as in your patch. Yes, including workarounds
in these few places. Longer term... We probably want to implement
__attribute__((qualify(...)))/__attribute__((unqualify(...))), revert
__typeof__ for AS/noderef to what gcc is doing for normal qualifiers
(i.e. "if p is int const *, typeof(*p) v gives const int") go for explicit
__unqualify((address_space,noderef)) in there. Playing interesting games
with arrays for unqualify (i.e. creating parallel chains of type nodes
all way down to the place where original qualifier had been applied).
^ permalink raw reply
* Re: [PATCH] starfire: Clean up properly if firmware loading fails
From: Andrew Morton @ 2010-01-26 3:28 UTC (permalink / raw)
To: Michael
Cc: Ben Hutchings, netdev, bugzilla-daemon, bugme-daemon, Alan Cox,
stable, David S. Miller
In-Reply-To: <4B5E5A5F.90608@moffatt.org.nz>
On Tue, 26 Jan 2010 15:58:39 +1300 Michael <michael@moffatt.org.nz> wrote:
> Hi guys,
>
> I think I'm the submitter that Ben is referring to.
>
> So that could be the answer to the kernel BUG I have reported, but I
> don't think that it will answer why the interface doesn't come up... or
> does it?
>From this:
Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
Jan 21 05:08:26 172 kernel: device eth4 entered promiscuous mode
Jan 21 05:08:26 172 kernel: starfire 0000:03:06.0: firmware: requesting adaptec/starfire_rx.bin
Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
Jan 21 05:08:26 172 kernel: device eth5 entered promiscuous mode
Jan 21 05:08:26 172 kernel: starfire 0000:03:07.0: firmware: requesting adaptec/starfire_rx.bin
Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
Jan 21 05:08:26 172 kernel: device eth6 entered promiscuous mode
Jan 21 05:08:26 172 kernel: starfire 0000:04:04.0: firmware: requesting adaptec/starfire_rx.bin
I assume that it can't find the firmware?
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Tejun Heo @ 2010-01-26 3:10 UTC (permalink / raw)
To: Al Viro
Cc: H. Peter Anvin, Frederic Weisbecker, linux-kernel, axboe, rusty,
akpm, ebiederm, tytso, Trond.Myklebust, aelder, hch, davem,
netdev, x86, mingo, dan.j.williams, borislav.petkov, ying.huang,
lenb, neilb, cl
In-Reply-To: <20100126024857.GD19799@ZenIV.linux.org.uk>
Hello,
On 01/26/2010 11:48 AM, Al Viro wrote:
> On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:
>
>>> Eh... You are leaving that noderef in place in case of array. And _that_
>>> is not an address space, so casts to AS 0 won't do you any good.
>>
>> Any ideas on how to fix it?
>
> BTW, before we go any further, which warnings are you getting from sparse
> and which version of sparse are you using?
>
> noderef is one thing; address_space mess is a different story. The version
> I have here steps into the former, but not the latter; what are you seeing?
Oops, I too am seeing the noderef thing not the address space warning.
char *estacks = per_cpu(exception_stacks, cpu);
I get
arch/x86/kernel/cpu/common.c:1149:19: warning: incorrect type in initializer (different modifiers)
arch/x86/kernel/cpu/common.c:1149:19: expected char *estacks
arch/x86/kernel/cpu/common.c:1149:19: got char [noderef] *<noident>
CC arch/x86/kernel/cpu/common.o
$ rpm -qi sparse
Name : sparse Relocations: (not relocatable)
Version : 0.4.1.git1 Vendor: openSUSE
Release : 3.2 Build Date: Sat 24 Oct 2009 11:58:16 AM KST
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] starfire: Clean up properly if firmware loading fails
From: Michael @ 2010-01-26 2:58 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon, Alan Cox,
stable, David S. Miller
In-Reply-To: <1264473168.373.354.camel@localhost>
Hi guys,
I think I'm the submitter that Ben is referring to.
So that could be the answer to the kernel BUG I have reported, but I
don't think that it will answer why the interface doesn't come up... or
does it?
Cheers,
Michael.
Ben Hutchings wrote:
> On Mon, 2010-01-25 at 18:15 -0800, Andrew Morton wrote:
>
>> On Tue, 26 Jan 2010 02:02:12 +0000 Ben Hutchings <bhutchings@solarflare.com> wrote:
>>
>>
>>> netdev_open() will return without cleaning up net device or hardware
>>> state if firmware loading fails. This results in a BUG() on a second
>>> attempt to bring the interface up, reported in
>>> <http://bugzilla.kernel.org/show_bug.cgi?id=15117>, and probably has
>>> even worse effects if the driver is removed afterwards.
>>>
>> (That's the wrong bugzilla URL)
>>
>
> Hah, well spotted. Must have copied from the wrong tab.
>
>
>>> Call netdev_close() to clean up on failure.
>>>
>> OK, thanks.
>>
>>
>>> ---
>>> On Mon, 2010-01-25 at 17:08 -0800, Andrew Morton wrote:
>>>
>>>> (switched to email. Please respond via emailed reply-to-all, not via the
>>>> bugzilla web interface).
>>>>
>>>> On Wed, 20 Jan 2010 04:29:20 GMT
>>>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>>>
>>>>
>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=15091
>>>>>
>>>>> Summary: starfire causes kernel BUG when interface goes up
>>>>>
>>> [...]
>>>
>>>>> I formerly used 2.6.20 and 2.6.24 with a couple of starfire 4 port ethernet
>>>>> cards. On 2.6.32 the interfaces don't start on boot and when I issue "ifconfig
>>>>> ethX up" (where X is a starfire port).
>>>>>
>>> [...]
>>>
>>>> Starfire is triggering the BUG_ON(!test_bit(NAPI_STATE_SCHED,
>>>> &n->state)); in napi_enable().
>>>>
>>>> This is a regression somewhere between 2.6.24 and 2.6.32(!).
>>>>
>>> This driver now attempts to load firmware when an interface is brought
>>> up, *after* calling napi_enable(). If that fails, it will return
>>> without calling napi_disable(). On the second attempt to bring the
>>> interface it calls napi_enable() a second time and triggers this
>>> assertion.
>>>
>>> As a workaround, try installing the necessary firmware. :-)
>>>
>>>
>> Missing signed-off-by. I added it, OK? Also added a Cc:stable.
>>
> [...]
>
> Well I was going to wait and see what the submitter says first, but I'm
> happy for you to add that in your patch set if it's a positive result.
>
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Al Viro @ 2010-01-26 2:48 UTC (permalink / raw)
To: Tejun Heo
Cc: H. Peter Anvin, Frederic Weisbecker, linux-kernel, axboe, rusty,
akpm, ebiederm, tytso, Trond.Myklebust, aelder, hch, davem,
netdev, x86, mingo, dan.j.williams, borislav.petkov, ying.huang,
lenb, neilb, cl
In-Reply-To: <4B5E56EC.2090600@kernel.org>
On Tue, Jan 26, 2010 at 11:43:56AM +0900, Tejun Heo wrote:
> > Eh... You are leaving that noderef in place in case of array. And _that_
> > is not an address space, so casts to AS 0 won't do you any good.
>
> Any ideas on how to fix it?
BTW, before we go any further, which warnings are you getting from sparse
and which version of sparse are you using?
noderef is one thing; address_space mess is a different story. The version
I have here steps into the former, but not the latter; what are you seeing?
^ permalink raw reply
* Re: [PATCH 7/8] percpu: add __percpu sparse annotations to hw_breakpoint
From: Tejun Heo @ 2010-01-26 2:47 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, axboe, rusty, akpm, ebiederm, tytso,
Trond.Myklebust, aelder, hch, viro, davem, netdev, x86, mingo,
dan.j.williams, borislav.petkov, ying.huang, lenb, neilb, cl
In-Reply-To: <20100126023542.GQ5087@nowhere>
On 01/26/2010 11:35 AM, Frederic Weisbecker wrote:
> No guarantee that will build. I should pull your tree and install
> sparse (yeah, shame on me, I've never installed it).
Nope, it doesn't. Please pull from the following tree to receive the
whole thing. The definitions in question are in
include/asm-generic/percpu.h.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git percpu-sparse-review
After installing sparse,
make C=2 arch/x86/kernel/cpu/common.o
should be enough.
Thanks.
--
tejun
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox