* Re: PHY down?
From: Joakim Tjernlund @ 2011-08-02 12:24 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1312282868.2591.68.camel@deadeye>
Ben Hutchings <bhutchings@solarflare.com> wrote on 2011/08/02 13:01:08:
>
> On Tue, 2011-08-02 at 11:24 +0200, Joakim Tjernlund wrote:
> > I must be missing something obvious but I cannot find how
> > to bring eth0's PHY down (link down) from user space.
> > Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
>
> If you configure an interface down, and if the interface is not used for
> remote management, then some drivers will turn the PHY off. But there
> is no general way to control this explicitly.
OK, when to stop the PHY doesn't seem standardized. Seem logical to me
to also turn off the PHY when interface is configured down. Perhaps this could
be agreed upon?
What does remote management mean? How do I identify if the I/F is used for remote management?
Jocke
>
> Ben.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 12:01 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <201108022052.FBE56208.FLQHFtMOVOSOJF@I-love.SAKURA.ne.jp>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Tue, 2 Aug 2011 20:52:05 +0900
> David Miller wrote:
>> Actually, I change my mind. :-)
>>
>> I think sendmmsg() needs to unconditionally not report an error if any
>> datagrams were sent successfully.
>
> What about adding
I much prefer to make the error handling more correct, rather than
making sendmmsg() have fundamentally different semantics depending
upon the underlying LSM.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-08-02 11:52 UTC (permalink / raw)
To: davem; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110802.042641.2122529993066553943.davem@davemloft.net>
David Miller wrote:
> Actually, I change my mind. :-)
>
> I think sendmmsg() needs to unconditionally not report an error if any
> datagrams were sent successfully.
What about adding
#ifdef CONFIG_SECURITY_NETWORK
static inline bool security_socket_may_send_multiple_address(void)
{
return security_ops->socket_may_send_multiple_address;
}
#else
static inline bool security_socket_may_send_multiple_address(void)
{
return true;
}
#endif
and letting SMACK and TOMOYO return false and others return true?
The check will look like
if (sendmmsg) {
Record destination address of first datagram if first datagram,
compare with recorded address and subsequent datagram otherwise.
If same address, continue. Otherwise, call
security_socket_may_send_multiple_address() and break if it returns false.
}
. The side effect is that sendmmsg() will be allowed to send to single
destination if underlying LSM module does not permit sending to multiple
address, to multiple destination otherwise. As long as sendmmsg() is used for
sending to single destination, there will be no performance loss.
It will be kmalloc()-free, fast and simple. Also, makes LSM stacking easier.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 11:26 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110802.041857.1325765319466840715.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 02 Aug 2011 04:18:57 -0700 (PDT)
> From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Date: Tue, 02 Aug 2011 18:28:40 +0900
>
>> I think this behavior is not preferable. In this case, should
>> security_socket_sendmsg() return -EAGAIN rather than -EPERM? Or,
>> should sendmmsg() not record errors after some of datagrams were
>> sent?
>
> I think you must return -EAGAIN so that the user can see how many
> of the datagrams were sent successfully.
>
> In fact, it is a requirement. What if the sent datagrams have
> side effects (f.e. money moves from one bank account to another)?
>
> How else can the application find this out?
Actually, I change my mind. :-)
I think sendmmsg() needs to unconditionally not report an error if any
datagrams were sent successfully.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 11:18 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <201108020928.p729Sekl091800@www262.sakura.ne.jp>
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: Tue, 02 Aug 2011 18:28:40 +0900
> I think this behavior is not preferable. In this case, should
> security_socket_sendmsg() return -EAGAIN rather than -EPERM? Or,
> should sendmmsg() not record errors after some of datagrams were
> sent?
I think you must return -EAGAIN so that the user can see how many
of the datagrams were sent successfully.
In fact, it is a requirement. What if the sent datagrams have
side effects (f.e. money moves from one bank account to another)?
How else can the application find this out?
^ permalink raw reply
* Re: PHY down?
From: Ben Hutchings @ 2011-08-02 11:01 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF6D5A2ABF.61D9AA63-ONC12578E0.00335EE4-C12578E0.0033AE22@transmode.se>
On Tue, 2011-08-02 at 11:24 +0200, Joakim Tjernlund wrote:
> I must be missing something obvious but I cannot find how
> to bring eth0's PHY down (link down) from user space.
> Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
If you configure an interface down, and if the interface is not used for
remote management, then some drivers will turn the PHY off. But there
is no general way to control this explicitly.
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
* PHY down?
From: Joakim Tjernlund @ 2011-08-02 9:24 UTC (permalink / raw)
To: netdev
I must be missing something obvious but I cannot find how
to bring eth0's PHY down (link down) from user space.
Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
Jocke
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-08-02 9:28 UTC (permalink / raw)
To: davem; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110801.230731.1942061135621106602.davem@davemloft.net>
David Miller wrote:
> From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Date: Thu, 28 Jul 2011 12:36:30 +0900
>
> > Here is an optimized version. Only compile tested.
>
> Anton, please test this or I'm just going to apply it before it
> gets any testing :-)
Just a moment please. I found a problem (described below).
I tested on TOMOYO using below program
--- Start of test program ---
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/ethernet.h>
#include <linux/if_packet.h>
#include <asm/unistd.h>
#include <errno.h>
#ifndef __NR_sendmmsg
#if defined( __PPC__)
#define __NR_sendmmsg 349
#elif defined(__x86_64__)
#define __NR_sendmmsg 307
#elif defined(__i386__)
#define __NR_sendmmsg 345
#else
#error __NR_sendmmsg not defined
#endif
#endif
struct mmsghdr {
struct msghdr msg_hdr;
unsigned int msg_len;
};
static inline int sendmmsg(int fd, struct mmsghdr *mmsg, unsigned vlen,
unsigned flags)
{
return syscall(__NR_sendmmsg, fd, mmsg, vlen, flags, NULL);
}
static unsigned long packets;
static unsigned long packets_prev;
static void sigalrm_handler(int junk)
{
unsigned long p = packets;
printf("%ld\n", p - packets_prev);
packets_prev = p;
alarm(1);
}
#define NUMDESTS 20
#define NUMBATCH 100
int main(int argc, char *argv[])
{
const int fd = socket(AF_INET, SOCK_DGRAM, 0);
unsigned int i;
char b[10];
static char buf[NUMBATCH][10];
static struct iovec iovec[NUMBATCH][1];
static struct mmsghdr datagrams[NUMBATCH];
struct sockaddr_in addr[NUMDESTS];
signal(SIGALRM, sigalrm_handler);
alarm(1);
memset(buf, 0, sizeof(buf));
memset(iovec, 0, sizeof(iovec));
memset(datagrams, 0, sizeof(datagrams));
memset(&addr, 0, sizeof(addr));
for (i = 0; i < sizeof(b); i++)
b[i]= i;
for (i = 0; i < NUMDESTS; i++) {
addr[i].sin_family = AF_INET;
addr[i].sin_addr.s_addr = htonl(INADDR_LOOPBACK);
addr[i].sin_port = htons(10000 + (argc == 1 ? i : 0) * 10);
}
for (i = 0; i < NUMBATCH; ++i) {
memcpy(&buf[i], b, sizeof(buf[i]));
iovec[i][0].iov_base = buf[i];
iovec[i][0].iov_len = sizeof(buf[i]);
datagrams[i].msg_hdr.msg_iov = iovec[i];
datagrams[i].msg_hdr.msg_iovlen = 1;
datagrams[i].msg_hdr.msg_name = &addr[i % NUMDESTS];
datagrams[i].msg_hdr.msg_namelen = sizeof(addr[0]);
}
while (1) {
int ret;
errno = 0;
ret = sendmmsg(fd, datagrams, NUMBATCH, 0);
if (ret < 0) {
perror("sendmmsg");
exit(1);
}
if (ret != NUMBATCH) {
fprintf(stderr,
"sendmmsg returned sent less than batch %d\n", ret);
}
packets += ret;
}
return 0;
}
--- End of test program ---
and realized that remembering the fact that LSM module has returned an error
code other than -EAGAIN causes subsequent sendmmsg() request to fail with that
error code.
fput_light(sock->file, fput_needed);
if (err == 0)
return datagrams;
if (datagrams != 0) {
/*
* We may send less entries than requested (vlen) if the
* sock is non blocking...
*/
if (err != -EAGAIN) {
/*
* ... or if sendmsg returns an error after we
* send some datagrams, where we record the
* error to return on the next call or if the
* app asks about it using getsockopt(SO_ERROR).
*/
sock->sk->sk_err = -err;
}
return datagrams;
}
return err;
For example, if TOMOYO returned -EPERM on the 14th datagram,
subsequent sendmmsg() fails with EPERM and the program will exit().
sendmmsg returned sent less than batch 14
sendmmsg: Operation not permitted
I think this behavior is not preferable.
In this case, should security_socket_sendmsg() return -EAGAIN rather than
-EPERM?
Or, should sendmmsg() not record errors after some of datagrams were sent?
^ permalink raw reply
* Re: [PATCH net] bnx2x: Prevent restarting Tx during bnx2x_nic_unload
From: David Miller @ 2011-08-02 8:35 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <201108021052.37368.vladz@broadcom.com>
From: "Vlad Zolotarov" <vladz@broadcom.com>
Date: Tue, 2 Aug 2011 10:52:37 +0300
> Tx queues were stopped before bp->state was changed to a value different
> from BNX2X_STATE_OPEN, which allowed the bnx2x_tx_int() called from the
> NAPI context to re-enable it. This then allowed the netdev->ndo_start_xmit()
> to be called in the middle of the function reset and rings freeing.
>
> This patch changes bp->state to a value different
> from BNX2X_STATE_OPEN BEFORE disabling the Tx queues in order to restore the
> broken protection against the above race in the bnx2x_tx_int().
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thansk Vlad.
^ permalink raw reply
* [PATCH net] bnx2x: Prevent restarting Tx during bnx2x_nic_unload
From: Vlad Zolotarov @ 2011-08-02 7:52 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev@vger.kernel.org, Eilon Greenstein
Tx queues were stopped before bp->state was changed to a value different
from BNX2X_STATE_OPEN, which allowed the bnx2x_tx_int() called from the
NAPI context to re-enable it. This then allowed the netdev->ndo_start_xmit()
to be called in the middle of the function reset and rings freeing.
This patch changes bp->state to a value different
from BNX2X_STATE_OPEN BEFORE disabling the Tx queues in order to restore the
broken protection against the above race in the bnx2x_tx_int().
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 5b0dba6..d724a18 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1989,14 +1989,20 @@ int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
return -EINVAL;
}
+ /*
+ * It's important to set the bp->state to the value different from
+ * BNX2X_STATE_OPEN and only then stop the Tx. Otherwise bnx2x_tx_int()
+ * may restart the Tx from the NAPI context (see bnx2x_tx_int()).
+ */
+ bp->state = BNX2X_STATE_CLOSING_WAIT4_HALT;
+ smp_mb();
+
/* Stop Tx */
bnx2x_tx_disable(bp);
#ifdef BCM_CNIC
bnx2x_cnic_notify(bp, CNIC_CTL_STOP_CMD);
#endif
- bp->state = BNX2X_STATE_CLOSING_WAIT4_HALT;
- smp_mb();
bp->rx_mode = BNX2X_RX_MODE_NONE;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 6:07 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <201107280336.p6S3aUY7004372@www262.sakura.ne.jp>
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: Thu, 28 Jul 2011 12:36:30 +0900
> Here is an optimized version. Only compile tested.
Anton, please test this or I'm just going to apply it before it
gets any testing :-)
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: Jeff Kirsher @ 2011-08-02 3:58 UTC (permalink / raw)
To: David Miller
Cc: jgarzik@pobox.com, bhutchings@solarflare.com,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
nic_swsd@realtek.com, romieu@fr.zoreil.com, becker@scyld.com
In-Reply-To: <20110801.204840.1467588276691539635.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
On Mon, 2011-08-01 at 20:48 -0700, David Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Mon, 01 Aug 2011 23:21:20 -0400
>
> > On 08/01/2011 08:24 PM, Ben Hutchings wrote:
> >> On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
> >>> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
> >>> the necessary Kconfig and Makefile changes.
> >> [...]
> >>
> >> Does it really make sense to move the pci-skeleton driver? Although
> >> it
> >> includes hardware access specific to RTL8139 chips, that's not really
> >> the point of it.
> >
> > Indeed. pci-skeleton was simply intended to illustrate a clean driver
> > for a simple DMA-driven NIC.
> >
> > Honestly, it's so outdated now that deletion would be a better course.
>
> Yeah, this is probably true.
Ok, I will remove it.
I will put together a v3 of the series.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 70/71] tile: Move the Tilera driver
From: Jeff Kirsher @ 2011-08-02 3:53 UTC (permalink / raw)
To: Chris Metcalf, H Hartley Sweeten, Geert Uytterhoeven
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <4E36E0B2.60900@tilera.com>
[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]
On Mon, 2011-08-01 at 10:21 -0700, Chris Metcalf wrote:
> On 7/30/2011 11:27 PM, Jeff Kirsher wrote:
> > Move the Tilera driver into drivers/net/ethernet/tile and
> > make the necessary Kconfig and Makefile changes.
> >
> > CC: Chris Metcalf <cmetcalf@tilera.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > [...]
> > +++ b/drivers/net/ethernet/tile/Kconfig
> > @@ -0,0 +1,28 @@
> > +#
> > +# Tilera network device configuration
> > +#
> > +
> > +config NET_VENDOR_TILERA
> > + bool "Tilera devices"
> > + depends on TILE
> > + ---help---
> > + If you have a network (Ethernet) card belonging to this class, say Y
> > + and read the Ethernet-HOWTO, available from
> > + <http://www.tldp.org/docs.html#howto>.
> > +
> > + Note that the answer to this question doesn't directly affect the
> > + kernel: saying N will just cause the configurator to skip all
> > + the questions about Tilera cards. If you say Y, you will be asked for
> > + your specific card in the following questions.
> > +
> > +config TILE_NET
> > + tristate "Tilera GBE/XGBE network driver support"
> > + depends on NET_VENDOR_TILERA && TILE
> > + default y
> > + select CRC32
> > + ---help---
> > + This is a standard Linux network device driver for the
> > + on-chip Tilera Gigabit Ethernet and XAUI interfaces.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called tile_net.
>
> Overall, this seems fine, since the Tilera drivers get grouped more
> appropriately as a result. However, the drivers in question are not
> Ethernet cards (and Tilera is not an Ethernet card vendor and has no plans
> to become one). Instead, this is the driver support for the built-in
> networking hardware on the Tilera multicore CPU chip. I'm happy to group
> this support under drivers/net/ethernet/tile/, but I think it's appropriate
> to default it to "Y" if you are building a TILE kernel (since you are
> guaranteed to have the networking hardware available).
>
> I suspect for now the cleanest thing to do is to fold the two config
> options together, using NET_VENDOR_TILERA for consistency with other
> NET_VENDOR_xxx symbols, and defaulting it to "Y" via "depends on TILE". I
> don't think the Ethernet-HOWO reference is particularly helpful since it
> mostly tackles all the various card issues, kernel boot param issues, etc.,
> none of which are relevant to this driver. Something like:
>
> +config NET_VENDOR_TILERA
> + bool "Tilera devices"
> + depends on TILE
> + default y
> + select CRC32
> + ---help---
> + This is a standard Linux network device driver for the arch/tile
> + on-chip Gigabit Ethernet and XAUI interfaces.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called tile_net.
>
>
> Obviously you'd also need to tweak the TILE_NET symbol in the Makefile to
> be VENDOR_TILERA. If this makes sense to you, go ahead and make the
> change, and feel free to use my
>
> Acked-by: Chris Metcalf <cmetcalf@tilera.com>
>
Sounds fine, I will make the necessary changes.
Also based on feedback from Hartley Sweeten and Geert Uytterhoeven, I
will make a change to the Kconifg's to make it less a maintenance issue
going forward by wrapping the drivers in the Kconfig with "if
NET_VENDOR_<blah> ... endif. This way new drivers will not have to add
the dependency of NET_VENDOR_<blah>.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: David Miller @ 2011-08-02 3:48 UTC (permalink / raw)
To: jgarzik
Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo, sassmann, nic_swsd,
romieu, becker
In-Reply-To: <4E376D30.6050406@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Mon, 01 Aug 2011 23:21:20 -0400
> On 08/01/2011 08:24 PM, Ben Hutchings wrote:
>> On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
>>> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
>>> the necessary Kconfig and Makefile changes.
>> [...]
>>
>> Does it really make sense to move the pci-skeleton driver? Although
>> it
>> includes hardware access specific to RTL8139 chips, that's not really
>> the point of it.
>
> Indeed. pci-skeleton was simply intended to illustrate a clean driver
> for a simple DMA-driven NIC.
>
> Honestly, it's so outdated now that deletion would be a better course.
Yeah, this is probably true.
^ permalink raw reply
* Re: [Bug?] Machine hangs, rtl8192se possible cause
From: Larry Finger @ 2011-08-02 3:45 UTC (permalink / raw)
To: Jaroslaw Fedewicz
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAFdoEiRBPMx0C+YXwd4-Q=_nHpOb+r2+GspwujZrPh6S4tDwEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 08/01/2011 06:10 PM, Jaroslaw Fedewicz wrote:
>
> I'm using a fairly recent version of kernel from git (I think from
> before yesterday). The mysterious hangs were there from the beginning,
> but it also might be partly because ATI driver was messed up too at
> these times. Later, ati appeared fixed but the hangs wouldn't go away.
If that git tree is linux-2.6, or its new name, from Linus, then you have the
latest source.
> I don't think it's a panic proper, though. Nothing ever gets logged
> along the lines of "panic". Even if I happen to have a text mode
> console, it just freezes. If I have a panic or an oops proper, I'm
> also kicked out of X11 to see it by the KMS. But not in this case.
>
> (Also, the laptop has neither Caps Lock nor Num Lock nor Scroll Lock
> LEDs, so I can't see if they blink.)
A kernel panic never logs anything to the disk. The only place you will see it
is on the logging console, or in netconsole output.
> What raised my suspicions is that I've never seen this happen when
> rtl8192se wasn't compiled at all or was not loaded.
>
> The most problematic thing is that it does not hang right away. Most
> of the time, I see the machine go into the catatonia after quite a
> while, and as it is not the laptop I do most of my work on, I usually
> see it hanged when screen PM has already kicked in. So I cannot really
> read what the log might say on the matter.
>
> I cannot also trigger the freeze reliably. Most of the time it happens
> "when you are not looking at it", and it usually happens either during
> or just after high load averages and low to none network activity (a
> typical scenario: build a firefox from sources, go outside, come home
> 4 hours later, the laptop is turned on but dead by hanging; no
> messages as the screen is obviously off; a less typical scenario is to
> freeze during startup).
>
> I'm the last person ever to suggest anything on the subject, but could
> it be a problem in the card's power management?
Not likely. I have three different cards with differing configurations that I
have run for extended periods without seeing your problem. One of them is the
same as yours.
Until you get some kind of dump from the system, I'm not sure what can be done.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: Jeff Kirsher @ 2011-08-02 3:41 UTC (permalink / raw)
To: Jeff Garzik
Cc: Ben Hutchings, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com,
Realtek linux nic maintainers, Francois Romieu, Donald Becker
In-Reply-To: <4E376D30.6050406@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
On Mon, 2011-08-01 at 20:21 -0700, Jeff Garzik wrote:
> On 08/01/2011 08:24 PM, Ben Hutchings wrote:
> > On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
> >> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
> >> the necessary Kconfig and Makefile changes.
> > [...]
> >
> > Does it really make sense to move the pci-skeleton driver? Although it
> > includes hardware access specific to RTL8139 chips, that's not really
> > the point of it.
>
> Indeed. pci-skeleton was simply intended to illustrate a clean driver
> for a simple DMA-driven NIC.
>
> Honestly, it's so outdated now that deletion would be a better course.
If it would be useful, should we take the time to update pci-skeleton
driver? Or will this be a maintenance issue going forward and deletion
is the best answer?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: Jeff Garzik @ 2011-08-02 3:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jeff Kirsher, davem, netdev, gospo, sassmann,
Realtek linux nic maintainers, Francois Romieu, Donald Becker
In-Reply-To: <1312244694.2591.42.camel@deadeye>
On 08/01/2011 08:24 PM, Ben Hutchings wrote:
> On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
>> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
>> the necessary Kconfig and Makefile changes.
> [...]
>
> Does it really make sense to move the pci-skeleton driver? Although it
> includes hardware access specific to RTL8139 chips, that's not really
> the point of it.
Indeed. pci-skeleton was simply intended to illustrate a clean driver
for a simple DMA-driven NIC.
Honestly, it's so outdated now that deletion would be a better course.
Jeff
^ permalink raw reply
* Re: failure to find rate WARN_ON on iwlagn
From: Dave Jones @ 2011-08-02 2:31 UTC (permalink / raw)
To: netdev; +Cc: ilw
In-Reply-To: <20110706151128.GB1425@redhat.com>
On Wed, Jul 06, 2011 at 11:11:28AM -0400, Dave Jones wrote:
> I just hit this trace 3 times on this hardware..
> 04:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
I'm still seeing this every couple days, even on current trees.
Dave
> wlan0: authenticate with b8:c7:5d:0c:39:88 (try 1)
> wlan0: authenticate with b8:c7:5d:0c:39:88 (try 2)
> wlan0: authenticate with b8:c7:5d:0c:39:88 (try 3)
> wlan0: authentication with b8:c7:5d:0c:39:88 timed out
> ------------[ cut here ]------------
> WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
> Hardware name: Adamo 13
> Modules linked in: sctp libcrc32c ip_queue can_raw cmtp kernelcapi rfcomm can_bcm hidp caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose ax25 x25 atm appletalk ipx p8022 psnap llc p8023 tcp_lp nfs fscache fuse nfsd lockd nfs_acl auth_rpcgss sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables btusb bluetooth arc4 dell_wmi sparse_keymap snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hda_codec_hdmi snd_hda_codec_idt cdc_ether usbnet cdc_wdm mii snd_hda_intel snd_hda_codec snd_hwdep cdc_acm uvcvideo dell_laptop snd_seq microcode videodev v4l2_compat_ioctl32 dcdbas snd_seq_device snd_pcm iwlagn mac80211 iTCO_wdt tg3 cfg80211 pcspkr joydev i2c_i801 iTCO_vend
or_support rfkill snd_timer snd soundcore snd_page_alloc wmi virtio_net kvm_intel kvm ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_s!
> can]
> Pid: 0, comm: swapper Not tainted 3.0.0-rc5+ #89
> Call Trace:
> <IRQ> [<ffffffff8105acfc>] warn_slowpath_common+0x83/0x9b
> [<ffffffff8105ad2e>] warn_slowpath_null+0x1a/0x1c
> [<ffffffffa0252b17>] rate_control_send_low+0x8b/0x10f [mac80211]
> [<ffffffffa0291c59>] rs_get_rate+0x138/0x215 [iwlagn]
> [<ffffffffa0252fcf>] rate_control_get_rate+0x86/0x14c [mac80211]
> [<ffffffff814cf60e>] ? _raw_spin_unlock_irqrestore+0x6c/0x7a
> [<ffffffffa025bde1>] invoke_tx_handlers+0x8f3/0xf47 [mac80211]
> [<ffffffffa025a4f0>] ? compare_ether_addr+0x2c/0x2c [mac80211]
> [<ffffffff814c818e>] ? __slab_alloc+0x399/0x3b4
> [<ffffffffa025c4b4>] ieee80211_tx+0x7f/0xaf [mac80211]
> [<ffffffffa025c66a>] ieee80211_xmit+0x186/0x19a [mac80211]
> [<ffffffff81060d3f>] ? __local_bh_disable+0x8c/0xbe
> [<ffffffffa025d5dc>] ieee80211_tx_skb+0x56/0x5e [mac80211]
> [<ffffffffa02493c3>] ieee80211_send_bar+0xda/0xe9 [mac80211]
> [<ffffffffa0243928>] ieee80211_tx_status+0x25c/0x808 [mac80211]
> [<ffffffff814cf600>] ? _raw_spin_unlock_irqrestore+0x5e/0x7a
> [<ffffffffa0242d12>] ieee80211_tasklet_handler+0x5b/0xa8 [mac80211]
> [<ffffffff81061311>] tasklet_action+0x93/0xf3
> [<ffffffff810614ba>] __do_softirq+0x10f/0x257
> [<ffffffff814d6bdc>] call_softirq+0x1c/0x30
> [<ffffffff8100bcaa>] do_softirq+0x4b/0xa1
> [<ffffffff8106189d>] irq_exit+0x5d/0xb5
> [<ffffffff814d747d>] do_IRQ+0x8d/0xa4
> [<ffffffff814cfc13>] common_interrupt+0x13/0x13
> <EOI> [<ffffffff814d29f7>] ? notifier_call_chain+0xbb/0xbb
> [<ffffffff812e11c3>] ? arch_local_irq_enable+0x8/0xd
> [<ffffffff8108e2a8>] ? trace_hardirqs_on+0xd/0xf
> [<ffffffff812e1d80>] acpi_idle_enter_c1+0xa0/0xbe
> [<ffffffff813e0acb>] cpuidle_idle_call+0x10c/0x1eb
> [<ffffffff81009323>] cpu_idle+0xe3/0x143
> [<ffffffff81d3dbc2>] ? start_kernel+0x401/0x40c
> [<ffffffff814abc71>] rest_init+0xd5/0xdc
> [<ffffffff814abb9c>] ? csum_partial_copy_generic+0x16c/0x16c
> [<ffffffff81d3dbc2>] start_kernel+0x401/0x40c
> [<ffffffff81d3d2c4>] x86_64_start_reservations+0xaf/0xb3
> [<ffffffff81d3d140>] ? early_idt_handlers+0x140/0x140
> [<ffffffff81d3d3ca>] x86_64_start_kernel+0x102/0x111
> ---[ end trace ab18f52dc63f6394 ]---
>
> --
> 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
---end quoted text---
^ permalink raw reply
* Re: pandaboard brctl oops
From: Shan Wei @ 2011-08-02 2:24 UTC (permalink / raw)
To: Marek Vasut; +Cc: netdev, linux-arm-kernel, linux-omap, m.kloucek.m
In-Reply-To: <201108012325.17312.marek.vasut@gmail.com>
hi
Marek Vasut wrote, at 08/02/2011 05:25 AM:
> Hi,
>
> recently a friend of mine sent me this backtrace. I put him in CC so please any
> subsequent questions shall be forwarded to him.
>
> He claims this happens on pandaboard.
>
> Cheers
>
> root@box:~# brctl addbr br0
> root@box:~# brctl addif br0 eth0
> [ 77.795776] Unable to handle kernel NULL pointer dereference at virtual
> address 00000000
> [ 77.804321] pgd = ee8d4000
> [ 77.807312] [00000000] *pgd=af8e6831, *pte=00000000, *ppte=00000000
> [ 77.813995] Internal error: Oops: 80000007 [#1] SMP
> [ 77.819122] last sysfs file: /sys/devices/virtual/net/br0/uevent
> [ 77.825439] Modules linked in: bridge stp llc wl12xx_sdio wl12xx
> [ 77.831787] CPU: 0 Not tainted (2.6.39.2-omap4 #3)
> [ 77.837188] PC is at 0x0
> [ 77.839904] LR is at br_change_mtu+0x64/0x7c [bridge]
This one has been fixed in latest kernel.
commit 6407d74c5106bb362b4087693688afd34942b094
Author: Alexander Holler <holler@ahsoftware.de>
Date: Tue Jun 7 00:51:35 2011 -0700
bridge: provide a cow_metrics method for fake_ops
Like in commit 0972ddb237 (provide cow_metrics() methods to blackhole
dst_ops), we must provide a cow_metrics for bridges fake_dst_ops as
well.
This fixes a regression coming from commits 62fa8a846d7d (net: Implement
read-only protection and COW'ing of metrics.) and 33eb9873a28 (bridge:
initialize fake_rtable metrics)
ip link set mybridge mtu 1234
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH] cxgb3i: ref count cdev access to prevent modification while in use
From: Neil Horman @ 2011-08-02 2:00 UTC (permalink / raw)
To: David Miller, swise; +Cc: netdev, divy, swise, kxie
Argh! My bad. Ill resubmit to linux-scsi
Neil
David Miller <davem@davemloft.net> wrote:
>From: Steve Wise <swise@opengridcomputing.com>
>Date: Mon, 01 Aug 2011 09:42:57 -0500
>
>>
>>>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>>>> CC: Divy Le Ray<divy@chelsio.com>
>>>> CC: Steve Wise<swise@chelsio.com>
>>>> CC: "David S. Miller"<davem@davemloft.net>
>>> Divy, Steve, I think Dave is waiting for an ACK from one of you to,
>>> since you're
>>> the listed maintainers.
>>> Neil
>>
>> Karen is the cxgb3i maintainer, but I just now reviewed the patch and
>> it looks good. Divy is on vacation for a few weeks. I think its ok
>> to pull it in since Karen already acked it.
>
>And just to make clear this needs to go via the SCSI tree not via me.
>
^ permalink raw reply
* Re: [PATCH 6/6] bna: Tx and Rx Redesign
From: David Miller @ 2011-08-02 1:09 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1312231375-14398-7-git-send-email-rmody@brocade.com>
This just adds a lot of new code, but there are no users of this
new code.
Resubmit this when you have the actual users of the code ready.
I'm not applying this entire patch series.
^ permalink raw reply
* Re: [PATCH] sunrpc: use better NUMA affinities
From: J. Bruce Fields @ 2011-08-02 1:06 UTC (permalink / raw)
To: NeilBrown
Cc: Greg Banks, Eric Dumazet, Christoph Hellwig,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Miller,
linux-kernel, netdev
In-Reply-To: <20110730093025.716f3f50-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
On Sat, Jul 30, 2011 at 09:30:25AM +1000, NeilBrown wrote:
> On Sat, 30 Jul 2011 06:34:44 +1000 Greg Banks <gnb-97jfqw80gc6171pxa8y+qA@public.gmane.org> wrote:
> > The "killall nfsd" semantics in those scripts are awful and lead to
> > problems shutting down when there are lots of threads. It would
> > probably be an improvement to provide a better shutdown mechanism and
> > force distros to use it.
>
> rpc.nfsd 0
>
> will stop all nfsd threads. Follow with
>
> exportfs -f
>
> and you should be done. I'm not 100% sure about the nfsv4 thread though -
> would need to check.
>
> And yes - I would love it if distros could standardise on start/stop scripts
> so upstreams could maintain them sensibly. This is my personal number 1
> reason for liking systemd - it pushes for this standardisation.
I can't remember if this is getting fixed in Fedora--probably not. We
should fix it.
I'd also be fine with logging a deprecation message when someone signals
an nfsd thread.
> > Or, you could preserve the effective semantics by having a single
> > "nfsd" thread whose purpose is to notice that it's being signalled and
> > perform a clean shutdown (perhaps blocking the thread doing the kill()
> > call until the shutdown has completed).
>
> That's kinda neat. It would be an ugly wart to have to keep around, but
> sometimes that the price we pay for "no regressions".
Yep; patch welcomed.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv6: updates to privacy addresses per RFC 4941.
From: David Miller @ 2011-08-02 1:05 UTC (permalink / raw)
To: lorenzo; +Cc: netdev, yoshfuji, jpa
In-Reply-To: <20110726235049.6D52516A59B@drone1.mtv.corp.google.com>
From: lorenzo@google.com (Lorenzo Colitti)
Date: Tue, 26 Jul 2011 16:50:49 -0700 (PDT)
> Update the code to handle some of the differences between
> RFC 3041 and RFC 4941, which obsoletes it. Also a couple
> of janitorial fixes.
>
> - Allow router advertisements to increase the lifetime of
> temporary addresses. This was not allowed by RFC 3041,
> but is specified by RFC 4941. It is useful when RA
> lifetimes are lower than TEMP_{VALID,PREFERRED}_LIFETIME:
> in this case, the previous code would delete or deprecate
> addresses prematurely.
>
> - Change the default of MAX_RETRY to 3 per RFC 4941.
>
> - Add a comment to clarify that the preferred and valid
> lifetimes in inet6_ifaddr are relative to the timestamp.
>
> - Shorten lines to 80 characters in a couple of places.
>
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Queued up for net-next, thanks!
^ permalink raw reply
* Re: [PATCH] net: add kerneldoc to skb_copy_bits()
From: David Miller @ 2011-08-02 1:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1312000651.2873.30.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 30 Jul 2011 06:37:31 +0200
> Since skb_copy_bits() is called from assembly, add a fat comment to make
> clear we should think twice before changing its prototype.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] net/smsc911x: add device tree probe support
From: David Miller @ 2011-08-02 1:01 UTC (permalink / raw)
To: shawn.guo
Cc: patches, netdev, devicetree-discuss, grant.likely,
steve.glendinning, linux-arm-kernel
In-Reply-To: <1312050360-15767-1-git-send-email-shawn.guo@linaro.org>
From: Shawn Guo <shawn.guo@linaro.org>
Date: Sun, 31 Jul 2011 02:26:00 +0800
> It adds device tree probe support for smsc911x driver.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Steve Glendinning <steve.glendinning@smsc.com>
> Cc: David S. Miller <davem@davemloft.net>
> Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Queued up for net-next, thanks.
^ 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