* Re: [PATCH] gainfar.c : skb_over_panic
From: David Miller @ 2010-06-21 20:47 UTC (permalink / raw)
To: liberty; +Cc: galak, netdev
In-Reply-To: <4C1F2D39.9050804@extricom.com>
From: Eran Liberty <liberty@extricom.com>
Date: Mon, 21 Jun 2010 12:13:29 +0300
> I have compared the suggested patch with what the function
> skb_recycle_check() does. Both patch and skb_recycle_check()
> have skb_reset_tail_pointer(). While the patch zero only skb->len,
> skb_recycle_check()
> clears the whole skb (up to tail). On top of that skb_recycle_check()
> preforms a whole set of other checks and cleanups. The question is,
> which action is MORE correct: the pin-point action of the patch
> suggested or the broader checks of skb_recycle_check() function?
At this stage in the code we know exactly what modifications, if any,
we've made to the SKB state. Therefore it makes sense to only fix
up the tiny amount of changes we've made instead of doing a complete
skb_recycle_call() which seems entirely excessive in this situation.
^ permalink raw reply
* Re: [PATCH] Fix a typo in netlink.h
From: David Miller @ 2010-06-21 20:45 UTC (permalink / raw)
To: justinmattock; +Cc: trivial, netdev
In-Reply-To: <1276921793-24147-1-git-send-email-justinmattock@gmail.com>
From: "Justin P. Mattock" <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 21:29:53 -0700
> Fix a typo in include/net/netlink.h
> should be finalize instead of finanlize
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: Jiri Pirko @ 2010-06-21 20:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100621.133806.226761715.davem@davemloft.net>
Mon, Jun 21, 2010 at 10:38:06PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jpirko@redhat.com>
>Date: Mon, 21 Jun 2010 21:34:06 +0200
>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>...
>> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> -
>
>Jiri, it is used by every single pr_*() logging call made
>in this file.
>
>I was hoping that this facilty and the voluminous amounty of pervasive
>usage of this in the networking drivers nowadays would make it
>familiar to active hackers like you :-)
Ough, right, missed that. That's just strange. I don't like this.
>--
>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: [net-next-2.6 PATCH 4/4] e1000e: disable gig speed when in S0->Sx transition
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045946.6728.12416.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:59:48 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Most of this workaround is necessary for all ICHx/PCH parts so one of
> the two MAC-type checks can be removed.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] e1000e: packet split should not be used with early receive
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045925.6728.43858.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:59:27 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Originally it was thought there were issues with ICHx/PCH parts with packet
> split when jumbo frames were enabled but in fact it is really only when
> early-receive is enabled (via ERT register) on these parts. Use packet
> split with jumbos but only when early-receive is not enabled.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/4] e1000e: do not touch PHY page 800 registers when link speed is 1000Mbps
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045904.6728.18894.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:59:06 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The PHY on 82577/82578 has issues when the registers on page 800 are
> accessed when in gigabit mode. Do not clear the Wakeup Control register
> when resetting the part since it is on page 800 (and will be cleared on
> reset anyway).
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/4] e1000e: avoid polling h/w registers during link negotiation
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045804.6728.37945.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:58:43 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Avoid touching hardware registers when possible, otherwise link negotiation
> can get messed up when user-level scripts are rapidly polling the driver to
> see if/when link is up. Use the saved link state information instead when
> possible.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] NET: MIPSsim: Fix modpost warning.
From: David Miller @ 2010-06-21 20:40 UTC (permalink / raw)
To: ralf; +Cc: netdev
In-Reply-To: <20100621134450.GA10265@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 21 Jun 2010 14:44:50 +0100
> $ make CONFIG_DEBUG_SECTION_MISMATCH=y
> [...]
> WARNING: drivers/net/built-in.o(.data+0x0): Section mismatch in reference from the variable mipsnet_driver to the function .init.text:mipsnet_probe()
> The variable mipsnet_driver references
> the function __init mipsnet_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
> [...]
>
> Fixed by making mipsnet_probe __devinit.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: David Miller @ 2010-06-21 20:38 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100621193405.GG2656@psychotron.bos.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Mon, 21 Jun 2010 21:34:06 +0200
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
...
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
Jiri, it is used by every single pr_*() logging call made
in this file.
I was hoping that this facilty and the voluminous amounty of pervasive
usage of this in the networking drivers nowadays would make it
familiar to active hackers like you :-)
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Peter P Waskiewicz Jr @ 2010-06-21 20:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, jeff@garzik.org, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1277150272.2100.47.camel@achroite.uk.solarflarecom.com>
On Mon, 21 Jun 2010, Ben Hutchings wrote:
> On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote:
>> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>>
>> Program underlying ethernet devices with n-tuple flow classification
>> filters.
>>
>> This also adds a new flag to ethtool_flags, allowing n-tuple
>> programming to be toggled using the set_flags call.
>
> I just noticed a problem with the implementation which makes me wonder
> whether this was tested at all:
Yes, it was tested. We didn't hit every corner case, which I think your
catch below is a corner case issue. Our hardware can only do so much.
>
> [...]
>> +static struct cmdline_info cmdline_ntuple[] = {
>> + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL },
>> + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL },
>> + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL },
>> + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL },
>> + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL },
>> + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL },
>> + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL },
>> + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL },
>> + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL },
>> + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL },
>> + { "user-def", CMDL_INT, &ntuple_fs.data, NULL },
>> + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL },
>> + { "action", CMDL_INT, &ntuple_fs.action, NULL },
>> +};
> [...]
>> + if (mode == MODE_SNTUPLE) {
>> + if (!strcmp(argp[i], "flow-type")) {
>> + i += 1;
>> + if (i >= argc) {
>> + show_usage(1);
>> + break;
>> + }
>> + ntuple_fs.flow_type =
>> + rxflow_str_to_type(argp[i]);
>> + i += 1;
>> + parse_generic_cmdline(argc, argp, i,
>> + &sntuple_changed,
>> + cmdline_ntuple,
>> + ARRAY_SIZE(cmdline_ntuple));
>> + i = argc;
>> + break;
>> + } else {
>> + show_usage(1);
>> + }
>> + break;
>> + }
> [...]
>
> parse_generic_cmdline() will write an int for each argument defined with
> type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of
> type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some
> of them are big-endian. I also wonder whether anyone really wants to
> enter an IPv4 address as a single integer.
The assignment is broken since 'p' is an int. That can be fixed. Also,
we can fix the 64-bit field. I added the user-defined field to be 64-bit
so that we weren't locking anyone down. My hardware only uses 2 bytes, so
I was only able to test that.
When this was proposed, we added the IPv4 address as a single int. People
seemed ok with it at the time, so we went with it. If you have a
different approach, please present it.
Cheers,
-PJ
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-21 20:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Hagen Paul Pfeifer, netdev, Octavian Purdila
In-Reply-To: <20100621102508.2075d677@nehalam>
On Mon, Jun 21, 2010 at 10:25:08AM -0700, Stephen Hemminger wrote:
> It is not handling the case of ifp == NULL.
>
> Maybe the following (move the assignment into the if block).
>
> --- a/net/ipv6/ndisc.c 2010-06-21 10:22:20.825637690 -0700
> +++ b/net/ipv6/ndisc.c 2010-06-21 10:24:31.573011996 -0700
> @@ -586,6 +586,7 @@ static void ndisc_send_na(struct net_dev
> src_addr = solicited_addr;
> if (ifp->flags & IFA_F_OPTIMISTIC)
> override = 0;
> + inc_opt |= ifp->idev->cnf.force_tllao;
> in6_ifa_put(ifp);
> } else {
> if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
> @@ -599,7 +600,6 @@ static void ndisc_send_na(struct net_dev
> icmp6h.icmp6_solicited = solicited;
> icmp6h.icmp6_override = override;
>
> - inc_opt |= ifp->idev->cnf.force_tllao;
> __ndisc_send(dev, neigh, daddr, src_addr,
> &icmp6h, solicited_addr,
> inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
>
>
>
Thanks a lot! This fix seems to work fine for me (tested locally only).
I'll see what happens when I apply it to my server tomorrow.
Curious though as to why I wasn't able to reproduce it when compiling
the kernel with Gentoo's GCC. It doesn't look like it should make any
difference. Maybe I made a mistake when I tested it with Gentoo.
Regards
Andreas Klauer
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Ben Hutchings @ 2010-06-21 19:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: jeff, davem, netdev, gospo, Peter P Waskiewicz Jr
In-Reply-To: <20100204075101.16661.95658.stgit@localhost.localdomain>
On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote:
> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>
> Program underlying ethernet devices with n-tuple flow classification
> filters.
>
> This also adds a new flag to ethtool_flags, allowing n-tuple
> programming to be toggled using the set_flags call.
I just noticed a problem with the implementation which makes me wonder
whether this was tested at all:
[...]
> +static struct cmdline_info cmdline_ntuple[] = {
> + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL },
> + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL },
> + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL },
> + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL },
> + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL },
> + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL },
> + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL },
> + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL },
> + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL },
> + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL },
> + { "user-def", CMDL_INT, &ntuple_fs.data, NULL },
> + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL },
> + { "action", CMDL_INT, &ntuple_fs.action, NULL },
> +};
[...]
> + if (mode == MODE_SNTUPLE) {
> + if (!strcmp(argp[i], "flow-type")) {
> + i += 1;
> + if (i >= argc) {
> + show_usage(1);
> + break;
> + }
> + ntuple_fs.flow_type =
> + rxflow_str_to_type(argp[i]);
> + i += 1;
> + parse_generic_cmdline(argc, argp, i,
> + &sntuple_changed,
> + cmdline_ntuple,
> + ARRAY_SIZE(cmdline_ntuple));
> + i = argc;
> + break;
> + } else {
> + show_usage(1);
> + }
> + break;
> + }
[...]
parse_generic_cmdline() will write an int for each argument defined with
type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of
type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some
of them are big-endian. I also wonder whether anyone really wants to
enter an IPv4 address as a single integer.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: Jiri Pirko @ 2010-06-21 19:34 UTC (permalink / raw)
To: netdev; +Cc: davem
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a95a41b..e079117 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -31,8 +31,6 @@
*
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
^ permalink raw reply related
* Re: PATCH: uninitialized memory access in tcp_parse_options
From: Mathieu Lacage @ 2010-06-21 19:10 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev
In-Reply-To: <3E37AD8C-208F-42B8-AA04-E0B294D909A8@earthlink.net>
On Mon, 2010-06-21 at 11:02 -0700, Mitchell Erblich wrote:
> The standard default for TCP with IPv4 is 536, which
> translates to 576 MTU.
>
> Thus, why don't you init mss to 536?
I don't know: I am not a tcp expert and I am not sure I really
understand the way this function is expected to be used by callers but I
sent a patch to make sure that someone would feel compelled to find the
right fix. It looks like callers of this function are expected to
initialize the fields themselves so, the idea of doing the
initialization in tcp_parse_options is probably bad.
Mathieu
--
Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
Tel: +33 4 9238 5056
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:56 UTC (permalink / raw)
To: Nick Bowler
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <20100621135857.GA21159-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
On Monday, June 21, 2010, Nick Bowler wrote:
> On 00:11 Mon 21 Jun , Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
>
> Didn't see this one in the list:
>
> Why is kslowd accumulating so much CPU time?
> http://thread.gmane.org/gmane.linux.kernel/996907
Thanks, I'm going to add it to the list.
Rafael
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:54 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <1277074706.21312.8.camel@maxim-laptop>
On Monday, June 21, 2010, Maxim Levitsky wrote:
> On Mon, 2010-06-21 at 00:11 +0200, Rafael J. Wysocki wrote:
> > This message contains a list of some regressions from 2.6.34,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
> >
> > Each entry from the list will be sent additionally in an automatic reply
> > to this message with CCs to the people involved in reporting and handling
> > the issue.
> >
> >
> > Listed regressions statistics:
> >
> > Date Total Pending Unresolved
> > ----------------------------------------
> > 2010-06-21 46 37 26
> > 2010-06-09 15 13 10
> >
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16255
> > Subject : 2.6.35-rc3 deadlocks on semaphore operations
> > Submitter : Christoph Lameter <cl@linux-foundation.org>
> > Date : 2010-06-18 14:49 (3 days old)
> > Message-ID : <alpine.DEB.2.00.1006180940140.11575@router.home>
> > References : http://marc.info/?l=linux-kernel&m=127687262727707&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16248
> > Subject : inconsistent lock state
> > Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Date : 2010-06-15 11:24 (6 days old)
> > Message-ID : <20100615112434.GA3967@swordfish.minsk.epam.com>
> > References : http://marc.info/?l=linux-kernel&m=127660087625903&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16247
> > Subject : drm/i915 BUG with 2.6.35-rc
> > Submitter : Benny Halevy <bhalevy@panasas.com>
> > Date : 2010-06-14 22:38 (7 days old)
> > Message-ID : <4C16AF56.1040002@panasas.com>
> > References : http://marc.info/?l=linux-kernel&m=127655510531367&w=2
>
>
> Don't have time to test, but I confirm that running compiz without
> mode-setting (ubuntu 8.10) hangs the system. (device is i945)
> It might be related to few intel regressions on this list.
>
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> > Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2010-06-14 17:24 (7 days old)
> > Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
> I was hit by this bug. Fix is now present in iwlwifi tree.
> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=4d23e4e5eb50431426facf192354ad2506e2dd40
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16234
> > Subject : [2.6.35-rc3] reboot mutex 'bug'...
> > Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
> > Date : 2010-06-14 15:16 (7 days old)
> > Message-ID : <AANLkTimDcTnyEPmt2ZcCM1UWtn4AYKotiqyjobJApkO7@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127652861118933&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16232
> > Subject : 2.6.35-rc3 - WARNING:iwl_set_dynamic_key
> > Submitter : Mario Guenterberg <mario.guenterberg@googlemail.com>
> > Date : 2010-06-14 11:55 (7 days old)
> > Message-ID : <20100614115510.GA7904@guenti-laptop>
> > References : http://marc.info/?l=linux-kernel&m=127651695627147&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16230
> > Subject : inconsistent IN-HARDIRQ-W -> HARDIRQ-ON-W usage: fasync, 2.6.35-rc3
> > Submitter : Dominik Brodowski <linux@dominikbrodowski.net>
> > Date : 2010-06-13 9:53 (8 days old)
> > Message-ID : <20100613095305.GA13231@comet.dominikbrodowski.net>
> > References : http://marc.info/?l=linux-kernel&m=127642282208277&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
> > Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
> > Submitter : Brian Bloniarz <phunge0@hotmail.com>
> > Date : 2010-06-16 17:57 (5 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16222
> > Subject : 2.6.35-rc{12} regression: inactive console corrupted
> > Submitter : Pavel Machek <pavel@ucw.cz>
> > Date : 2010-06-12 10:33 (9 days old)
> > Message-ID : <20100612103321.GA1458@ucw.cz>
> > References : http://marc.info/?l=linux-kernel&m=127633882614501&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
> > Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-11 20:31 (10 days old)
> > Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16205
> > Subject : acpi: freeing invalid memtype bf799000-bf79a000
> > Submitter : Marcin Slusarz <marcin.slusarz@gmail.com>
> > Date : 2010-06-09 20:09 (12 days old)
> > Message-ID : <20100609200910.GA2876@joi.lan>
> > References : http://marc.info/?l=linux-kernel&m=127611427029914&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16201
> > Subject : SIOCGIWFREQ ioctl fails to get frequency info
> > Submitter : nuh <nuh@mailinator.net>
> > Date : 2010-06-14 10:45 (7 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16199
> > Subject : 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-07 18:14 (14 days old)
> > Message-ID : <AANLkTin2pPqOUx--9fIX3BH3e-cU6oCRufijcx_4ozx5@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127593447812015&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16198
> > Subject : Running make install over sshfs is painful now
> > Submitter : Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date : 2010-06-07 6:53 (14 days old)
> > Message-ID : <20100607065324.GA25590@core.coreip.homeip.net>
> > References : http://marc.info/?l=linux-kernel&m=127589362011138&w=2
> I confirm this.
> Its direct result of adding '+' to kernel version.
> This just causes only troubles.
> I suggest to have a config option for it.
Thanks for the updates.
Rafael
^ permalink raw reply
* Re: [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Jeff Garzik @ 2010-06-21 18:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1277142725.2100.36.camel@achroite.uk.solarflarecom.com>
On 06/21/2010 01:52 PM, Ben Hutchings wrote:
> On Mon, 2010-06-21 at 13:39 -0400, Jeff Garzik wrote:
>> On 06/21/2010 09:06 AM, Ben Hutchings wrote:
>>> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
>>> ---
>>> drivers/net/sfc/ethtool.c | 16 +++
>>> drivers/net/sfc/io.h | 7 +
>>> drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
>>> drivers/net/sfc/nic.h | 3 +
>>> 4 files changed, 292 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
>>> index 22026bf..81b7f39 100644
>>> --- a/drivers/net/sfc/ethtool.c
>>> +++ b/drivers/net/sfc/ethtool.c
>>> @@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
>>> strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
>>> }
>>>
>>> +static int efx_ethtool_get_regs_len(struct net_device *net_dev)
>>> +{
>>> + return efx_nic_get_regs_len(netdev_priv(net_dev));
>>> +}
>>> +
>>> +static void efx_ethtool_get_regs(struct net_device *net_dev,
>>> + struct ethtool_regs *regs, void *buf)
>>> +{
>>> + struct efx_nic *efx = netdev_priv(net_dev);
>>> +
>>> + regs->version = efx->type->revision;
>>> + efx_nic_get_regs(efx, buf);
>>
>> regs->version is really the version of hardware register dump exported
>> to userspace. You might want to hardcode this in the driver, to be
>> changed when efx_nic_regs[] array changes, rather than tying
>> regs->version directly to the SFC hardware architecture revision.
>>
>> However, if that limitation is OK with you, ie. ethtool register dump
>> code will change when h/w arch rev changes, then
>
> This is exactly what we want, as the set of defined registers (and
> fields within each register) will change in each architecture revision.
> (It may not change in each chip revision, but efx_nic_type::revision is
> supposed to reflect the architecture revision.)
>
> Although this code doesn't include an explicit format version, we can
> consider the current format to be version 0 and increment it if we ever
> want to make changes to the format for existing NIC revisions.
Yep -- that's the intented purpose. If you ever want to dump additional
registers or information, it might be useful to avoid a hard coupling
with the hardware arch revision.
Either way is fine, of course.
Jeff
^ permalink raw reply
* Re: PATCH: uninitialized memory access in tcp_parse_options
From: Mitchell Erblich @ 2010-06-21 18:02 UTC (permalink / raw)
To: Mathieu Lacage; +Cc: netdev
In-Reply-To: <1277127249.9469.53.camel@localhost.localdomain>
Mathieu Lacage,
The standard default for TCP with IPv4 is 536, which
translates to 576 MTU.
Thus, why don't you init mss to 536?
Mitchell Erblich
===============
On Jun 21, 2010, at 6:34 AM, Mathieu Lacage wrote:
> valgrind reports the following error:
>
> ==15996== Conditional jump or move depends on uninitialised value(s)
> ==15996== at 0x6E63E4C: tcp_parse_options (tcp_input.c:3776)
> ==15996== by 0x6E856A3: tcp_check_req (tcp_minisocks.c:532)
> ==15996== by 0x6E7F0C6: tcp_v4_hnd_req (tcp_ipv4.c:1492)
> ==15996== by 0x6E7F55A: tcp_v4_do_rcv (tcp_ipv4.c:1571)
> ==15996== by 0x6E808C5: tcp_v4_rcv (tcp_ipv4.c:1690)
> ==15996== by 0x6E2DA7B: ip_local_deliver_finish (ip_input.c:231)
> ==15996== by 0x6E2DE0C: ip_local_deliver (netfilter.h:206)
> ==15996== by 0x6E2E940: ip_rcv_finish (dst.h:255)
> ==15996== by 0x6E2F17C: ip_rcv (netfilter.h:206)
> ==15996== by 0x6D53D0E: __netif_receive_skb (dev.c:2873)
> ==15996== by 0x6D5521F: process_backlog (dev.c:3305)
> ==15996== by 0x6D55A20: net_rx_action (dev.c:3435)
>
> The attached patch (generated against net-next-2.6) fixes that error by
> making sure that user_mss is correctly initialized at the start of
> tcp_parse_options, just like saw_tstamp is initialized at the start of
> this function. To try to be coherent, this patch also removes the
> redundant initialization of saw_tstamp from the caller, tcp_check_req.
>
> hope this helps,
> Mathieu
> --
> Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
> Tel: +33 4 9238 5056
> <tcp-options.patch>
^ permalink raw reply
* Re: [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Ben Hutchings @ 2010-06-21 17:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <4C1FA3C1.4020006@garzik.org>
On Mon, 2010-06-21 at 13:39 -0400, Jeff Garzik wrote:
> On 06/21/2010 09:06 AM, Ben Hutchings wrote:
> > Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> > ---
> > drivers/net/sfc/ethtool.c | 16 +++
> > drivers/net/sfc/io.h | 7 +
> > drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
> > drivers/net/sfc/nic.h | 3 +
> > 4 files changed, 292 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
> > index 22026bf..81b7f39 100644
> > --- a/drivers/net/sfc/ethtool.c
> > +++ b/drivers/net/sfc/ethtool.c
> > @@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
> > strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
> > }
> >
> > +static int efx_ethtool_get_regs_len(struct net_device *net_dev)
> > +{
> > + return efx_nic_get_regs_len(netdev_priv(net_dev));
> > +}
> > +
> > +static void efx_ethtool_get_regs(struct net_device *net_dev,
> > + struct ethtool_regs *regs, void *buf)
> > +{
> > + struct efx_nic *efx = netdev_priv(net_dev);
> > +
> > + regs->version = efx->type->revision;
> > + efx_nic_get_regs(efx, buf);
>
> regs->version is really the version of hardware register dump exported
> to userspace. You might want to hardcode this in the driver, to be
> changed when efx_nic_regs[] array changes, rather than tying
> regs->version directly to the SFC hardware architecture revision.
>
> However, if that limitation is OK with you, ie. ethtool register dump
> code will change when h/w arch rev changes, then
This is exactly what we want, as the set of defined registers (and
fields within each register) will change in each architecture revision.
(It may not change in each chip revision, but efx_nic_type::revision is
supposed to reflect the architecture revision.)
Although this code doesn't include an explicit format version, we can
consider the current format to be version 0 and increment it if we ever
want to make changes to the format for existing NIC revisions.
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
>
> This is a ABI-related choice, so it deserves a bit of consideration.
I *think* I know what I'm doing here. :-)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6] sfc: Implement ethtool register dump operation
From: Jeff Garzik @ 2010-06-21 17:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1277125613.2100.9.camel@achroite.uk.solarflarecom.com>
On 06/21/2010 09:06 AM, Ben Hutchings wrote:
> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
> ---
> drivers/net/sfc/ethtool.c | 16 +++
> drivers/net/sfc/io.h | 7 +
> drivers/net/sfc/nic.c | 266 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/net/sfc/nic.h | 3 +
> 4 files changed, 292 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
> index 22026bf..81b7f39 100644
> --- a/drivers/net/sfc/ethtool.c
> +++ b/drivers/net/sfc/ethtool.c
> @@ -242,6 +242,20 @@ static void efx_ethtool_get_drvinfo(struct net_device *net_dev,
> strlcpy(info->bus_info, pci_name(efx->pci_dev), sizeof(info->bus_info));
> }
>
> +static int efx_ethtool_get_regs_len(struct net_device *net_dev)
> +{
> + return efx_nic_get_regs_len(netdev_priv(net_dev));
> +}
> +
> +static void efx_ethtool_get_regs(struct net_device *net_dev,
> + struct ethtool_regs *regs, void *buf)
> +{
> + struct efx_nic *efx = netdev_priv(net_dev);
> +
> + regs->version = efx->type->revision;
> + efx_nic_get_regs(efx, buf);
regs->version is really the version of hardware register dump exported
to userspace. You might want to hardcode this in the driver, to be
changed when efx_nic_regs[] array changes, rather than tying
regs->version directly to the SFC hardware architecture revision.
However, if that limitation is OK with you, ie. ethtool register dump
code will change when h/w arch rev changes, then
Acked-by: Jeff Garzik <jgarzik@redhat.com>
This is a ABI-related choice, so it deserves a bit of consideration.
Regards,
Jeff
^ permalink raw reply
* RE: [PATCH] kernel 2.6.35: ixgbe: skip non IPv4 packets in ATR filter
From: Skidmore, Donald C @ 2010-06-21 17:35 UTC (permalink / raw)
To: Guillaume Gaudonville, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, Waskiewicz Jr, Peter P,
Chilakala, Mallikarjuna
In-Reply-To: <4C1F637E.8010005@6wind.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Guillaume Gaudonville
>Sent: Monday, June 21, 2010 6:05 AM
>To: netdev@vger.kernel.org
>Cc: Kirsher, Jeffrey T; Waskiewicz Jr, Peter P; Chilakala, Mallikarjuna
>Subject: [PATCH] kernel 2.6.35: ixgbe: skip non IPv4 packets in ATR filter
>
>Hello,
>
>In driver ixgbe, ixgbe_atr may cause crashes for non-ipv4 packets. Just
>add a test to check skb->protocol:
>
> From fcb81aa89b6819f95349a4ed8c30f0629430aa1d Mon Sep 17 00:00:00 2001
>From: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>Date: Thu, 17 Jun 2010 16:02:14 +0200
>Subject: [PATCH] ixgbe: skip non IPv4 packets in ATR filter
>
>It may crash on short packets due to ip_hdr() access.
>
>Signed-off-by: Guillaume Gaudonville <guillaume.gaudonville@6wind.com>
>---
> drivers/net/ixgbe/ixgbe_main.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/net/ixgbe/ixgbe_main.c
>b/drivers/net/ixgbe/ixgbe_main.c
>index b2af2f6..3581dbe 100644
>--- a/drivers/net/ixgbe/ixgbe_main.c
>+++ b/drivers/net/ixgbe/ixgbe_main.c
>@@ -6019,7 +6019,6 @@ static void ixgbe_tx_queue(struct ixgbe_adapter
>*adapter,
> static void ixgbe_atr(struct ixgbe_adapter *adapter, struct sk_buff *skb,
> int queue, u32 tx_flags)
> {
>- /* Right now, we support IPv4 only */
> struct ixgbe_atr_input atr_input;
> struct tcphdr *th;
> struct iphdr *iph = ip_hdr(skb);
>@@ -6028,6 +6027,10 @@ static void ixgbe_atr(struct ixgbe_adapter
>*adapter, struct sk_buff *skb,
> u32 src_ipv4_addr, dst_ipv4_addr;
> u8 l4type = 0;
>
>+ /* Right now, we support IPv4 only */
>+ if (skb->protocol != htons(ETH_P_IP))
>+ return;
>+
> /* check if we're UDP or TCP */
> if (iph->protocol == IPPROTO_TCP) {
> th = tcp_hdr(skb);
>--
>1.5.6.5
>
>--
>Guillaume Gaudonville
>guillaume.gaudonville@6wind.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
This patch has been pulled into our internal tree for testing.
Thanks,
-Don
<donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the net tree
From: Paul E. McKenney @ 2010-06-21 17:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Jiri Pirko, David Miller, netdev
In-Reply-To: <20100621161609.935d0085.sfr@canb.auug.org.au>
On Mon, Jun 21, 2010 at 04:16:09PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> net/bridge/br_fdb.c net/bridge/netfilter/ebt_redirect.c
> net/bridge/netfilter/ebt_ulog.c net/bridge/netfilter/ebtables.c
> net/netfilter/nfnetlink_log.c between commit
> f350a0a87374418635689471606454abc7beaa3a ("bridge: use rx_handler_data
> pointer to store net_bridge_port pointer") from the net tree and commit
> 81bdf5bd7349bd4523538cbd7878f334bc2bfe14 ("net: Make accesses to
> ->br_port safe for sparse RCU") from the tip tree.
>
> The net tree commit looks like a superset of the tip tree commit, so I
> effectively reverted the tip tree commit.
I defer to Jiri on this one, and will withdraw my patch.
Thanx, Paul
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Stephen Hemminger @ 2010-06-21 17:25 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Andreas Klauer, netdev, Octavian Purdila
In-Reply-To: <20100621162518.GA5972@nuttenaction>
The OOPS is here
static void ndisc_send_na(struct net_device *dev, struct neighbour *neigh,
const struct in6_addr *daddr,
const struct in6_addr *solicited_addr,
int router, int solicited, int override, int inc_opt)
{
...
/* for anycast or proxy, solicited_addr != src_addr */
ifp = ipv6_get_ifaddr(dev_net(dev), solicited_addr, dev, 1);
if (ifp) {
src_addr = solicited_addr;
if (ifp->flags & IFA_F_OPTIMISTIC)
override = 0;
in6_ifa_put(ifp);
} else {
if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
inet6_sk(dev_net(dev)->ipv6.ndisc_sk)->srcprefs,
&tmpaddr))
return;
src_addr = &tmpaddr;
}
icmp6h.icmp6_router = router;
icmp6h.icmp6_solicited = solicited;
icmp6h.icmp6_override = override;
inc_opt |= ifp->idev->cnf.force_tllao;
And it caused by this recent commit.
Author: Octavian Purdila <opurdila@ixiacom.com> 2009-10-02 04:39:15
Committer: David S. Miller <davem@davemloft.net> 2009-10-07 01:10:45
Parent: d1f8297a96b0d70f17704296a6666468f2087ce6 (Revert "sit: stateless autoconf for isatap")
Child: d7fc02c7bae7b1cf69269992cf880a43a350cdaa (Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6)
Branches: addrconf, master, remotes/origin/master
Follows: v2.6.32-rc3
Precedes: v2.6.33-rc1
make TLLAO option for NA packets configurable
On Friday 02 October 2009 20:53:51 you wrote:
> This is good although I would have shortened the name.
Ah, I knew I forgot something :) Here is v4.
tavi
>From 24d96d825b9fa832b22878cc6c990d5711968734 Mon Sep 17 00:00:00 2001
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Fri, 2 Oct 2009 00:51:15 +0300
Subject: [PATCH] ipv6: new sysctl for sending TLLAO with unicast NAs
Neighbor advertisements responding to unicast neighbor solicitations
did not include the target link-layer address option. This patch adds
a new sysctl option (disabled by default) which controls whether this
option should be sent even with unicast NAs.
The need for this arose because certain routers expect the TLLAO in
some situations even as a response to unicast NS packets.
Moreover, RFC 2461 recommends sending this to avoid a race condition
(section 4.4, Target link-layer address)
Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is not handling the case of ifp == NULL.
Maybe the following (move the assignment into the if block).
--- a/net/ipv6/ndisc.c 2010-06-21 10:22:20.825637690 -0700
+++ b/net/ipv6/ndisc.c 2010-06-21 10:24:31.573011996 -0700
@@ -586,6 +586,7 @@ static void ndisc_send_na(struct net_dev
src_addr = solicited_addr;
if (ifp->flags & IFA_F_OPTIMISTIC)
override = 0;
+ inc_opt |= ifp->idev->cnf.force_tllao;
in6_ifa_put(ifp);
} else {
if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
@@ -599,7 +600,6 @@ static void ndisc_send_na(struct net_dev
icmp6h.icmp6_solicited = solicited;
icmp6h.icmp6_override = override;
- inc_opt |= ifp->idev->cnf.force_tllao;
__ndisc_send(dev, neigh, daddr, src_addr,
&icmp6h, solicited_addr,
inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-21 16:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20100621091946.63f26b21@nehalam>
On Mon, Jun 21, 2010 at 09:19:46AM -0700, Stephen Hemminger wrote:
> Unfortunately, Greg seems to be slow in getting 2.6.34.1 out.
> These patches are related:
>
> http://marc.info/?l=linux-netdev&m=127472600330413
> http://marc.info/?l=linux-netdev&m=127472599530407
Thank you for your reply. I will test if these patches help ASAP.
In the meantime, I also reproduced the issue with 2.6.33.5.
Regards
Andreas Klauer
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Hagen Paul Pfeifer @ 2010-06-21 16:25 UTC (permalink / raw)
To: Andreas Klauer; +Cc: netdev
In-Reply-To: <20100621153018.GA2433@EIS>
* Andreas Klauer | 2010-06-21 17:30:18 [+0200]:
>Hi,
>
>no one replied so far - am I reporting this to the wrong place?
>Please advise.
It is the right place, some guys are in holiday but probably you can git
bisect the problem?
HGN
^ 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