* Re: Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-19 18:48 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20100619165642.GP14513@mail.wantstofly.org>
Lennert Buytenhek <buytenh@wantstofly.org> wrote on 2010/06/19 18:56:43:
>
> On Sat, Jun 19, 2010 at 04:22:18PM +0200, Joakim Tjernlund wrote:
>
> > > > > > OK. With DSA, how does one configure VLANs, policing and
> > > > > > parameters in the HW switch that don't map or exist in the
> > > > > > linux bridge?
> > > > >
> > > > > The idea is to use existing kernel interface for this as much as
> > > > > possible. So e.g. if you do:
> > > > >
> > > > > vconfig add lan1 123
> > > > > vconfig add lan2 123
> > > > > brctl addbr br123
> > > > > brctl addif br123 lan1.123
> > > > > brctl addif br123 lan2.123
> > > > >
> > > > > Then the DSA code (or some userspace netlink listener helper, or some
> > > > > combination of both) should ideally also detect that VLAN 123 on
> > > > > interfaces lan1 and lan2 are to be bridged together, and program the
> > > > > switch chip accordingly. I think all VLAN configurations that at least
> > > > > the Marvell hardware supports can be expressed this way.
> > > >
> > > > Yes, but I image that this breaks down when you want to do something
> > > > a bit more advanced. For example I don't think linux VLANs supports
> > > > "shared VLAN learning"(SVL) and to configure a HW switch to do SVL
> > > > one would first have to impl. that in Linux VLAN and then add the DSA
> > > > code to get the config to the switch.
> > >
> > > Yes. But that's really the best way to do it, in my humble opinion.
> >
> > I will buy that for the moment. I can't see a better way either if
> > you truly want to integrate a HW switch into linux. I just wish
> > Linux VLANs had some support for SVL too
>
> You know how to fix that. :)
Possibly :)
>
>
> > > If you don't go the host networking stack integration route, you end
> > > up with something like the vendor drivers. Which work fine for most
> > > scenarios.. until you want to do something like talking TCP/IP using
> > > the host TCP stack over some of the switch ports, at which point the
> > > lack of host networking stack integration comes to bite you.
> >
> > Just doing STP will bite you :)
>
> Most people deal with this by running a userland STP daemon that uses
> raw sockets to inject manually (i.e. in userspace) DSA-tagged packets
> onto the eth0 (or whatever) interface. This "works" (for some
> definitions of 'works') for UDP apps such as a DHCP server as well --
> this crappy approach unfortunately only really breaks down for TCP.
>
>
> > > > Not sure how one would express whether VLAN tags should be stripped
> > > > off or not when egressing the HW switch's physical port.
> > >
> > > If you transmit a packet onto 'lan', it will be sent to the switch chip
> > > with an "untagged" DSA tag. If you transmit a packet onto 'lan.123',
> > > it will be sent to the switch chip with a "tagged" DSA tag. See
> > > net/dsa/tag_dsa.c for details.
> >
> > Ah, now I get it, thanks.
> > However, how does this work for LAN to LAN pkgs? LAN1 and LAN2 could be
> > in the same VLAN but one is implicit(port) VLAN and the
> > other is explicit.
>
> If you tell the HW switch to forward these packets, they will never
> appear at the CPU interface, so the DSA tagging/untagging doesn't enter
> the picture.
"tell the HW switch"? Doesn't DSA do that already? If not, what
is the point of DSA then if it doesn't use the native forwarding
capabilities of the HW switch?
>
>
> > How do I config the HW switch to do that?
>
> Tell the switch that the vlan is native on one of the ports but not on
> the other. It's been a while since I looked at the chip docs but there
> are ways of doing this.
The current DSA impl. does not support this? There should be some
way to manage this within the DSA framework.
>
>
> > > > Furthermore, suppose one have a big HW switch, 48 ports, and lots of
> > > > VLANs in that HW switch one would have to create a lot of virtual I/Fs
> > > > and VLANs in linux just to configure the HW switch. This wastes
> > > > resources on the CPU.
> > >
> > > Where the 'resource waste' is on the order of a couple of tens or
> > > hundreds of kilobytes of RAM. If this is a problem for your host
> > > CPU, I think you have bigger problems anyway.
> >
> > That is not a very good argument, this is how bloat builds.
>
> If you have a better way of getting all the features while spending
> less resources, please step forward with your ideas. The current design
> is the best I could come up with, but I'm sure it's not optimal in its
> current form.
I don't, I am not that familiar with the inner working of Linux
networking code.
>
>
> > > > > To configure things like ingress/egress rate limiting and such in the
> > > > > switch chip for which there is no Linux counterpart interface, I suppose
> > > > > some sysfs interface or so might suffice.
> > > >
> > > > Yes, there are aspects of a HW switch that doesn't map into DSA currently.
> > > > Perhaps one should add some framework to support this?
> > >
> > > Sounds good.
> >
> > Any idea how such an framework should look like? What transport
> > mechanism is suitable to talk to a user space daemon?
>
> Have a look at netlink.
I was afraid you would say that, I have no experience with netlink :)
^ permalink raw reply
* 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-19 17:53 UTC (permalink / raw)
To: netdev
Hi,
I have a NULL pointer dereference Oops here which I can reproduce,
and I believe it's related to network / IPv6 somehow since sending a
ping from outside to the IPv6 address is what ultimately triggers it.
The box is a dedicated server with a /64 subnet assigned to it.
What I'm trying to do is tunnel part of it through IPv4 / OpenVPN.
I'm completely new to IPv6 so I'm probably doing this horribly wrong.
Unfortunately I only have a screenshot of the Oops.
I uploaded it along with other information here:
http://www.metamorpher.de/kernel/
Before the Oops I'm running a shell script (see link above)
which among other things sets up proxy_ndp on eth0 (r8169 driver).
The Oops is triggered by sending a ping from the outside world to
the IP which was intended to be tunneled (2a01:4f8:120:8221:ffff::2).
If you need more information, I'll try my best to provide it.
If it's a kernel bug, I'll also be happy to test any patches.
Regards
Andreas Klauer
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Jiri Kosina @ 2010-06-19 17:49 UTC (permalink / raw)
To: Alan Ott
Cc: Marcel Holtmann, David S Miller, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth, linux-kernel, netdev
In-Reply-To: <1276467601-9066-1-git-send-email-alan@signal11.us>
On Sun, 13 Jun 2010, Alan Ott wrote:
> This patch adds support or getting and setting feature reports for bluetooth
> HID devices from HIDRAW.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Marcel, any word on this please? We already have USB counterpart in, so
it'd be nice to finalize the Bluetooth part as well.
Thanks.
> ---
> net/bluetooth/hidp/core.c | 121 +++++++++++++++++++++++++++++++++++++++++++--
> net/bluetooth/hidp/hidp.h | 8 +++
> 2 files changed, 125 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index bfe641b..0f068a0 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -36,6 +36,7 @@
> #include <linux/file.h>
> #include <linux/init.h>
> #include <linux/wait.h>
> +#include <linux/mutex.h>
> #include <net/sock.h>
>
> #include <linux/input.h>
> @@ -313,6 +314,93 @@ static int hidp_send_report(struct hidp_session *session, struct hid_report *rep
> return hidp_queue_report(session, buf, rsize);
> }
>
> +static int hidp_get_raw_report(struct hid_device *hid,
> + unsigned char report_number,
> + unsigned char *data, size_t count,
> + unsigned char report_type)
> +{
> + struct hidp_session *session = hid->driver_data;
> + struct sk_buff *skb;
> + size_t len;
> + int numbered_reports = hid->report_enum[report_type].numbered;
> +
> + switch (report_type) {
> + case HID_FEATURE_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_FEATURE;
> + break;
> + case HID_INPUT_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_INPUT;
> + break;
> + case HID_OUTPUT_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_OUPUT;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (mutex_lock_interruptible(&session->report_mutex))
> + return -ERESTARTSYS;
> +
> + /* Set up our wait, and send the report request to the device. */
> + session->waiting_report_type = report_type & HIDP_DATA_RTYPE_MASK;
> + session->waiting_report_number = numbered_reports ? report_number : -1;
> + set_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + data[0] = report_number;
> + if (hidp_send_ctrl_message(hid->driver_data, report_type, data, 1))
> + goto err_eio;
> +
> + /* Wait for the return of the report. The returned report
> + gets put in session->report_return. */
> + while (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
> + int res;
> +
> + res = wait_event_interruptible_timeout(session->report_queue,
> + !test_bit(HIDP_WAITING_FOR_RETURN, &session->flags),
> + 5*HZ);
> + if (res == 0) {
> + /* timeout */
> + goto err_eio;
> + }
> + if (res < 0) {
> + /* signal */
> + goto err_restartsys;
> + }
> + }
> +
> + skb = session->report_return;
> + if (skb) {
> + if (numbered_reports) {
> + /* Strip off the report number. */
> + size_t rpt_len = skb->len-1;
> + len = rpt_len < count ? rpt_len : count;
> + memcpy(data, skb->data+1, len);
> + } else {
> + len = skb->len < count ? skb->len : count;
> + memcpy(data, skb->data, len);
> + }
> +
> + kfree_skb(skb);
> + session->report_return = NULL;
> + } else {
> + /* Device returned a HANDSHAKE, indicating protocol error. */
> + len = -EIO;
> + }
> +
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> +
> + return len;
> +
> +err_restartsys:
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> + return -ERESTARTSYS;
> +err_eio:
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> + return -EIO;
> +}
> +
> static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, size_t count,
> unsigned char report_type)
> {
> @@ -367,6 +455,10 @@ static void hidp_process_handshake(struct hidp_session *session,
> case HIDP_HSHK_ERR_INVALID_REPORT_ID:
> case HIDP_HSHK_ERR_UNSUPPORTED_REQUEST:
> case HIDP_HSHK_ERR_INVALID_PARAMETER:
> + if (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + wake_up_interruptible(&session->report_queue);
> + }
> /* FIXME: Call into SET_ GET_ handlers here */
> break;
>
> @@ -403,9 +495,11 @@ static void hidp_process_hid_control(struct hidp_session *session,
> }
> }
>
> -static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> +/* Returns true if the passed-in skb should be freed by the caller. */
> +static int hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> unsigned char param)
> {
> + int done_with_skb = 1;
> BT_DBG("session %p skb %p len %d param 0x%02x", session, skb, skb->len, param);
>
> switch (param) {
> @@ -417,7 +511,6 @@ static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
>
> if (session->hid)
> hid_input_report(session->hid, HID_INPUT_REPORT, skb->data, skb->len, 0);
> -
> break;
>
> case HIDP_DATA_RTYPE_OTHER:
> @@ -429,12 +522,27 @@ static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> __hidp_send_ctrl_message(session,
> HIDP_TRANS_HANDSHAKE | HIDP_HSHK_ERR_INVALID_PARAMETER, NULL, 0);
> }
> +
> + if (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags) &&
> + param == session->waiting_report_type) {
> + if (session->waiting_report_number < 0 ||
> + session->waiting_report_number == skb->data[0]) {
> + /* hidp_get_raw_report() is waiting on this report. */
> + session->report_return = skb;
> + done_with_skb = 0;
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + wake_up_interruptible(&session->report_queue);
> + }
> + }
> +
> + return done_with_skb;
> }
>
> static void hidp_recv_ctrl_frame(struct hidp_session *session,
> struct sk_buff *skb)
> {
> unsigned char hdr, type, param;
> + int free_skb = 1;
>
> BT_DBG("session %p skb %p len %d", session, skb, skb->len);
>
> @@ -454,7 +562,7 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
> break;
>
> case HIDP_TRANS_DATA:
> - hidp_process_data(session, skb, param);
> + free_skb = hidp_process_data(session, skb, param);
> break;
>
> default:
> @@ -463,7 +571,8 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
> break;
> }
>
> - kfree_skb(skb);
> + if (free_skb)
> + kfree_skb(skb);
> }
>
> static void hidp_recv_intr_frame(struct hidp_session *session,
> @@ -797,6 +906,7 @@ static int hidp_setup_hid(struct hidp_session *session,
> hid->dev.parent = hidp_get_device(session);
> hid->ll_driver = &hidp_hid_driver;
>
> + hid->hid_get_raw_report = hidp_get_raw_report;
> hid->hid_output_raw_report = hidp_output_raw_report;
>
> err = hid_add_device(hid);
> @@ -857,6 +967,9 @@ int hidp_add_connection(struct hidp_connadd_req *req, struct socket *ctrl_sock,
> skb_queue_head_init(&session->ctrl_transmit);
> skb_queue_head_init(&session->intr_transmit);
>
> + mutex_init(&session->report_mutex);
> + init_waitqueue_head(&session->report_queue);
> +
> session->flags = req->flags & (1 << HIDP_BLUETOOTH_VENDOR_ID);
> session->idle_to = req->idle_to;
>
> diff --git a/net/bluetooth/hidp/hidp.h b/net/bluetooth/hidp/hidp.h
> index 8d934a1..00e71dd 100644
> --- a/net/bluetooth/hidp/hidp.h
> +++ b/net/bluetooth/hidp/hidp.h
> @@ -80,6 +80,7 @@
> #define HIDP_VIRTUAL_CABLE_UNPLUG 0
> #define HIDP_BOOT_PROTOCOL_MODE 1
> #define HIDP_BLUETOOTH_VENDOR_ID 9
> +#define HIDP_WAITING_FOR_RETURN 10
>
> struct hidp_connadd_req {
> int ctrl_sock; // Connected control socket
> @@ -154,6 +155,13 @@ struct hidp_session {
> struct sk_buff_head ctrl_transmit;
> struct sk_buff_head intr_transmit;
>
> + /* Used in hidp_get_raw_report() */
> + int waiting_report_type; /* HIDP_DATA_RTYPE_* */
> + int waiting_report_number; /* -1 for not numbered */
> + struct mutex report_mutex;
> + struct sk_buff *report_return;
> + wait_queue_head_t report_queue;
> +
> /* Report descriptor */
> __u8 *rd_data;
> uint rd_size;
> --
> 1.7.0.4
>
>
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Lennert Buytenhek @ 2010-06-19 16:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF27FDE4E4.06C565FF-ONC1257747.004A175A-C1257747.004EF252@transmode.se>
On Sat, Jun 19, 2010 at 04:22:18PM +0200, Joakim Tjernlund wrote:
> > > > > OK. With DSA, how does one configure VLANs, policing and
> > > > > parameters in the HW switch that don't map or exist in the
> > > > > linux bridge?
> > > >
> > > > The idea is to use existing kernel interface for this as much as
> > > > possible. So e.g. if you do:
> > > >
> > > > vconfig add lan1 123
> > > > vconfig add lan2 123
> > > > brctl addbr br123
> > > > brctl addif br123 lan1.123
> > > > brctl addif br123 lan2.123
> > > >
> > > > Then the DSA code (or some userspace netlink listener helper, or some
> > > > combination of both) should ideally also detect that VLAN 123 on
> > > > interfaces lan1 and lan2 are to be bridged together, and program the
> > > > switch chip accordingly. I think all VLAN configurations that at least
> > > > the Marvell hardware supports can be expressed this way.
> > >
> > > Yes, but I image that this breaks down when you want to do something
> > > a bit more advanced. For example I don't think linux VLANs supports
> > > "shared VLAN learning"(SVL) and to configure a HW switch to do SVL
> > > one would first have to impl. that in Linux VLAN and then add the DSA
> > > code to get the config to the switch.
> >
> > Yes. But that's really the best way to do it, in my humble opinion.
>
> I will buy that for the moment. I can't see a better way either if
> you truly want to integrate a HW switch into linux. I just wish
> Linux VLANs had some support for SVL too
You know how to fix that. :)
> > If you don't go the host networking stack integration route, you end
> > up with something like the vendor drivers. Which work fine for most
> > scenarios.. until you want to do something like talking TCP/IP using
> > the host TCP stack over some of the switch ports, at which point the
> > lack of host networking stack integration comes to bite you.
>
> Just doing STP will bite you :)
Most people deal with this by running a userland STP daemon that uses
raw sockets to inject manually (i.e. in userspace) DSA-tagged packets
onto the eth0 (or whatever) interface. This "works" (for some
definitions of 'works') for UDP apps such as a DHCP server as well --
this crappy approach unfortunately only really breaks down for TCP.
> > > Not sure how one would express whether VLAN tags should be stripped
> > > off or not when egressing the HW switch's physical port.
> >
> > If you transmit a packet onto 'lan', it will be sent to the switch chip
> > with an "untagged" DSA tag. If you transmit a packet onto 'lan.123',
> > it will be sent to the switch chip with a "tagged" DSA tag. See
> > net/dsa/tag_dsa.c for details.
>
> Ah, now I get it, thanks.
> However, how does this work for LAN to LAN pkgs? LAN1 and LAN2 could be
> in the same VLAN but one is implicit(port) VLAN and the
> other is explicit.
If you tell the HW switch to forward these packets, they will never
appear at the CPU interface, so the DSA tagging/untagging doesn't enter
the picture.
> How do I config the HW switch to do that?
Tell the switch that the vlan is native on one of the ports but not on
the other. It's been a while since I looked at the chip docs but there
are ways of doing this.
> > > Furthermore, suppose one have a big HW switch, 48 ports, and lots of
> > > VLANs in that HW switch one would have to create a lot of virtual I/Fs
> > > and VLANs in linux just to configure the HW switch. This wastes
> > > resources on the CPU.
> >
> > Where the 'resource waste' is on the order of a couple of tens or
> > hundreds of kilobytes of RAM. If this is a problem for your host
> > CPU, I think you have bigger problems anyway.
>
> That is not a very good argument, this is how bloat builds.
If you have a better way of getting all the features while spending
less resources, please step forward with your ideas. The current design
is the best I could come up with, but I'm sure it's not optimal in its
current form.
> > > > To configure things like ingress/egress rate limiting and such in the
> > > > switch chip for which there is no Linux counterpart interface, I suppose
> > > > some sysfs interface or so might suffice.
> > >
> > > Yes, there are aspects of a HW switch that doesn't map into DSA currently.
> > > Perhaps one should add some framework to support this?
> >
> > Sounds good.
>
> Any idea how such an framework should look like? What transport
> mechanism is suitable to talk to a user space daemon?
Have a look at netlink.
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Joakim Tjernlund @ 2010-06-19 14:22 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev
In-Reply-To: <20100618201243.GK14513@mail.wantstofly.org>
Lennert Buytenhek <buytenh@wantstofly.org> wrote on 2010/06/18 22:12:43:
> From: Lennert Buytenhek <buytenh@wantstofly.org>
> To: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> Cc: netdev@vger.kernel.org
> Date: 2010/06/18 22:12
> Subject: Re: Distributed Switch Architecture(DSA)
>
> On Fri, Jun 18, 2010 at 05:13:03PM +0200, Joakim Tjernlund wrote:
>
> > > > > > > > Now I want to add STP/RSTP to the switch. How would one do that?
> > > > > > >
> > > > > > > First, you'll want the hardware bridging patches that I posted to
> > > > > > > netdev@ a while back, e.g.:
> > > > > > >
> > > > > > > http://patchwork.ozlabs.org/patch/16578/
> > > > > >
> > > > > > I see, will have to study this a bit closer. One question though,
> > > > > > does this disable MAC learning in the linux bridge?
> > > > >
> > > > > No, why should it?
> > > >
> > > > Doesn't the HW switch handle all MAC leaning? Why duplicate
> > > > this in the SW bridge?
> > > > I figured the HW switch would offload the SW bridge this task.
> > >
> > > Imagine the case where you bridge lan1, lan2 (both on the switch chip)
> > > into br0, together with wlan0 (which is not on the switch chip).
> > >
> > > Now a packet is sent out of br0. Should it be sent to wlan0 or to the
> > > switch chip? How will you make this decision without an address database
> > > on the Linux side?
> >
> > True, in this case you need it, but for only HW switch I/Fs you don't
> > need it and there can be several hundreds of MAC addresses passing
> > trough the HW switch. It would be nice if one didn't need to pass
> > all those up to the SW bridge, especially if you have a small embedded
> > CPU.
>
> I think you overestimate the effect that address learning will have on
> the host CPU. It only needs to happen for the first packet for every
> new MAC address, and address flooding attacks is something you'll need
> to address in either case.
Possibly, I am just being careful.
>
> If you're really worried about this scenario, then just configure your
> boot loader to bridge all switch ports together, and don't load the DSA
> driver. The switch will then appear as a single interface, 'eth0' (or
> whatever your SoC calls it), over which you can talk directly without
> any form of tagging. You won't be able to use any advanced features,
> though.
Na, that is no fun :)
>
>
> > > > > > Do you have any idea how to do DSA on a Broadcom switch?
> > > > >
> > > > > I have no idea. When I originally submitted the DSA code for merging,
> > > > > I contacted Broadcom people about adding support for Broadcom switch
> > > > > chips to it, but I never heard back from them.
> > > >
> > > > OK. With DSA, how does one configure VLANs, policing and parameters in the
> > > > HW switch that don't map or exist in the linux bridge?
> > >
> > > The idea is to use existing kernel interface for this as much as
> > > possible. So e.g. if you do:
> > >
> > > vconfig add lan1 123
> > > vconfig add lan2 123
> > > brctl addbr br123
> > > brctl addif br123 lan1.123
> > > brctl addif br123 lan2.123
> > >
> > > Then the DSA code (or some userspace netlink listener helper, or some
> > > combination of both) should ideally also detect that VLAN 123 on
> > > interfaces lan1 and lan2 are to be bridged together, and program the
> > > switch chip accordingly. I think all VLAN configurations that at least
> > > the Marvell hardware supports can be expressed this way.
> >
> > Yes, but I image that this breaks down when you want to do something
> > a bit more advanced. For example I don't think linux VLANs supports
> > "shared VLAN learning"(SVL) and to configure a HW switch to do SVL
> > one would first have to impl. that in Linux VLAN and then add the DSA
> > code to get the config to the switch.
>
> Yes. But that's really the best way to do it, in my humble opinion.
I will buy that for the moment. I can't see a better way either if
you truly want to integrate a HW switch into linux. I just wish
Linux VLANs had some support for SVL too
>
> If you don't go the host networking stack integration route, you end
> up with something like the vendor drivers. Which work fine for most
> scenarios.. until you want to do something like talking TCP/IP using
> the host TCP stack over some of the switch ports, at which point the
> lack of host networking stack integration comes to bite you.
Just doing STP will bite you :)
>
>
> > Not sure how one would express whether VLAN tags should be stripped
> > off or not when egressing the HW switch's physical port.
>
> If you transmit a packet onto 'lan', it will be sent to the switch chip
> with an "untagged" DSA tag. If you transmit a packet onto 'lan.123',
> it will be sent to the switch chip with a "tagged" DSA tag. See
> net/dsa/tag_dsa.c for details.
Ah, now I get it, thanks.
However, how does this work for LAN to LAN pkgs? LAN1 and LAN2 could be
in the same VLAN but one is implicit(port) VLAN and the
other is explicit. How do I config the HW switch to do that?
>
>
> > Furthermore, suppose one have a big HW switch, 48 ports, and lots of
> > VLANs in that HW switch one would have to create a lot of virtual I/Fs
> > and VLANs in linux just to configure the HW switch. This wastes
> > resources on the CPU.
>
> Where the 'resource waste' is on the order of a couple of tens or
> hundreds of kilobytes of RAM. If this is a problem for your host
> CPU, I think you have bigger problems anyway.
That is not a very good argument, this is how bloat builds.
However, lets ignore this for now.
>
>
> > > To configure things like ingress/egress rate limiting and such in the
> > > switch chip for which there is no Linux counterpart interface, I suppose
> > > some sysfs interface or so might suffice.
> >
> > Yes, there are aspects of a HW switch that doesn't map into DSA currently.
> > Perhaps one should add some framework to support this?
>
> Sounds good.
Any idea how such an framework should look like? What transport
mechanism is suitable to talk to a user space daemon?
^ permalink raw reply
* Re: inconsistent lock state
From: Dominik Brodowski @ 2010-06-19 13:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
linux-fsdevel, linux-kernel, Maciej Rutecki, Eric Dumazet,
Paul E. McKenney, Lai Jiangshan, David S. Miller, netdev
In-Reply-To: <20100618133004.228c2223.akpm@linux-foundation.org>
Hey,
On Fri, Jun 18, 2010 at 01:30:04PM -0700, Andrew Morton wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
>
> Fix a lockdep-splat-causing regression introduced by
>
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author: Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit: David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> :
> : fasync: RCU and fine grained locking
>
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
Seems to work fine -- thanks!
Best,
Dominik
^ permalink raw reply
* Re: inconsistent lock state
From: Sergey Senozhatsky @ 2010-06-19 8:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Sergey Senozhatsky, Alexander Viro, Peter Zijlstra, Sage Weil,
linux-fsdevel, linux-kernel, Dominik Brodowski, Maciej Rutecki,
Eric Dumazet, Paul E. McKenney, Lai Jiangshan, David S. Miller,
netdev
In-Reply-To: <20100618133004.228c2223.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 8190 bytes --]
Hello Andrew,
Thanks. I'll test.
Sergey
On (06/18/10 13:30), Andrew Morton wrote:
> This was also reported by Dominik and is being tracked at
> https://bugzilla.kernel.org/show_bug.cgi?id=16230
>
> On Tue, 15 Jun 2010 14:24:34 +0300
> Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
>
> > Hello,
> >
> > kernel: [ 3272.351191]
> > kernel: [ 3272.351194] =================================
> > kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> > kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351206] ---------------------------------
> > kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > kernel: [ 3272.351218] (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> > kernel: [ 3272.351235] [<c104e95c>] __lock_acquire+0x281/0xbe1
> > kernel: [ 3272.351243] [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351248] [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351255] [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351261] [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> > kernel: [ 3272.351275] [<c1232003>] input_pass_event+0x6f/0xae
> > kernel: [ 3272.351283] [<c1232ef5>] input_handle_event+0x38d/0x396
> > kernel: [ 3272.351288] [<c1232fbf>] input_event+0x4f/0x62
> > kernel: [ 3272.351293] [<c12368e4>] input_sync+0xe/0x11
> > kernel: [ 3272.351299] [<c1236d72>] atkbd_interrupt+0x48b/0x541
> > kernel: [ 3272.351304] [<c122ecb2>] serio_interrupt+0x35/0x68
> > kernel: [ 3272.351309] [<c122fbff>] i8042_interrupt+0x264/0x26e
> > kernel: [ 3272.351314] [<c106bb02>] handle_IRQ_event+0x1d/0x98
> > kernel: [ 3272.351321] [<c106d506>] handle_edge_irq+0xc0/0x107
> > kernel: [ 3272.351326] [<c10045ca>] handle_irq+0x1a/0x20
> > kernel: [ 3272.351332] [<c100435f>] do_IRQ+0x43/0x8d
> > kernel: [ 3272.351337] [<c1002d75>] common_interrupt+0x35/0x3c
> > kernel: [ 3272.351342] [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> > kernel: [ 3272.351349] [<c100170d>] cpu_idle+0x89/0xbe
> > kernel: [ 3272.351354] [<c12b6d11>] rest_init+0xb5/0xba
> > kernel: [ 3272.351361] [<c148a7bf>] start_kernel+0x33b/0x340
> > kernel: [ 3272.351368] [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> > kernel: [ 3272.351374] irq event stamp: 54104917
> > kernel: [ 3272.351377] hardirqs last enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> > kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> > kernel: [ 3272.351391] softirqs last enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> > kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> > kernel: [ 3272.351404]
> > kernel: [ 3272.351405] other info that might help us debug this:
> > kernel: [ 3272.351409] 3 locks held by X/3827:
> > kernel: [ 3272.351412] #0: (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351423] #1: (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351432] #2: (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> > kernel: [ 3272.351442]
> > kernel: [ 3272.351443] stack backtrace:
> > kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> > kernel: [ 3272.351451] Call Trace:
> > kernel: [ 3272.351456] [<c12c4ff1>] ? printk+0xf/0x11
> > kernel: [ 3272.351462] [<c104e51a>] valid_state+0x133/0x141
> > kernel: [ 3272.351468] [<c104e5f7>] mark_lock+0xcf/0x1b3
> > kernel: [ 3272.351473] [<c104e54e>] ? mark_lock+0x26/0x1b3
> > kernel: [ 3272.351479] [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> > kernel: [ 3272.351484] [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> > kernel: [ 3272.351489] [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351495] [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> > kernel: [ 3272.351502] [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> > kernel: [ 3272.351508] [<c104f652>] lock_acquire+0x59/0x70
> > kernel: [ 3272.351513] [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351519] [<c12c6c48>] _raw_spin_lock+0x25/0x34
> > kernel: [ 3272.351524] [<c10aefb4>] ? kill_fasync+0x37/0x71
> > kernel: [ 3272.351529] [<c10aefb4>] kill_fasync+0x37/0x71
> > kernel: [ 3272.351534] [<c124d694>] sock_wake_async+0x77/0x83
> > kernel: [ 3272.351540] [<c124fe4d>] sk_wake_async+0x2d/0x32
> > kernel: [ 3272.351545] [<c1250004>] sock_def_readable+0x45/0x51
> > kernel: [ 3272.351551] [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> > kernel: [ 3272.351557] [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> > kernel: [ 3272.351562] [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> > kernel: [ 3272.351567] [<c124cff7>] sock_aio_write+0xd4/0xdd
> > kernel: [ 3272.351575] [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> > kernel: [ 3272.351582] [<c10a4288>] ? copy_from_user+0x8/0xa
> > kernel: [ 3272.351587] [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> > kernel: [ 3272.351594] [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351599] [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351605] [<c10a4f58>] do_readv_writev+0x7d/0xdf
> > kernel: [ 3272.351610] [<c124cf23>] ? sock_aio_write+0x0/0xdd
> > kernel: [ 3272.351615] [<c1164082>] ? security_file_permission+0xf/0x11
> > kernel: [ 3272.351621] [<c10a47e5>] ? rw_verify_area+0x90/0xac
> > kernel: [ 3272.351626] [<c10a4ff3>] vfs_writev+0x39/0x42
> > kernel: [ 3272.351632] [<c10a5102>] sys_writev+0x3b/0x8c
> > kernel: [ 3272.351637] [<c10027d3>] sysenter_do_call+0x12/0x32
> >
>
> This, I think?
>
>
> From: Andrew Morton <akpm@linux-foundation.org>
>
> Fix a lockdep-splat-causing regression introduced by
>
> : commit 989a2979205dd34269382b357e6d4b4b6956b889
> : Author: Eric Dumazet <eric.dumazet@gmail.com>
> : AuthorDate: Wed Apr 14 09:55:35 2010 +0000
> : Commit: David S. Miller <davem@davemloft.net>
> : CommitDate: Wed Apr 21 16:19:29 2010 -0700
> :
> : fasync: RCU and fine grained locking
>
> kill_fasync() can be called from both process and hard-irq context, so
> fa_lock must be taken with IRQs disabled.
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> fs/fcntl.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
> --- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
> +++ a/fs/fcntl.c
> @@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
> {
> while (fa) {
> struct fown_struct *fown;
> + unsigned long flags;
> +
> if (fa->magic != FASYNC_MAGIC) {
> printk(KERN_ERR "kill_fasync: bad magic number in "
> "fasync_struct!\n");
> return;
> }
> - spin_lock(&fa->fa_lock);
> + spin_lock_irqsave(&fa->fa_lock, flags);
> if (fa->fa_file) {
> fown = &fa->fa_file->f_owner;
> /* Don't send SIGURG to processes which have not set a
> @@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
> if (!(sig == SIGURG && fown->signum == 0))
> send_sigio(fown, fa->fa_fd, band);
> }
> - spin_unlock(&fa->fa_lock);
> + spin_unlock_irqrestore(&fa->fa_lock, flags);
> fa = rcu_dereference(fa->fa_next);
> }
> }
> _
>
>
> afaict all other lockers of fa_lock are OK (but one never really knows
> with spin_lock_irq()).
>
> Guys, please review-and-ack and I'll get it merged up.
>
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code
From: David Miller @ 2010-06-19 5:15 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100616232523.4834.84849.stgit@localhost.localdomain>
I've applied this series however:
1) Please address Ben's concerns about turning EEE on by default
given that standardization is not complete yet.
2) I hate module parameters, I'd rather you create a new ethtool
feature bit and thus allow the setting to be modified at run
time. Please create a new ethtool control flag, and remove
this module option.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/9] cxgb4 update v2
From: David Miller @ 2010-06-19 5:12 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1276891535-13967-1-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Fri, 18 Jun 2010 13:05:26 -0700
>
> Here's v2 of the cxgb4 series. Of the 9 patches patch 8 has been updated to
> fix the iw_cxgb4 breakage and the rest are as before.
All applied, thanks.
^ permalink raw reply
* [PATCH] Fix a typo in netlink.h
From: Justin P. Mattock @ 2010-06-19 4:29 UTC (permalink / raw)
To: trivial; +Cc: netdev, Justin P. Mattock
Fix a typo in include/net/netlink.h
should be finalize instead of finanlize
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
include/net/netlink.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index 4fc05b5..f3b201d 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -35,7 +35,7 @@
* nlmsg_new() create a new netlink message
* nlmsg_put() add a netlink message to an skb
* nlmsg_put_answer() callback based nlmsg_put()
- * nlmsg_end() finanlize netlink message
+ * nlmsg_end() finalize netlink message
* nlmsg_get_pos() return current position in message
* nlmsg_trim() trim part of message
* nlmsg_cancel() cancel message construction
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Bring back var 'i' increment
From: Gustavo F. Padovan @ 2010-06-19 0:28 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, marcel-kz+m5ild9QBg9hUCZPvPmw
In-Reply-To: <1276907040-23229-1-git-send-email-padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
* Gustavo F. Padovan <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org> [2010-06-18 21:24:00 -0300]:
> commit ff6e2163f28a1094fb5ca5950fe2b43c3cf6bc7a accidentally added a
> regression on the bnep code. Fixing it.
>
> Signed-off-by: Gustavo F. Padovan <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
> ---
> net/bluetooth/bnep/netdev.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/bnep/netdev.c b/net/bluetooth/bnep/netdev.c
> index 0faad5c..8c100c9 100644
> --- a/net/bluetooth/bnep/netdev.c
> +++ b/net/bluetooth/bnep/netdev.c
> @@ -104,6 +104,8 @@ static void bnep_net_set_mc_list(struct net_device *dev)
> break;
> memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
> memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
> +
> + i++;
> }
> r->len = htons(skb->len - len);
> }
> --
Marcel, if you want I can carry the fix on my tree for -next.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH] Bluetooth: Bring back var 'i' increment
From: Gustavo F. Padovan @ 2010-06-19 0:24 UTC (permalink / raw)
To: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
Cc: gustavo-THi1TnShQwVAfugRpC6u6w, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100619002213.GC14514@vigoh>
commit ff6e2163f28a1094fb5ca5950fe2b43c3cf6bc7a accidentally added a
regression on the bnep code. Fixing it.
Signed-off-by: Gustavo F. Padovan <padovan-Y3ZbgMPKUGA34EUeqzHoZw@public.gmane.org>
---
net/bluetooth/bnep/netdev.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/bnep/netdev.c b/net/bluetooth/bnep/netdev.c
index 0faad5c..8c100c9 100644
--- a/net/bluetooth/bnep/netdev.c
+++ b/net/bluetooth/bnep/netdev.c
@@ -104,6 +104,8 @@ static void bnep_net_set_mc_list(struct net_device *dev)
break;
memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
+
+ i++;
}
r->len = htons(skb->len - len);
}
--
1.6.4.4
^ permalink raw reply related
* Re: potential bug in bnep_net_set_mc_list()
From: Gustavo F. Padovan @ 2010-06-19 0:22 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jiri Pirko, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100618230916.GA5467@bicker>
Hi Dan,
* Dan Carpenter <error27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2010-06-19 01:09:17 +0200]:
> This is from ff6e2163f28a: "net: convert multiple drivers to use
> netdev_for_each_mc_addr, part7"
>
> net/bluetooth/bnep/netdev.c
> 101 i = 0;
> 102 netdev_for_each_mc_addr(ha, dev) {
> 103 if (i == BNEP_MAX_MULTICAST_FILTERS)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 104 break;
> 105 memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
> 106 memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
> 107 }
>
> "i" is never incremented here so the check is always false.
Bring back the increment should fix this. I'll send a fix for this.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* potential bug in bnep_net_set_mc_list()
From: Dan Carpenter @ 2010-06-18 23:09 UTC (permalink / raw)
To: Jiri Pirko
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
This is from ff6e2163f28a: "net: convert multiple drivers to use
netdev_for_each_mc_addr, part7"
net/bluetooth/bnep/netdev.c
101 i = 0;
102 netdev_for_each_mc_addr(ha, dev) {
103 if (i == BNEP_MAX_MULTICAST_FILTERS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
104 break;
105 memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
106 memcpy(__skb_put(skb, ETH_ALEN), ha->addr, ETH_ALEN);
107 }
"i" is never incremented here so the check is always false.
regards,
dan carpenter
^ permalink raw reply
* Can I limit number of rx queues for igb (and other Intel drivers)?
From: Ben Greear @ 2010-06-18 22:39 UTC (permalink / raw)
To: NetDev
I'm using pktgen to send a stream of packets with varying source and destination
IP addresses. It appears that the fancy rx logic of the NIC (I'm using igb for this test)
causes the received packets to appear on random rx queues and so be received out
of order in the network core.
I do not see the out-of-order issue when using a single source/dest IP address
for the pktgen packets.
So, is there a way to tell igb to use only a single rx queue?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH -next] netfilter: xt_IDLETIMER needs kdev_t.h
From: Randy Dunlap @ 2010-06-18 22:34 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML, netfilter-devel
In-Reply-To: <20100618145443.77b7f8df.sfr@canb.auug.org.au>
From: Randy Dunlap <randy.dunlap@oracle.com>
Add header file to fix build error:
net/netfilter/xt_IDLETIMER.c:276: error: implicit declaration of function 'MKDEV'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
net/netfilter/xt_IDLETIMER.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20100618.orig/net/netfilter/xt_IDLETIMER.c
+++ linux-next-20100618/net/netfilter/xt_IDLETIMER.c
@@ -36,6 +36,7 @@
#include <linux/netfilter.h>
#include <linux/netfilter/x_tables.h>
#include <linux/netfilter/xt_IDLETIMER.h>
+#include <linux/kdev_t.h>
#include <linux/kobject.h>
#include <linux/workqueue.h>
#include <linux/sysfs.h>
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000e: don't inadvertently re-set INTX_DISABLE
From: Jeff Kirsher @ 2010-06-18 21:14 UTC (permalink / raw)
To: Dean Nelson; +Cc: netdev, Andy Gospodarek
In-Reply-To: <20100618203630.5781.77777.send-patch@localhost.localdomain>
On Fri, Jun 18, 2010 at 13:36, Dean Nelson <dnelson@redhat.com> wrote:
> Should e1000_test_msi() fail to see an msi interrupt, it attempts to
> fallback to legacy INTx interrupts. But an error in the code may prevent
> this from happening correctly.
>
> Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR
> by clearing the SERR bit from the just read PCI_COMMAND bits as it writes
> them back out.
>
> Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR
> by writing out the version of PCI_COMMAND it had previously read.
>
> The problem with this is that e1000_test_msi_interrupt() calls
> pci_disable_msi(), which eventually ends up in pci_intx(). And because
> pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets
> cleared from PCI_COMMAND, which is what we want. But when we get back to
> e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because
> of the attempt by e1000_test_msi() to re-enable SERR.
>
> The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
> part of its attempt to re-enable SERR.
>
> During debugging/testing of this issue I found that not all the systems
> I ran on had the SERR bit set to begin with. And on some of the systems
> the same could be said for the INTX_DISABLE bit. Needless to say these
> latter systems didn't have a problem falling back to legacy INTx
> interrupts with the code as is.
>
> Signed-off-by: Dean Nelson <dnelson@redhat.com>
> CC: stable@kernel.org
>
> ---
>
> I forced the msi interrupt test to fail by commenting out the clearing
> of FLAG_MSI_TEST_FAILED in e1000_intr_msi_test().
>
> drivers/net/e1000e/netdev.c | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
Thanks Dean, I have added it to my queue.
Cheers,
Jeff
^ permalink raw reply
* [net-next-2.6 PATCH] e1000e: don't inadvertently re-set INTX_DISABLE
From: Dean Nelson @ 2010-06-18 20:36 UTC (permalink / raw)
To: netdev, Jeff Kirsher; +Cc: Andy Gospodarek
Should e1000_test_msi() fail to see an msi interrupt, it attempts to
fallback to legacy INTx interrupts. But an error in the code may prevent
this from happening correctly.
Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR
by clearing the SERR bit from the just read PCI_COMMAND bits as it writes
them back out.
Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR
by writing out the version of PCI_COMMAND it had previously read.
The problem with this is that e1000_test_msi_interrupt() calls
pci_disable_msi(), which eventually ends up in pci_intx(). And because
pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets
cleared from PCI_COMMAND, which is what we want. But when we get back to
e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because
of the attempt by e1000_test_msi() to re-enable SERR.
The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
part of its attempt to re-enable SERR.
During debugging/testing of this issue I found that not all the systems
I ran on had the SERR bit set to begin with. And on some of the systems
the same could be said for the INTX_DISABLE bit. Needless to say these
latter systems didn't have a problem falling back to legacy INTx
interrupts with the code as is.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
CC: stable@kernel.org
---
I forced the msi interrupt test to fail by commenting out the clearing
of FLAG_MSI_TEST_FAILED in e1000_intr_msi_test().
drivers/net/e1000e/netdev.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 57a7e41..79e38dc 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3419,13 +3419,18 @@ static int e1000_test_msi(struct e1000_adapter *adapter)
/* disable SERR in case the MSI write causes a master abort */
pci_read_config_word(adapter->pdev, PCI_COMMAND, &pci_cmd);
- pci_write_config_word(adapter->pdev, PCI_COMMAND,
- pci_cmd & ~PCI_COMMAND_SERR);
+ if (pci_cmd & PCI_COMMAND_SERR)
+ pci_write_config_word(adapter->pdev, PCI_COMMAND,
+ pci_cmd & ~PCI_COMMAND_SERR);
err = e1000_test_msi_interrupt(adapter);
- /* restore previous setting of command word */
- pci_write_config_word(adapter->pdev, PCI_COMMAND, pci_cmd);
+ /* re-enable SERR */
+ if (pci_cmd & PCI_COMMAND_SERR) {
+ pci_read_config_word(adapter->pdev, PCI_COMMAND, &pci_cmd);
+ pci_cmd |= PCI_COMMAND_SERR;
+ pci_write_config_word(adapter->pdev, PCI_COMMAND, pci_cmd);
+ }
/* success ! */
if (!err)
^ permalink raw reply related
* Re: inconsistent lock state
From: Andrew Morton @ 2010-06-18 20:30 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Alexander Viro, Peter Zijlstra, Sage Weil, linux-fsdevel,
linux-kernel, Dominik Brodowski, Maciej Rutecki, Eric Dumazet,
Paul E. McKenney, Lai Jiangshan, David S. Miller, netdev
In-Reply-To: <20100615112434.GA3967@swordfish.minsk.epam.com>
This was also reported by Dominik and is being tracked at
https://bugzilla.kernel.org/show_bug.cgi?id=16230
On Tue, 15 Jun 2010 14:24:34 +0300
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> Hello,
>
> kernel: [ 3272.351191]
> kernel: [ 3272.351194] =================================
> kernel: [ 3272.351199] [ INFO: inconsistent lock state ]
> kernel: [ 3272.351204] 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> kernel: [ 3272.351206] ---------------------------------
> kernel: [ 3272.351210] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> kernel: [ 3272.351215] X/3827 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: [ 3272.351218] (&(&new->fa_lock)->rlock){?.-...}, at: [<c10aefb4>] kill_fasync+0x37/0x71
> kernel: [ 3272.351232] {IN-HARDIRQ-W} state was registered at:
> kernel: [ 3272.351235] [<c104e95c>] __lock_acquire+0x281/0xbe1
> kernel: [ 3272.351243] [<c104f652>] lock_acquire+0x59/0x70
> kernel: [ 3272.351248] [<c12c6c48>] _raw_spin_lock+0x25/0x34
> kernel: [ 3272.351255] [<c10aefb4>] kill_fasync+0x37/0x71
> kernel: [ 3272.351261] [<fd220c81>] evdev_event+0x135/0x190 [evdev]
> kernel: [ 3272.351275] [<c1232003>] input_pass_event+0x6f/0xae
> kernel: [ 3272.351283] [<c1232ef5>] input_handle_event+0x38d/0x396
> kernel: [ 3272.351288] [<c1232fbf>] input_event+0x4f/0x62
> kernel: [ 3272.351293] [<c12368e4>] input_sync+0xe/0x11
> kernel: [ 3272.351299] [<c1236d72>] atkbd_interrupt+0x48b/0x541
> kernel: [ 3272.351304] [<c122ecb2>] serio_interrupt+0x35/0x68
> kernel: [ 3272.351309] [<c122fbff>] i8042_interrupt+0x264/0x26e
> kernel: [ 3272.351314] [<c106bb02>] handle_IRQ_event+0x1d/0x98
> kernel: [ 3272.351321] [<c106d506>] handle_edge_irq+0xc0/0x107
> kernel: [ 3272.351326] [<c10045ca>] handle_irq+0x1a/0x20
> kernel: [ 3272.351332] [<c100435f>] do_IRQ+0x43/0x8d
> kernel: [ 3272.351337] [<c1002d75>] common_interrupt+0x35/0x3c
> kernel: [ 3272.351342] [<c124723d>] cpuidle_idle_call+0x6a/0xa0
> kernel: [ 3272.351349] [<c100170d>] cpu_idle+0x89/0xbe
> kernel: [ 3272.351354] [<c12b6d11>] rest_init+0xb5/0xba
> kernel: [ 3272.351361] [<c148a7bf>] start_kernel+0x33b/0x340
> kernel: [ 3272.351368] [<c148a0c9>] i386_start_kernel+0xc9/0xd0
> kernel: [ 3272.351374] irq event stamp: 54104917
> kernel: [ 3272.351377] hardirqs last enabled at (54104917): [<c12c70f2>] _raw_spin_unlock_irqrestore+0x36/0x5b
> kernel: [ 3272.351384] hardirqs last disabled at (54104916): [<c12c6ced>] _raw_spin_lock_irqsave+0x13/0x42
> kernel: [ 3272.351391] softirqs last enabled at (54104732): [<c1032cf2>] __do_softirq+0xfd/0x10c
> kernel: [ 3272.351398] softirqs last disabled at (54104703): [<c1032d30>] do_softirq+0x2f/0x47
> kernel: [ 3272.351404]
> kernel: [ 3272.351405] other info that might help us debug this:
> kernel: [ 3272.351409] 3 locks held by X/3827:
> kernel: [ 3272.351412] #0: (rcu_read_lock){.+.+..}, at: [<c124fdfa>] rcu_read_lock+0x0/0x26
> kernel: [ 3272.351423] #1: (rcu_read_lock){.+.+..}, at: [<c124d5d9>] rcu_read_lock+0x0/0x26
> kernel: [ 3272.351432] #2: (rcu_read_lock){.+.+..}, at: [<c10ae429>] rcu_read_lock+0x0/0x26
> kernel: [ 3272.351442]
> kernel: [ 3272.351443] stack backtrace:
> kernel: [ 3272.351448] Pid: 3827, comm: X Not tainted 2.6.35-rc3-dbg-00106-ga75e02b-dirty #15
> kernel: [ 3272.351451] Call Trace:
> kernel: [ 3272.351456] [<c12c4ff1>] ? printk+0xf/0x11
> kernel: [ 3272.351462] [<c104e51a>] valid_state+0x133/0x141
> kernel: [ 3272.351468] [<c104e5f7>] mark_lock+0xcf/0x1b3
> kernel: [ 3272.351473] [<c104e54e>] ? mark_lock+0x26/0x1b3
> kernel: [ 3272.351479] [<c104dfd2>] ? check_usage_backwards+0x0/0x68
> kernel: [ 3272.351484] [<c104e9d0>] __lock_acquire+0x2f5/0xbe1
> kernel: [ 3272.351489] [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> kernel: [ 3272.351495] [<c104ea44>] ? __lock_acquire+0x369/0xbe1
> kernel: [ 3272.351502] [<c102ab40>] ? try_to_wake_up+0x2a8/0x2bb
> kernel: [ 3272.351508] [<c104f652>] lock_acquire+0x59/0x70
> kernel: [ 3272.351513] [<c10aefb4>] ? kill_fasync+0x37/0x71
> kernel: [ 3272.351519] [<c12c6c48>] _raw_spin_lock+0x25/0x34
> kernel: [ 3272.351524] [<c10aefb4>] ? kill_fasync+0x37/0x71
> kernel: [ 3272.351529] [<c10aefb4>] kill_fasync+0x37/0x71
> kernel: [ 3272.351534] [<c124d694>] sock_wake_async+0x77/0x83
> kernel: [ 3272.351540] [<c124fe4d>] sk_wake_async+0x2d/0x32
> kernel: [ 3272.351545] [<c1250004>] sock_def_readable+0x45/0x51
> kernel: [ 3272.351551] [<c12b0247>] unix_stream_sendmsg+0x1e2/0x269
> kernel: [ 3272.351557] [<c124fe6e>] ? rcu_read_unlock+0x1c/0x1e
> kernel: [ 3272.351562] [<c124cf1a>] __sock_sendmsg+0x51/0x5a
> kernel: [ 3272.351567] [<c124cff7>] sock_aio_write+0xd4/0xdd
> kernel: [ 3272.351575] [<c10a4d95>] do_sync_readv_writev+0x84/0xb7
> kernel: [ 3272.351582] [<c10a4288>] ? copy_from_user+0x8/0xa
> kernel: [ 3272.351587] [<c10a4e69>] ? rw_copy_check_uvector+0x55/0xc7
> kernel: [ 3272.351594] [<c1164082>] ? security_file_permission+0xf/0x11
> kernel: [ 3272.351599] [<c10a47e5>] ? rw_verify_area+0x90/0xac
> kernel: [ 3272.351605] [<c10a4f58>] do_readv_writev+0x7d/0xdf
> kernel: [ 3272.351610] [<c124cf23>] ? sock_aio_write+0x0/0xdd
> kernel: [ 3272.351615] [<c1164082>] ? security_file_permission+0xf/0x11
> kernel: [ 3272.351621] [<c10a47e5>] ? rw_verify_area+0x90/0xac
> kernel: [ 3272.351626] [<c10a4ff3>] vfs_writev+0x39/0x42
> kernel: [ 3272.351632] [<c10a5102>] sys_writev+0x3b/0x8c
> kernel: [ 3272.351637] [<c10027d3>] sysenter_do_call+0x12/0x32
>
This, I think?
From: Andrew Morton <akpm@linux-foundation.org>
Fix a lockdep-splat-causing regression introduced by
: commit 989a2979205dd34269382b357e6d4b4b6956b889
: Author: Eric Dumazet <eric.dumazet@gmail.com>
: AuthorDate: Wed Apr 14 09:55:35 2010 +0000
: Commit: David S. Miller <davem@davemloft.net>
: CommitDate: Wed Apr 21 16:19:29 2010 -0700
:
: fasync: RCU and fine grained locking
kill_fasync() can be called from both process and hard-irq context, so
fa_lock must be taken with IRQs disabled.
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16230
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Maciej Rutecki <maciej.rutecki@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/fcntl.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff -puN fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe fs/fcntl.c
--- a/fs/fcntl.c~fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe
+++ a/fs/fcntl.c
@@ -733,12 +733,14 @@ static void kill_fasync_rcu(struct fasyn
{
while (fa) {
struct fown_struct *fown;
+ unsigned long flags;
+
if (fa->magic != FASYNC_MAGIC) {
printk(KERN_ERR "kill_fasync: bad magic number in "
"fasync_struct!\n");
return;
}
- spin_lock(&fa->fa_lock);
+ spin_lock_irqsave(&fa->fa_lock, flags);
if (fa->fa_file) {
fown = &fa->fa_file->f_owner;
/* Don't send SIGURG to processes which have not set a
@@ -747,7 +749,7 @@ static void kill_fasync_rcu(struct fasyn
if (!(sig == SIGURG && fown->signum == 0))
send_sigio(fown, fa->fa_fd, band);
}
- spin_unlock(&fa->fa_lock);
+ spin_unlock_irqrestore(&fa->fa_lock, flags);
fa = rcu_dereference(fa->fa_next);
}
}
_
afaict all other lockers of fa_lock are OK (but one never really knows
with spin_lock_irq()).
Guys, please review-and-ack and I'll get it merged up.
^ permalink raw reply
* Re: Distributed Switch Architecture(DSA)
From: Lennert Buytenhek @ 2010-06-18 20:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF4FC7639D.8FBCAF3B-ONC1257746.004AF9D3-C1257746.005397F6@transmode.se>
On Fri, Jun 18, 2010 at 05:13:03PM +0200, Joakim Tjernlund wrote:
> > > > > > > Now I want to add STP/RSTP to the switch. How would one do that?
> > > > > >
> > > > > > First, you'll want the hardware bridging patches that I posted to
> > > > > > netdev@ a while back, e.g.:
> > > > > >
> > > > > > http://patchwork.ozlabs.org/patch/16578/
> > > > >
> > > > > I see, will have to study this a bit closer. One question though,
> > > > > does this disable MAC learning in the linux bridge?
> > > >
> > > > No, why should it?
> > >
> > > Doesn't the HW switch handle all MAC leaning? Why duplicate
> > > this in the SW bridge?
> > > I figured the HW switch would offload the SW bridge this task.
> >
> > Imagine the case where you bridge lan1, lan2 (both on the switch chip)
> > into br0, together with wlan0 (which is not on the switch chip).
> >
> > Now a packet is sent out of br0. Should it be sent to wlan0 or to the
> > switch chip? How will you make this decision without an address database
> > on the Linux side?
>
> True, in this case you need it, but for only HW switch I/Fs you don't
> need it and there can be several hundreds of MAC addresses passing
> trough the HW switch. It would be nice if one didn't need to pass
> all those up to the SW bridge, especially if you have a small embedded
> CPU.
I think you overestimate the effect that address learning will have on
the host CPU. It only needs to happen for the first packet for every
new MAC address, and address flooding attacks is something you'll need
to address in either case.
If you're really worried about this scenario, then just configure your
boot loader to bridge all switch ports together, and don't load the DSA
driver. The switch will then appear as a single interface, 'eth0' (or
whatever your SoC calls it), over which you can talk directly without
any form of tagging. You won't be able to use any advanced features,
though.
> > > > > Do you have any idea how to do DSA on a Broadcom switch?
> > > >
> > > > I have no idea. When I originally submitted the DSA code for merging,
> > > > I contacted Broadcom people about adding support for Broadcom switch
> > > > chips to it, but I never heard back from them.
> > >
> > > OK. With DSA, how does one configure VLANs, policing and parameters in the
> > > HW switch that don't map or exist in the linux bridge?
> >
> > The idea is to use existing kernel interface for this as much as
> > possible. So e.g. if you do:
> >
> > vconfig add lan1 123
> > vconfig add lan2 123
> > brctl addbr br123
> > brctl addif br123 lan1.123
> > brctl addif br123 lan2.123
> >
> > Then the DSA code (or some userspace netlink listener helper, or some
> > combination of both) should ideally also detect that VLAN 123 on
> > interfaces lan1 and lan2 are to be bridged together, and program the
> > switch chip accordingly. I think all VLAN configurations that at least
> > the Marvell hardware supports can be expressed this way.
>
> Yes, but I image that this breaks down when you want to do something
> a bit more advanced. For example I don't think linux VLANs supports
> "shared VLAN learning"(SVL) and to configure a HW switch to do SVL
> one would first have to impl. that in Linux VLAN and then add the DSA
> code to get the config to the switch.
Yes. But that's really the best way to do it, in my humble opinion.
If you don't go the host networking stack integration route, you end
up with something like the vendor drivers. Which work fine for most
scenarios.. until you want to do something like talking TCP/IP using
the host TCP stack over some of the switch ports, at which point the
lack of host networking stack integration comes to bite you.
> Not sure how one would express whether VLAN tags should be stripped
> off or not when egressing the HW switch's physical port.
If you transmit a packet onto 'lan', it will be sent to the switch chip
with an "untagged" DSA tag. If you transmit a packet onto 'lan.123',
it will be sent to the switch chip with a "tagged" DSA tag. See
net/dsa/tag_dsa.c for details.
> Furthermore, suppose one have a big HW switch, 48 ports, and lots of
> VLANs in that HW switch one would have to create a lot of virtual I/Fs
> and VLANs in linux just to configure the HW switch. This wastes
> resources on the CPU.
Where the 'resource waste' is on the order of a couple of tens or
hundreds of kilobytes of RAM. If this is a problem for your host
CPU, I think you have bigger problems anyway.
> > To configure things like ingress/egress rate limiting and such in the
> > switch chip for which there is no Linux counterpart interface, I suppose
> > some sysfs interface or so might suffice.
>
> Yes, there are aspects of a HW switch that doesn't map into DSA currently.
> Perhaps one should add some framework to support this?
Sounds good.
^ permalink raw reply
* [PATCH net-next 5/9] cxgb4: switch to 64 bit inteface statistics
From: Dimitris Michailidis @ 2010-06-18 20:05 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1276891535-13967-5-git-send-email-dm@chelsio.com>
Implement ndo_get_stats64, remove ndo_get_stats.
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4_main.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index baf4f0a..6bfe7d6 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -2527,12 +2527,12 @@ static int cxgb_close(struct net_device *dev)
return t4_enable_vi(adapter, 0, pi->viid, false, false);
}
-static struct net_device_stats *cxgb_get_stats(struct net_device *dev)
+static struct rtnl_link_stats64 *cxgb_get_stats(struct net_device *dev)
{
struct port_stats stats;
struct port_info *p = netdev_priv(dev);
struct adapter *adapter = p->adapter;
- struct net_device_stats *ns = &dev->stats;
+ struct rtnl_link_stats64 *ns = &dev->stats64;
spin_lock(&adapter->stats_lock);
t4_get_port_stats(adapter, p->tx_chan, &stats);
@@ -2675,7 +2675,7 @@ static const struct net_device_ops cxgb4_netdev_ops = {
.ndo_open = cxgb_open,
.ndo_stop = cxgb_close,
.ndo_start_xmit = t4_eth_xmit,
- .ndo_get_stats = cxgb_get_stats,
+ .ndo_get_stats64 = cxgb_get_stats,
.ndo_set_rx_mode = cxgb_set_rxmode,
.ndo_set_mac_address = cxgb_set_mac_addr,
.ndo_validate_addr = eth_validate_addr,
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 3/9] cxgb4: implement EEH
From: Dimitris Michailidis @ 2010-06-18 20:05 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1276891535-13967-3-git-send-email-dm@chelsio.com>
Implement the pci_error_handlers methods for EEH.
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4.h | 1 +
drivers/net/cxgb4/cxgb4_main.c | 108 +++++++++++++++++++++++++++++++++++++++-
drivers/net/cxgb4/l2t.c | 7 +++
drivers/net/cxgb4/t4_hw.c | 11 +++-
4 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4.h b/drivers/net/cxgb4/cxgb4.h
index bfa1366..5e37c1e 100644
--- a/drivers/net/cxgb4/cxgb4.h
+++ b/drivers/net/cxgb4/cxgb4.h
@@ -650,6 +650,7 @@ void t4_intr_disable(struct adapter *adapter);
void t4_intr_clear(struct adapter *adapter);
int t4_slow_intr_handler(struct adapter *adapter);
+int t4_wait_dev_ready(struct adapter *adap);
int t4_link_start(struct adapter *adap, unsigned int mbox, unsigned int port,
struct link_config *lc);
int t4_restart_aneg(struct adapter *adap, unsigned int mbox, unsigned int port);
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 60f6ea0..baf4f0a 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -2483,6 +2483,7 @@ static void cxgb_down(struct adapter *adapter)
t4_intr_disable(adapter);
cancel_work_sync(&adapter->tid_release_task);
adapter->tid_release_task_busy = false;
+ adapter->tid_release_head = NULL;
if (adapter->flags & USING_MSIX) {
free_msix_queue_irqs(adapter);
@@ -2907,6 +2908,108 @@ bye: if (ret != -ETIMEDOUT && ret != -EIO)
return ret;
}
+/* EEH callbacks */
+
+static pci_ers_result_t eeh_err_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
+{
+ int i;
+ struct adapter *adap = pci_get_drvdata(pdev);
+
+ if (!adap)
+ goto out;
+
+ rtnl_lock();
+ adap->flags &= ~FW_OK;
+ notify_ulds(adap, CXGB4_STATE_START_RECOVERY);
+ for_each_port(adap, i) {
+ struct net_device *dev = adap->port[i];
+
+ netif_device_detach(dev);
+ netif_carrier_off(dev);
+ }
+ if (adap->flags & FULL_INIT_DONE)
+ cxgb_down(adap);
+ rtnl_unlock();
+ pci_disable_device(pdev);
+out: return state == pci_channel_io_perm_failure ?
+ PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_NEED_RESET;
+}
+
+static pci_ers_result_t eeh_slot_reset(struct pci_dev *pdev)
+{
+ int i, ret;
+ struct fw_caps_config_cmd c;
+ struct adapter *adap = pci_get_drvdata(pdev);
+
+ if (!adap) {
+ pci_restore_state(pdev);
+ pci_save_state(pdev);
+ return PCI_ERS_RESULT_RECOVERED;
+ }
+
+ if (pci_enable_device(pdev)) {
+ dev_err(&pdev->dev, "cannot reenable PCI device after reset\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+ pci_restore_state(pdev);
+ pci_save_state(pdev);
+ pci_cleanup_aer_uncorrect_error_status(pdev);
+
+ if (t4_wait_dev_ready(adap) < 0)
+ return PCI_ERS_RESULT_DISCONNECT;
+ if (t4_fw_hello(adap, 0, 0, MASTER_MUST, NULL))
+ return PCI_ERS_RESULT_DISCONNECT;
+ adap->flags |= FW_OK;
+ if (adap_init1(adap, &c))
+ return PCI_ERS_RESULT_DISCONNECT;
+
+ for_each_port(adap, i) {
+ struct port_info *p = adap2pinfo(adap, i);
+
+ ret = t4_alloc_vi(adap, 0, p->tx_chan, 0, 0, 1, NULL, NULL);
+ if (ret < 0)
+ return PCI_ERS_RESULT_DISCONNECT;
+ p->viid = ret;
+ p->xact_addr_filt = -1;
+ }
+
+ t4_load_mtus(adap, adap->params.mtus, adap->params.a_wnd,
+ adap->params.b_wnd);
+ if (cxgb_up(adap))
+ return PCI_ERS_RESULT_DISCONNECT;
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+static void eeh_resume(struct pci_dev *pdev)
+{
+ int i;
+ struct adapter *adap = pci_get_drvdata(pdev);
+
+ if (!adap)
+ return;
+
+ rtnl_lock();
+ for_each_port(adap, i) {
+ struct net_device *dev = adap->port[i];
+
+ if (netif_running(dev)) {
+ link_start(dev);
+ cxgb_set_rxmode(dev);
+ }
+ netif_device_attach(dev);
+ }
+ rtnl_unlock();
+}
+
+static struct pci_error_handlers cxgb4_eeh = {
+ .error_detected = eeh_err_detected,
+ .slot_reset = eeh_slot_reset,
+ .resume = eeh_resume,
+};
+
static inline bool is_10g_port(const struct link_config *lc)
{
return (lc->supported & FW_PORT_CAP_SPEED_10G) != 0;
@@ -3154,8 +3257,10 @@ static int __devinit init_one(struct pci_dev *pdev,
/* We control everything through PF 0 */
func = PCI_FUNC(pdev->devfn);
- if (func > 0)
+ if (func > 0) {
+ pci_save_state(pdev); /* to restore SR-IOV later */
goto sriov;
+ }
err = pci_enable_device(pdev);
if (err) {
@@ -3396,6 +3501,7 @@ static struct pci_driver cxgb4_driver = {
.id_table = cxgb4_pci_tbl,
.probe = init_one,
.remove = __devexit_p(remove_one),
+ .err_handler = &cxgb4_eeh,
};
static int __init cxgb4_init_module(void)
diff --git a/drivers/net/cxgb4/l2t.c b/drivers/net/cxgb4/l2t.c
index 9f96724..5b990d2 100644
--- a/drivers/net/cxgb4/l2t.c
+++ b/drivers/net/cxgb4/l2t.c
@@ -310,6 +310,13 @@ static void t4_l2e_free(struct l2t_entry *e)
neigh_release(e->neigh);
e->neigh = NULL;
}
+ while (e->arpq_head) {
+ struct sk_buff *skb = e->arpq_head;
+
+ e->arpq_head = skb->next;
+ kfree(skb);
+ }
+ e->arpq_tail = NULL;
}
spin_unlock_bh(&e->lock);
diff --git a/drivers/net/cxgb4/t4_hw.c b/drivers/net/cxgb4/t4_hw.c
index 5c81c55..0c8a84a 100644
--- a/drivers/net/cxgb4/t4_hw.c
+++ b/drivers/net/cxgb4/t4_hw.c
@@ -221,6 +221,13 @@ int t4_wr_mbox_meat(struct adapter *adap, int mbox, const void *cmd, int size,
if ((size & 15) || size > MBOX_LEN)
return -EINVAL;
+ /*
+ * If the device is off-line, as in EEH, commands will time out.
+ * Fail them early so we don't waste time waiting.
+ */
+ if (adap->pdev->error_state != pci_channel_io_normal)
+ return -EIO;
+
v = MBOWNER_GET(t4_read_reg(adap, ctl_reg));
for (i = 0; v == MBOX_OWNER_NONE && i < 3; i++)
v = MBOWNER_GET(t4_read_reg(adap, ctl_reg));
@@ -3045,7 +3052,7 @@ static void __devinit init_link_config(struct link_config *lc,
}
}
-static int __devinit wait_dev_ready(struct adapter *adap)
+int t4_wait_dev_ready(struct adapter *adap)
{
if (t4_read_reg(adap, PL_WHOAMI) != 0xffffffff)
return 0;
@@ -3093,7 +3100,7 @@ int __devinit t4_prep_adapter(struct adapter *adapter)
{
int ret;
- ret = wait_dev_ready(adapter);
+ ret = t4_wait_dev_ready(adapter);
if (ret < 0)
return ret;
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 4/9] cxgb4: set dev_id to the port number
From: Dimitris Michailidis @ 2010-06-18 20:05 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1276891535-13967-4-git-send-email-dm@chelsio.com>
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/t4_hw.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4/t4_hw.c b/drivers/net/cxgb4/t4_hw.c
index 0c8a84a..4c956fb 100644
--- a/drivers/net/cxgb4/t4_hw.c
+++ b/drivers/net/cxgb4/t4_hw.c
@@ -3162,6 +3162,7 @@ int __devinit t4_port_init(struct adapter *adap, int mbox, int pf, int vf)
p->rss_size = rss_size;
memcpy(adap->port[i]->dev_addr, addr, ETH_ALEN);
memcpy(adap->port[i]->perm_addr, addr, ETH_ALEN);
+ adap->port[i]->dev_id = j;
ret = ntohl(c.u.info.lstatus_to_modtype);
p->mdio_addr = (ret & FW_PORT_CMD_MDIOCAP) ?
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 7/9] cxgb4: add a missing error interrupt
From: Dimitris Michailidis @ 2010-06-18 20:05 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1276891535-13967-7-git-send-email-dm@chelsio.com>
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/t4_hw.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4/t4_hw.c b/drivers/net/cxgb4/t4_hw.c
index 4c956fb..5c058ea 100644
--- a/drivers/net/cxgb4/t4_hw.c
+++ b/drivers/net/cxgb4/t4_hw.c
@@ -1135,6 +1135,7 @@ static void cim_intr_handler(struct adapter *adapter)
static void ulprx_intr_handler(struct adapter *adapter)
{
static struct intr_info ulprx_intr_info[] = {
+ { 0x1800000, "ULPRX context error", -1, 1 },
{ 0x7fffff, "ULPRX parity error", -1, 1 },
{ 0 }
};
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 9/9] cxgb4: minor cleanup
From: Dimitris Michailidis @ 2010-06-18 20:05 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1276891535-13967-9-git-send-email-dm@chelsio.com>
Remove an unused flag and replace couple constants with enums.
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4.h | 1 -
drivers/net/cxgb4/cxgb4_main.c | 4 ++--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4.h b/drivers/net/cxgb4/cxgb4.h
index 5e37c1e..62804bb 100644
--- a/drivers/net/cxgb4/cxgb4.h
+++ b/drivers/net/cxgb4/cxgb4.h
@@ -309,7 +309,6 @@ enum { /* adapter flags */
FULL_INIT_DONE = (1 << 0),
USING_MSI = (1 << 1),
USING_MSIX = (1 << 2),
- QUEUES_BOUND = (1 << 3),
FW_OK = (1 << 4),
};
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 352c770..27f65b5 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -2758,8 +2758,8 @@ static int adap_init1(struct adapter *adap, struct fw_caps_config_cmd *c)
if (ret < 0)
return ret;
- ret = t4_cfg_pfvf(adap, 0, 0, 0, 64, 64, 64, 0, 0, 4, 0xf, 0xf, 16,
- FW_CMD_CAP_PF, FW_CMD_CAP_PF);
+ ret = t4_cfg_pfvf(adap, 0, 0, 0, MAX_EGRQ, 64, MAX_INGQ, 0, 0, 4,
+ 0xf, 0xf, 16, FW_CMD_CAP_PF, FW_CMD_CAP_PF);
if (ret < 0)
return ret;
--
1.5.4
^ permalink raw reply related
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