* Re: e1000e hardware CRC stripping breaks bridging
From: Johan Andersson @ 2008-02-12 13:57 UTC (permalink / raw)
To: Daniel Drake; +Cc: Auke Kok, netdev
In-Reply-To: <47B19EDE.5020802@gentoo.org>
Here is the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=9940
/Johan
On Tue, 2008-02-12 at 13:27 +0000, Daniel Drake wrote:
> Hi,
>
> Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> stripping enabled by e1000e breaks bridging because sometimes the CRC is
> not stripped:
> https://bugs.gentoo.org/show_bug.cgi?id=209235
>
> Apparently "upstream" are aware but I couldn't find any mails or bug
> reports on this topic.
>
> What's the current status of this issue? Perhaps we should disable
> hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
>
> Thanks,
> Daniel
> --
> 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: [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure
From: Jeff Garzik @ 2008-02-12 15:58 UTC (permalink / raw)
To: Matti Linnanvuori; +Cc: netdev, David Miller
In-Reply-To: <190693.34289.qm@web52005.mail.re2.yahoo.com>
Matti Linnanvuori wrote:
> From: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
>
> There is a race in Linux kernel file net/core/dev.c, function dev_close.
> The function calls function dev_deactivate, which calls function
> dev_watchdog_down that deletes the watchdog timer. However, after that, a
> driver can call netif_carrier_ok, which calls function
> __netdev_watchdog_up that can add the watchdog timer again. Function
> unregister_netdevice calls function dev_shutdown that traps the bug
> !timer_pending(&dev->watchdog_timer). Moving dev_deactivate after
> netif_running() has been cleared prevents function netif_carrier_on
> from calling __netdev_watchdog_up and adding the watchdog timer again.
>
> Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
>
> ---
>
> --- linux-2.6.25/net/core/dev.c 2008-02-12 12:37:51.206833000 +0200
> +++ b/net/core/dev.c 2008-02-12 12:38:48.727611400 +0200
> @@ -1071,8 +1071,6 @@ int dev_close(struct net_device *dev)
> */
> call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
>
> - dev_deactivate(dev);
> -
> clear_bit(__LINK_STATE_START, &dev->state);
>
> /* Synchronize to scheduled poll. We cannot touch poll list,
> @@ -1083,6 +1081,7 @@ int dev_close(struct net_device *dev)
> */
> smp_mb__after_clear_bit(); /* Commit netif_running(). */
>
> + dev_deactivate(dev);
> /*
> * Call the device specific close. This cannot fail.
> * Only if device is UP
This is more for davem (he does net/* stuff)
Jeff
^ permalink raw reply
* Re: [git patches] net driver updates
From: Jeff Garzik @ 2008-02-12 16:01 UTC (permalink / raw)
To: Ben Dooks; +Cc: David Miller, netdev, Laurent Pinchart
In-Reply-To: <20080212123828.GB26519@fluff.org.uk>
Ben Dooks wrote:
> These two where meant to be from Laurent Pinchart, they do have
> the correct signed-off lines in for him and start with "Patch from:". Is
> there any chance of fixing the authour attribution now?
The first line of the changeset mentions it. Other than that, nope.
Jeff
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Paul E. McKenney @ 2008-02-12 16:07 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: David Miller, shemminger, netdev, linux-kernel
In-Reply-To: <20080212085714.GB2582@ff.dom.local>
On Tue, Feb 12, 2008 at 08:57:14AM +0000, Jarek Poplawski wrote:
> On 12-02-2008 02:16, David Miller wrote:
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, 11 Feb 2008 16:59:54 -0800
> >
> > linux-kernel added to CC:, any change to generic kernel infrastructure
> > should be posted there
> >
> >> Eliminate warnings when rcu_assign_pointer is used with unsigned long.
> >> It is reasonable to use RCU with non-pointer values so allow it for general
> >> use. Add a comment to explain the if test.
> >>
> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >> ---
> >> include/linux/rcupdate.h | 13 +++++++------
> >> 1 files changed, 7 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >> index 37a642c..c44ac87 100644
> >> --- a/include/linux/rcupdate.h
> >> +++ b/include/linux/rcupdate.h
> >> @@ -172,14 +172,15 @@ struct rcu_head {
> >> * structure after the pointer assignment. More importantly, this
> >> * call documents which pointers will be dereferenced by RCU read-side
> >> * code.
> >> + *
> >> + * If value is the NULL (constant 0), then no barrier is needed.
> >> */
> >>
> >> -#define rcu_assign_pointer(p, v) \
> >> - ({ \
> >> - if (!__builtin_constant_p(v) || \
> >> - ((v) != NULL)) \
> >> - smp_wmb(); \
> >> - (p) = (v); \
> >> +#define rcu_assign_pointer(p, v) \
> >> + ({ \
> >> + if (!(__builtin_constant_p(v) && v)) \
>
> ...But, "If value is the NULL (constant 0)" we have:
>
> if (!(1 && NULL != 0)) ==> if (!(0)) and the barrier is used?!
"All programmers are blind, especially me."
You are right, Jarek. I ran this through gcc, and the following
comes close:
#define rcu_assign_pointer(p, v) \
({ \
if (!__builtin_constant_p(v) || (v)) \
smp_wmb(); \
(p) = (v); \
})
But I am concerned about the following case:
rcu_assign_pointer(global_index, 0);
. . .
x = global_array[rcu_dereference(global_index)];
Since arrays have a zero-th element, we would really want a memory
barrier in this case.
So how about leaving the index-unfriendly version of rcu_assign_pointer()
and adding an rcu_assign_index() as follows?
Thanx, Paul
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
rcupdate.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
--- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.000000000 -0800
+++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-12 08:04:59.000000000 -0800
@@ -278,6 +278,24 @@ extern struct lockdep_map rcu_lock_map;
})
/**
+ * rcu_assign_index - assign (publicize) a index of a newly
+ * initialized array elementg that will be dereferenced by RCU
+ * read-side critical sections. Returns the value assigned.
+ *
+ * Inserts memory barriers on architectures that require them
+ * (pretty much all of them other than x86), and also prevents
+ * the compiler from reordering the code that initializes the
+ * structure after the index assignment. More importantly, this
+ * call documents which indexes will be dereferenced by RCU read-side
+ * code.
+ */
+
+#define rcu_assign_index(p, v) ({ \
+ smp_wmb(); \
+ (p) = (v); \
+ })
+
+/**
* synchronize_sched - block until all CPUs have exited any non-preemptive
* kernel code sequences.
*
^ permalink raw reply
* [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.
From: Pavel Emelyanov @ 2008-02-12 16:27 UTC (permalink / raw)
To: David Miller; +Cc: Paul Moore, Linux Netdev List
Currently, if the call to netlbl_domhsh_search succeeds the
return result will still be NULL.
Fix that, by returning the found entry (if any).
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/netlabel/netlabel_domainhash.c b/net/netlabel/netlabel_domainhash.c
index 9a8ea01..fd46231 100644
--- a/net/netlabel/netlabel_domainhash.c
+++ b/net/netlabel/netlabel_domainhash.c
@@ -150,11 +150,11 @@ static struct netlbl_dom_map *netlbl_domhsh_search_def(const char *domain)
entry = netlbl_domhsh_search(domain);
if (entry == NULL) {
entry = rcu_dereference(netlbl_domhsh_def);
- if (entry != NULL && entry->valid)
- return entry;
+ if (entry != NULL && !entry->valid)
+ entry = NULL;
}
- return NULL;
+ return entry;
}
/*
^ permalink raw reply related
* Re: [PATCH][NETLABEL]: Fix lookup logic of netlbl_domhsh_search_def.
From: Paul Moore @ 2008-02-12 16:34 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <47B1C8E4.6010908@openvz.org>
On Tuesday 12 February 2008 11:27:16 am Pavel Emelyanov wrote:
> Currently, if the call to netlbl_domhsh_search succeeds the
> return result will still be NULL.
>
> Fix that, by returning the found entry (if any).
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Good catch, thanks.
Acked-by: Paul Moore <paul.moore@hp.com>
> ---
>
> diff --git a/net/netlabel/netlabel_domainhash.c
> b/net/netlabel/netlabel_domainhash.c index 9a8ea01..fd46231 100644
> --- a/net/netlabel/netlabel_domainhash.c
> +++ b/net/netlabel/netlabel_domainhash.c
> @@ -150,11 +150,11 @@ static struct netlbl_dom_map
> *netlbl_domhsh_search_def(const char *domain) entry =
> netlbl_domhsh_search(domain);
> if (entry == NULL) {
> entry = rcu_dereference(netlbl_domhsh_def);
> - if (entry != NULL && entry->valid)
> - return entry;
> + if (entry != NULL && !entry->valid)
> + entry = NULL;
> }
>
> - return NULL;
> + return entry;
> }
>
> /*
--
paul moore
linux security @ hp
^ permalink raw reply
* RE: r8169 auto-negotiation problem
From: fgnijuhhu guduggurehug @ 2008-02-12 16:44 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20080203184525.GA12607@electric-eye.fr.zoreil.com>
> fgnijuhhu guduggurehug :
> [...]
>> I already posted my problem and what I did to solve it on
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
>
> Have you tried anything more recent than a 2.6.18 based kernel ?
No, but if changes were made to the iniatialization of the chipset in the current driver (mine was 2.2LK), this might do the trick. The problem is that the error is rather erratic and unreproducible.
Anyway, how to best upgrade the kernel in debian (without problems, of course)? The problem right now is that every apt-get upgrade reverts the r8169 driver to the old one...
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* [PATCH][GENETLINK]: Relax dances with genl_lock.
From: Pavel Emelyanov @ 2008-02-12 17:16 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List
The genl_unregister_family() calls the genl_unregister_mc_groups(),
which takes and releases the genl_lock and then locks and releases
this lock itself.
Relax this behavior, all the more so the genl_unregister_mc_groups()
is called from genl_unregister_family() only.
I'm not sure, whether this is 2.6.25 material, but the patch looks
pretty simple. Should I hold it till 2.6.26?
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 150579a..d16929c 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -230,10 +230,8 @@ static void genl_unregister_mc_groups(struct genl_family *family)
{
struct genl_multicast_group *grp, *tmp;
- genl_lock();
list_for_each_entry_safe(grp, tmp, &family->mcast_groups, list)
__genl_unregister_mc_group(family, grp);
- genl_unlock();
}
/**
@@ -396,10 +394,10 @@ int genl_unregister_family(struct genl_family *family)
{
struct genl_family *rc;
- genl_unregister_mc_groups(family);
-
genl_lock();
+ genl_unregister_mc_groups(family);
+
list_for_each_entry(rc, genl_family_chain(family->id), family_list) {
if (family->id != rc->id || strcmp(rc->name, family->name))
continue;
^ permalink raw reply related
* Re: e1000e hardware CRC stripping breaks bridging
From: Andy Gospodarek @ 2008-02-12 17:23 UTC (permalink / raw)
To: Johan Andersson; +Cc: Daniel Drake, Auke Kok, netdev
In-Reply-To: <1202824670.26114.20.camel@gentoo-johan.transmode.se>
On Tue, Feb 12, 2008 at 02:57:50PM +0100, Johan Andersson wrote:
> Here is the bug report:
> http://bugzilla.kernel.org/show_bug.cgi?id=9940
>
> /Johan
>
> On Tue, 2008-02-12 at 13:27 +0000, Daniel Drake wrote:
> > Hi,
> >
> > Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> > stripping enabled by e1000e breaks bridging because sometimes the CRC is
> > not stripped:
> > https://bugs.gentoo.org/show_bug.cgi?id=209235
> >
> > Apparently "upstream" are aware but I couldn't find any mails or bug
> > reports on this topic.
> >
> > What's the current status of this issue? Perhaps we should disable
> > hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
> >
> > Thanks,
> > Daniel
This patch, just needs to get reverted:
commit 140a74802894e9db57e5cd77ccff77e590ece5f3
Author: Auke Kok <auke-jan.h.kok@intel.com>
Date: Thu Oct 25 13:57:58 2007 -0700
e1000e: Re-enable SECRC - crc stripping
^ permalink raw reply
* Re: e1000e hardware CRC stripping breaks bridging
From: Kok, Auke @ 2008-02-12 17:25 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev, johan.andersson, dsd, jesse.brandeburg
In-Reply-To: <47B19EDE.5020802@gentoo.org>
Daniel Drake wrote:
> Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> stripping enabled by e1000e breaks bridging because sometimes the CRC is
> not stripped:
> https://bugs.gentoo.org/show_bug.cgi?id=209235
>
> Apparently "upstream" are aware but I couldn't find any mails or bug
> reports on this topic.
>
> What's the current status of this issue? Perhaps we should disable
> hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
Jesse figured it out. I just send you a patch to test, can you guys give that a
try and see if it fixes the situation? Johan?
thanks,
Auke
^ permalink raw reply
* Re: Open bugs
From: James Bottomley @ 2008-02-12 17:57 UTC (permalink / raw)
To: Natalie Protasevich
Cc: alsa-devel, bugme-daemon, linux-scsi, netdev, linux-kernel,
linux-ide, akpm
In-Reply-To: <32209efe0802120018r17c38835ud931085e44aafefb@mail.gmail.com>
Added linux-scsi for the SCSI ones
On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
> Hello,
>
> The bugs listed are over a month old, and haven't been addressed yet.
> It would be appreciated if corresponding maintainers identify whether
> the bugs have been fixed, or need to be worked on, and take
> appropriate action.
>
> In most cases, reporters are standing by and ready to provide
> information and necessary testing.
> Thanks!
>
> SCSI======================================================
>
> Problems on booting
> http://bugzilla.kernel.org/show_bug.cgi?id=9621
> Date: 12/22/2007
> Regression
> Summary: The boot stops / hangs on hardware detection of SCSI. I have
> an InitioINI-9X00U/UW
> When I have an usb key sticked in /dev/sba, and run lilo then, then it
> dont boot but give L99 99 99 99 ... error
I think this was fixed by commit
e2d435ea4084022ab88efa74214accb45b1f9e92
Apparently bugzilla email is on the fritz again because this bug report
didn't come across linux-scsi.
> Resetting RAID attached to a FC Switch causes kernel panic and crash
> http://bugzilla.kernel.org/show_bug.cgi?id=9598
> 12/18/2007
> Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
> 8GB Ram, Qlogic FC adapter.
> Summary: Resetting the RAID box causes the X4200 to crash.
This one looks like the usual problem of remove re-add with the SCSI
device model.
> 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
> http://bugzilla.kernel.org/show_bug.cgi?id=8908
> 08/19/2007
> Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
> RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
> RAID Controller.
Since this one never apparently worked it's not a regression but an
enhancement request, isn't it?
However, adding this PCI ID to the driver should be fairly
straightforward. Does anyone know what the actual PCI IDs are?
James
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-12 18:04 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
In-Reply-To: <200802111724.12416.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
>
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.net/lists/netdev/msg54484.html
This driver is broken pretty horribly. It won't even compile for a
plain ppc64 kernel:
http://sr71.net/~dave/linux/ehea-is-broken.config
I know it's used for very specific hardware, but this is the symptom of
it not using the proper abstracted interfaces to the VM.
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
CC drivers/net/mii.o
make[4]: *** [drivers/net/ehea/ehea_main.o] Error 1
make[4]: *** Waiting for unfinished jobs....
CC drivers/net/ixgb/ixgb_param.o
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:32:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: 'NR_MEM_SECTIONS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: (Each undeclared identifier is reported only once
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: for each function it appears in.)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:575: error: implicit declaration of function 'valid_section_nr'
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_map_vaddr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:606: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_reg_kernel_mr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:655: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
-- Dave
^ permalink raw reply
* Re: Open bugs
From: Natalie Protasevich @ 2008-02-12 18:55 UTC (permalink / raw)
To: James Bottomley
Cc: linux-kernel, akpm, netdev, alsa-devel, linux-ide, bugme-daemon,
linux-scsi
In-Reply-To: <1202839022.3137.63.camel@localhost.localdomain>
On Feb 12, 2008 9:57 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> Added linux-scsi for the SCSI ones
>
> On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
> > Hello,
> >
> > The bugs listed are over a month old, and haven't been addressed yet.
> > It would be appreciated if corresponding maintainers identify whether
> > the bugs have been fixed, or need to be worked on, and take
> > appropriate action.
> >
> > In most cases, reporters are standing by and ready to provide
> > information and necessary testing.
> > Thanks!
> >
> > SCSI======================================================
> >
> > Problems on booting
> > http://bugzilla.kernel.org/show_bug.cgi?id=9621
> > Date: 12/22/2007
> > Regression
> > Summary: The boot stops / hangs on hardware detection of SCSI. I have
> > an InitioINI-9X00U/UW
> > When I have an usb key sticked in /dev/sba, and run lilo then, then it
> > dont boot but give L99 99 99 99 ... error
>
> I think this was fixed by commit
> e2d435ea4084022ab88efa74214accb45b1f9e92
>
> Apparently bugzilla email is on the fritz again because this bug report
> didn't come across linux-scsi.
I just fixed that, thanks. It was incorrect "assign-to" party.
>
> > Resetting RAID attached to a FC Switch causes kernel panic and crash
> > http://bugzilla.kernel.org/show_bug.cgi?id=9598
> > 12/18/2007
> > Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
> > 8GB Ram, Qlogic FC adapter.
> > Summary: Resetting the RAID box causes the X4200 to crash.
>
> This one looks like the usual problem of remove re-add with the SCSI
> device model.
>
> > 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
> > http://bugzilla.kernel.org/show_bug.cgi?id=8908
> > 08/19/2007
> > Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
> > RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
> > RAID Controller.
>
> Since this one never apparently worked it's not a regression but an
> enhancement request, isn't it?
No this is not a regression. The bug list that I post is just any bugs
(mostly unattended or stalled). Sometimes those are regressions off of
the Raphael's list, when they don't get resolved for a while, or just
random regressions that haven't showed up on the "hot list" by
Raphael.
>
> However, adding this PCI ID to the driver should be fairly
> straightforward. Does anyone know what the actual PCI IDs are?
I just asked the reporter to provide this information, thanks.
>
> James
>
>
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Jarek Poplawski @ 2008-02-12 19:32 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: David Miller, shemminger, netdev, linux-kernel
In-Reply-To: <20080212160729.GA9157@linux.vnet.ibm.com>
On Tue, Feb 12, 2008 at 08:07:29AM -0800, Paul E. McKenney wrote:
...
> "All programmers are blind, especially me."
Hmm... I got it my way: you - superheroes - sometimes seem to be just
like us - common people... (Probably early in the morning, before
dressing your funny costumes?)
> You are right, Jarek. I ran this through gcc, and the following
> comes close:
>
> #define rcu_assign_pointer(p, v) \
> ({ \
> if (!__builtin_constant_p(v) || (v)) \
> smp_wmb(); \
> (p) = (v); \
> })
>
> But I am concerned about the following case:
>
> rcu_assign_pointer(global_index, 0);
>
> . . .
>
> x = global_array[rcu_dereference(global_index)];
>
> Since arrays have a zero-th element, we would really want a memory
> barrier in this case.
It seems the above version of this macro uses the barrier for 0, but
if I miss something, or for these other: documenting reasons, then of
course you are right.
>
> So how about leaving the index-unfriendly version of rcu_assign_pointer()
> and adding an rcu_assign_index() as follows?
>
> Thanx, Paul
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>
> rcupdate.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
> --- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.000000000 -0800
> +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-12 08:04:59.000000000 -0800
> @@ -278,6 +278,24 @@ extern struct lockdep_map rcu_lock_map;
> })
>
> /**
> + * rcu_assign_index - assign (publicize) a index of a newly
> + * initialized array elementg that will be dereferenced by RCU
---------------------------^
+ * initialized array element that will be dereferenced by RCU
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH] [RFC] Smack: unlabeled outgoing ambient packets - v2
From: Paul Moore @ 2008-02-12 19:42 UTC (permalink / raw)
To: casey; +Cc: netdev, linux-kernel
In-Reply-To: <47B0E1A1.7090902@schaufler-ca.com>
On Monday 11 February 2008 7:00:33 pm Casey Schaufler wrote:
> This patch differs significantly from the previous version.
> I think that I am using the netlbl interfaces more appropriately,
> Paul, please let me know if there's a better approach.
Nope, this approach is what I was talking about. There are some minor
issues discussed below but they should be easy/quick to fix.
> It's inconvenient that netlbl_sock_setattr frees the domain passed.
> I see that it makes sense for SELinux with the way SELinux treats
> secctx's, but Smack is more careful about memory usage and I have
> to do what I consider a gratuitous kalloc because of this behavior.
> Would you be open to a patch to change this if it included the
> SELinux changes?
I've looked at this before from a SELinux point of view to see if I
could get rid of this extra memory allocation/copy and there just isn't
a clean way to do it ("clean" being very subjective). The problem is
you either have to hold the policy lock while you make the NetLabel
call (not a good idea), move the selinux_netlbl_sock_setsid()
functionality back into security/selinux/ss/services.c (not desired by
the SELinux folks who like to keep the selinux/ss/ directory minimal),
or do the allocatin in security_netlbl_sid_to_secattr() and free it in
selinux_netlbl_sock_setsid(). Of those options, only the last is
really possible and it's so prone to memory leakage that I'm hesitant
to say it's better than what we currently have. Right now you do a
call to netlbl_secattr_init() to start, do what you want with the
secattr, and then you call netlbl_secattr_destroy() which will clean up
_everything_ so nothing is leaked. It works out really well because
all of the _secattr_init() calls are matched by _secattr_destroy()
calls within the same function; very easy to quickly scan and ensure
there are no problems (the memory leak for a few weeks ago was quickly
caught by looking at the code). I'm in no hurry to loose this handy
little property of the secattr, although I do agree that it isn't
optimal for SMACK at present. On the plus side this only happens once
per-socket and not per-packet so I don't expect the malloc/copy to be
fatal at this point.
You've got my mind revisiting this idea so give me a while and let me
see if I can think of something that should be palatable to everyone
involved. In the meantime, I think you should fixup the few little
nits in this patch and get it merged as it is a nice improvement and
something that I believe most SMACK users will want.
> security/smack/smack_lsm.c | 20 ++++++------
> security/smack/smackfs.c | 54
> +++++++++++++++++++++++++---------- 2 files changed, 49
> insertions(+), 25 deletions(-)
>
> diff -uprN -X linux-2.6.25-g0210-base//Documentation/dontdiff
> linux-2.6.25-g0210-base/security/smack/smackfs.c
> linux-2.6.25-g0210/security/smack/smackfs.c ---
> linux-2.6.25-g0210-base/security/smack/smackfs.c 2008-02-10
> 19:30:47.000000000 -0800 +++
> linux-2.6.25-g0210/security/smack/smackfs.c 2008-02-11
> 07:14:54.000000000 -0800 @@ -45,6 +45,7 @@ enum smk_inos {
> */
> static DEFINE_MUTEX(smack_list_lock);
> static DEFINE_MUTEX(smack_cipso_lock);
> +static DEFINE_MUTEX(smack_ambient_lock);
>
> /*
> * This is the "ambient" label for network traffic.
> @@ -363,6 +364,27 @@ void smk_cipso_doi(void)
> __func__, __LINE__, rc);
> }
>
> +/**
> + * smk_unlbl_ambient - initialize the unlabeled domain
> + */
> +void smk_unlbl_ambient(char *oldambient)
> +{
> + int rc;
> + struct netlbl_audit audit_info;
You should try and populate the 'audit_info' struct with actual info so
the generated audit record is more useful for people who care about
those things. It's only two fields, 'secid' and 'loginuid', which are
pretty self-explanatory.
> + if (oldambient != NULL) {
> + rc = netlbl_cfg_map_del(oldambient, &audit_info);
> + if (rc != 0)
> + printk(KERN_WARNING "%s:%d remove rc = %d\n",
> + __func__, __LINE__, rc);
> + }
> +
> + rc = netlbl_cfg_unlbl_add_map(smack_net_ambient, &audit_info);
> + if (rc != 0)
> + printk(KERN_WARNING "%s:%d add rc = %d\n",
> + __func__, __LINE__, rc);
> +}
> +
> /*
> * Seq_file read operations for /smack/cipso
> */
> @@ -709,7 +731,6 @@ static ssize_t smk_read_ambient(struct f
> size_t cn, loff_t *ppos)
> {
> ssize_t rc;
> - char out[SMK_LABELLEN];
> int asize;
>
> if (*ppos != 0)
> @@ -717,23 +738,18 @@ static ssize_t smk_read_ambient(struct f
> /*
> * Being careful to avoid a problem in the case where
> * smack_net_ambient gets changed in midstream.
> - * Since smack_net_ambient is always set with a value
> - * from the label list, including initially, and those
> - * never get freed, the worst case is that the pointer
> - * gets changed just after this strncpy, in which case
> - * the value passed up is incorrect. Locking around
> - * smack_net_ambient wouldn't be any better than this
> - * copy scheme as by the time the caller got to look
> - * at the ambient value it would have cleared the lock
> - * and been changed.
> */
> - strncpy(out, smack_net_ambient, SMK_LABELLEN);
> - asize = strlen(out) + 1;
> + mutex_lock(&smack_ambient_lock);
>
> - if (cn < asize)
> - return -EINVAL;
> + asize = strlen(smack_net_ambient) + 1;
>
> - rc = simple_read_from_buffer(buf, cn, ppos, out, asize);
> + if (cn >= asize)
> + rc = simple_read_from_buffer(buf, cn, ppos,
> + smack_net_ambient, asize);
> + else
> + rc = -EINVAL;
> +
> + mutex_unlock(&smack_ambient_lock);
>
> return rc;
> }
> @@ -751,6 +767,7 @@ static ssize_t smk_write_ambient(struct
> size_t count, loff_t *ppos)
> {
> char in[SMK_LABELLEN];
> + char *oldambient;
> char *smack;
>
> if (!capable(CAP_MAC_ADMIN))
> @@ -766,7 +783,13 @@ static ssize_t smk_write_ambient(struct
> if (smack == NULL)
> return -EINVAL;
>
> + mutex_lock(&smack_ambient_lock);
> +
> + oldambient = smack_net_ambient;
> smack_net_ambient = smack;
> + smk_unlbl_ambient(oldambient);
> +
> + mutex_unlock(&smack_ambient_lock);
There is still the potential for a race here between when you change
the 'smack_net_ambient' value and when you actually change the NetLabel
configuration as you still allow new sockets to be created/labeled
regardless of the 'smack_ambient_lock'. That said, considering that
this is a privileged operation and one that I don't expect to be very
frequent it's probably not a big deal, I just wanted to make sure you
were aware of that.
> return count;
> }
> @@ -974,6 +997,7 @@ static int __init init_smk_fs(void)
>
> sema_init(&smack_write_sem, 1);
> smk_cipso_doi();
> + smk_unlbl_ambient(NULL);
>
> return err;
> }
> diff -uprN -X linux-2.6.25-g0210-base//Documentation/dontdiff
> linux-2.6.25-g0210-base/security/smack/smack_lsm.c
> linux-2.6.25-g0210/security/smack/smack_lsm.c ---
> linux-2.6.25-g0210-base/security/smack/smack_lsm.c 2008-02-10
> 19:30:47.000000000 -0800 +++
> linux-2.6.25-g0210/security/smack/smack_lsm.c 2008-02-10
> 20:10:47.000000000 -0800 @@ -1251,7 +1251,7 @@ static void
> smack_to_secattr(char *smack
>
> switch (smack_net_nltype) {
> case NETLBL_NLTYPE_CIPSOV4:
> - nlsp->domain = NULL;
> + nlsp->domain = kstrdup(smack, GFP_ATOMIC);
> nlsp->flags = NETLBL_SECATTR_DOMAIN;
> nlsp->flags |= NETLBL_SECATTR_MLS_LVL;
Should have noticed this sooner, how about replacing the above two lines
with the following?
nlsp->flags = NETLBL_SECATTR_DOMAIN | NETLBL_SECATTR_MLS_LVL;
> @@ -1276,21 +1276,21 @@ static void smack_to_secattr(char *smack
> * Convert the outbound smack value (smk_out) to a
> * secattr and attach it to the socket.
> *
> - * Returns 0 on success or an error code
> + * The return from netlbl_sock_setattr is ignored because
> + * the defaulting label behavior provided by netlbl takes
> + * care of the error cases.
Not quite ... NetLabel will take care of making sure things are labeled
correctly (default vs. ambient) but it can still fail for a variety of
reasons: memory pressure, labeling protocol cannot represent the
security attributes you passed, etc. Moral of the story, you still
need to check the return value of netlbl_sock_setattr() and deal with
failures in a sane manner.
> */
> -static int smack_netlabel(struct sock *sk)
> +static void smack_netlabel(struct sock *sk)
> {
> struct socket_smack *ssp = sk->sk_security;
> struct netlbl_lsm_secattr secattr;
> - int rc = 0;
> + int rc;
>
> netlbl_secattr_init(&secattr);
> smack_to_secattr(ssp->smk_out, &secattr);
> if (secattr.flags != NETLBL_SECATTR_NONE)
You can keep the above if-statement if you like, but NetLabel handles
this case gracefully (if it doesn't let me know, it's a bug) so it
isn't necessary.
> rc = netlbl_sock_setattr(sk, &secattr);
> -
> netlbl_secattr_destroy(&secattr);
> - return rc;
> }
>
> /**
> @@ -1340,7 +1340,7 @@ static int smack_inode_setsecurity(struc
> ssp->smk_in = sp;
> else if (strcmp(name, XATTR_SMACK_IPOUT) == 0) {
> ssp->smk_out = sp;
> - return smack_netlabel(sock->sk);
> + smack_netlabel(sock->sk);
See above comments regarding return values.
> } else
> return -EOPNOTSUPP;
>
> @@ -1367,7 +1367,8 @@ static int smack_socket_post_create(stru
> /*
> * Set the outbound netlbl.
> */
> - return smack_netlabel(sock->sk);
> + smack_netlabel(sock->sk);
> + return 0;
Same thing.
> }
>
> /**
> @@ -2199,7 +2200,6 @@ static int smack_socket_getpeersec_dgram
> static void smack_sock_graft(struct sock *sk, struct socket *parent)
> {
> struct socket_smack *ssp;
> - int rc;
>
> if (sk == NULL)
> return;
> @@ -2212,7 +2212,7 @@ static void smack_sock_graft(struct sock
> ssp->smk_out = current->security;
> ssp->smk_packet[0] = '\0';
>
> - rc = smack_netlabel(sk);
> + smack_netlabel(sk);
Once more, but with feeling.
> }
>
> /**
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Jarek Poplawski @ 2008-02-12 19:46 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: David Miller, shemminger, netdev, linux-kernel
In-Reply-To: <20080212193218.GA2803@ami.dom.local>
On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
...
> It seems the above version of this macro uses the barrier for 0, but
> if I miss something, or for these other: documenting reasons,
...or __builtin_constants could be used for indexing (?!),
> then of
> course you are right.
Jarek P.
^ permalink raw reply
* Re: e1000e hardware CRC stripping breaks bridging
From: Johan Andersson @ 2008-02-12 20:20 UTC (permalink / raw)
To: Kok, Auke; +Cc: Daniel Drake, netdev, jesse.brandeburg
In-Reply-To: <47B1D697.8030503@intel.com>
Kok, Auke wrote:
> Jesse figured it out. I just send you a patch to test, can you guys give that a
> try and see if it fixes the situation? Johan?
>
> thanks,
>
> Auke
>
Yes, I will test this patch right away.
/Johan
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Ross Vandegrift @ 2008-02-12 20:38 UTC (permalink / raw)
To: Andi Kleen; +Cc: Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080208120746.GE4745@one.firstfloor.org>
On Fri, Feb 08, 2008 at 01:07:46PM +0100, Andi Kleen wrote:
> On Thu, Feb 07, 2008 at 02:44:46PM -0500, Ross Vandegrift wrote:
> > On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
> > My initial test is end-to-end 1000Mbps, but I've got a few different
> > packet rates.
> >
> > > If the young/old heuristics do not work well enough anymore most
> > > likely we should try readding RED to the syn queue again. That used
> > > to be pretty effective in the early days. I don't quite remember why
> > > Linux didn't end up using it in fact.
> >
> > I'm running juno-z with 2, 4, & 8 threads of syn flood to port 80.
> > wireshark measures 2 threads at 350pps, 4 threads at 750pps, and 8
>
> What's the total bandwidth of the attack?
Sorry for the delay in getting back to you on this Andi.
Here's a breakdown for each attack of the pps and bandwidth:
packets/s Mb/s
380 0.182
715 0.343
1193 0.572
16460 7.896
The first three tests were done with some fixed delay inbetween syn
floods. The last is done with all delays as small as possible.
> > threads at 1200pps. Under no SYN flood, the server handles 750 HTTP
> > requests per second, measured via httping in flood mode.
>
> Thanks for the tests. Could you please do an additional experiment?
> Use sch_em or similar to add a jittering longer latency in the connection
> (as would be realistic in a real distributed DOS). Does it make a
> difference?
Jitter on both ends makes it worse. Jitter only on the syn flooder
end behaves approximately the same.
If I add jitter to both the flooder and the target with:
tc qdisc add dev eth0 root netem delay 50ms 100ms distribution normal
I can kill off the host with even a single thread of syn flooding,
even with a backlog queue size of 32768.
> > With a default tcp_max_syn_backlog of 1024, I can trivially prevent
> > any inbound client connections with 2 threads of syn flood.
> > Enabling tcp_syncookies brings the connection handling back up to 725
> > fetches per second.
>
> Yes the defaults are probably too low. That's something that should
> be fixed.
Yea, with a longer queue, the server is somewhat more resiliant. But
it's still pretty easy to overwhelm it. syncookies is a night and day
difference.
> > At these levels the CPU impact of tcp_syncookies is nothing. I can't
>
> CPU impact of syncookies was never a concern. The problems are rather
> missing flow control and disabling of valuable TCP features.
Oh definitely - Willy raised the CPU issue in another mail, I was just
including my findings with a bigger CPU.
In general I agree with you for the TCP features, but in the cases where
we're enabling syncookies, it's the difference between bad connectivity and
no connectivity.
--
Ross Vandegrift
ross@kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
^ permalink raw reply
* E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Krzysztof Halasa @ 2008-02-12 21:25 UTC (permalink / raw)
To: linux-kernel, netdev
Hi,
Is it a known problem?
Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
e1000e).
Don't work by default. "pci=nomsi" fixes the problem.
82572EI Gigabit Ethernet Controller (Copper) (rev 06)
Subsystem: PRO/1000 PT Desktop Adapter
(8086:10b9 subsystem 8086:1083)
grep eth0 /proc/interrupts
20: 1945 1 IO-APIC-fasteoi eth0
(without "pci=nomsi":
221: 0 0 PCI-MSI-edge eth0)
other devices of possible interest:
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
Additional details on request.
--
Krzysztof Halasa
^ permalink raw reply
* Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Prakash Punnoor @ 2008-02-12 21:34 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: linux-kernel, netdev
In-Reply-To: <m37ih9ooim.fsf@maximus.localdomain>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
> Hi,
>
> Is it a known problem?
> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
> e1000e).
>
> Don't work by default. "pci=nomsi" fixes the problem.
Probably the patch to enable msi bit on the host bridge(?) is still missing in
mainline. I needed that patch to make msi work on my MCP51 system.
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* permisions for Ethetool vs rtnetlink
From: Rick Jones @ 2008-02-12 22:08 UTC (permalink / raw)
To: Linux Network Development list
I've been further enhancing the netperf omni tests to enable reporting
stuff like uname for local/remote, the name of the probable egress
interface (rtnetlink), and then driver information for that interface.
I figure that such information being spat-out by netperf might be useful
to have if one were setting-up a database of results and/or making
regression checks and the like.
It struck me as a little odd that I can retrieve routing information for
a destination as a mere mortal, but to retreive driver information for
an interface I have to be priviledged. At first glance I would think
the sensitivity of both sets of information would be about the same?
Is the difference simply an artifact of history?
sincerely,
rick jones
^ permalink raw reply
* [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.
From: Steve Wise @ 2008-02-12 22:09 UTC (permalink / raw)
To: rdreier; +Cc: netdev, linux-kernel, general
RDMA/cxgb3: Fail loopback connections.
The cxgb3 HW and driver don't support loopback RDMA connections. So fail
any connection attempt where the destination address is local.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index e9a08fa..5d82723 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1784,6 +1784,17 @@ err:
return err;
}
+static void is_loopback_dst(struct iw_cm_id *cm_id)
+{
+ struct net_device *dev;
+
+ dev = ip_dev_find(&init_net, cm_id->remote_addr.sin_addr.s_addr);
+ if (!dev)
+ return 0;
+ dev_put(dev);
+ return 1;
+}
+
int iwch_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
{
int err = 0;
@@ -1791,6 +1802,11 @@ int iwch_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
struct iwch_ep *ep;
struct rtable *rt;
+ if (is_loopback_dst(cm_id)) {
+ err = -ENOSYS;
+ goto out;
+ }
+
ep = alloc_ep(sizeof(*ep), GFP_KERNEL);
if (!ep) {
printk(KERN_ERR MOD "%s - cannot alloc ep.\n", __FUNCTION__);
^ permalink raw reply related
* Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Kok, Auke @ 2008-02-12 22:24 UTC (permalink / raw)
To: Prakash Punnoor; +Cc: Krzysztof Halasa, linux-kernel, netdev
In-Reply-To: <200802122234.47164.prakash@punnoor.de>
Prakash Punnoor wrote:
> On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
>> Hi,
>>
>> Is it a known problem?
>> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
>> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
>> e1000e).
your card will work with e1000e from 2.6.25 onwards.
>> Don't work by default. "pci=nomsi" fixes the problem.
actually does not fix anything - it just works around it by falling back to legacy
interrupts.
> Probably the patch to enable msi bit on the host bridge(?) is still missing in
> mainline. I needed that patch to make msi work on my MCP51 system.
and there have been many more reports. unfortunately e1000 cards are one of the
few things that actually uses MSI. It works great except for a few problematic
motherboards, and the ones mentioned in this thread fall amongst them.
Auke
^ permalink raw reply
* Re: r8169 auto-negotiation problem
From: Francois Romieu @ 2008-02-12 22:20 UTC (permalink / raw)
To: fgnijuhhu guduggurehug; +Cc: netdev
In-Reply-To: <BAY107-W2892B3D06485CBB5AEDCC2D52B0@phx.gbl>
fgnijuhhu guduggurehug <jsmiths1234@live.com> :
> > fgnijuhhu guduggurehug :
> > [...]
> >> I already posted my problem and what I did to solve it on
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
> >
> > Have you tried anything more recent than a 2.6.18 based kernel ?
>
> No, but if changes were made to the iniatialization of the chipset
> in the current driver (mine was 2.2LK), this might do the trick.
Please try a recent kernel. Your r8169 driver is badly outdated.
[...]
> Anyway, how to best upgrade the kernel in debian (without problems,
> of course) ? The problem right now is that every apt-get upgrade
> reverts the r8169 driver to the old one...
I do not use debian but you can read:
http://www.google.com/search?q=debian+kernel+upgrade
--
Ueimor
^ permalink raw reply
* [PATCH] libertas: Remove unused exports
From: Roland Dreier @ 2008-02-12 23:08 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Dan Williams
In-Reply-To: <adatzkj0z7l.fsf@cisco.com>
The libertas driver exports a number of symbols with no in-tree
users; remove these unused exports. lbs_reset_device() is completely
unused, with no callers at all, so remove the function completely.
A couple of these unused exported symbols are static, which causes the
following build error on ia64 with gcc 4.2.3:
drivers/net/wireless/libertas/main.c:1375: error: __ksymtab_lbs_remove_mesh causes a section type conflict
drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh causes a section type conflict
This patch fixes this problem. I don't have hardware, so this is not
run-tested, but I tested the build with
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
Here's the patch that removes the unused exports (and a few more that
I found).
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -1040,7 +1040,6 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t cmd_action,
lbs_deb_leave(LBS_DEB_CMD);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_mesh_access);
int lbs_mesh_config(struct lbs_private *priv, uint16_t enable, uint16_t chan)
{
@@ -1576,7 +1575,6 @@ done:
lbs_deb_leave_args(LBS_DEB_HOST, "ret %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_prepare_and_send_command);
/**
* @brief This function allocates the command buffer and link
diff --git a/drivers/net/wireless/libertas/decl.h b/drivers/net/wireless/libertas/decl.h
index aaacd9b..4e22341 100644
--- a/drivers/net/wireless/libertas/decl.h
+++ b/drivers/net/wireless/libertas/decl.h
@@ -69,7 +69,6 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev);
int lbs_remove_card(struct lbs_private *priv);
int lbs_start_card(struct lbs_private *priv);
int lbs_stop_card(struct lbs_private *priv);
-int lbs_reset_device(struct lbs_private *priv);
void lbs_host_to_card_done(struct lbs_private *priv);
int lbs_update_channel(struct lbs_private *priv);
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index 84fb49c..1eaf6af 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1351,8 +1350,6 @@ done:
lbs_deb_leave_args(LBS_DEB_MESH, "ret %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_add_mesh);
-
static void lbs_remove_mesh(struct lbs_private *priv)
{
@@ -1372,7 +1369,6 @@ static void lbs_remove_mesh(struct lbs_private *priv)
free_netdev(mesh_dev);
lbs_deb_leave(LBS_DEB_MESH);
}
-EXPORT_SYMBOL_GPL(lbs_remove_mesh);
/**
* @brief This function finds the CFP in
@@ -1458,20 +1454,6 @@ void lbs_interrupt(struct lbs_private *priv)
}
EXPORT_SYMBOL_GPL(lbs_interrupt);
-int lbs_reset_device(struct lbs_private *priv)
-{
- int ret;
-
- lbs_deb_enter(LBS_DEB_MAIN);
- ret = lbs_prepare_and_send_command(priv, CMD_802_11_RESET,
- CMD_ACT_HALT, 0, 0, NULL);
- msleep_interruptible(10);
-
- lbs_deb_leave_args(LBS_DEB_MAIN, "ret %d", ret);
- return ret;
-}
-EXPORT_SYMBOL_GPL(lbs_reset_device);
-
static int __init lbs_init_module(void)
{
lbs_deb_enter(LBS_DEB_MAIN);
^ 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