Re: [PATCH 1/6][SCTP]: Limit association max_retrans setting in setsockopt
From: Sridhar Samudrala [EMAIL PROTECTED] Date: Thu, 15 Jun 2006 15:46:12 -0700 Please apply the following 6 SCTP patches to 2.6 tree. Sridhar, I missed the 2.6.17 release but I will be sure to queue these up for the first 2.6.17.x stable release. Sorry about that. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 1/1] AF_UNIX Datagram getpeersec (with minor fix)
Hi,
I added one file (include/linux/selinux.h) which was omitted from the
previous patch, and removed a couple of unnecessary changes.
Again, comments are welcome!
thanks,
Catherine
--
From: [EMAIL PROTECTED]
This patch implements an API whereby an application can determine the
label of its peer's Unix datagram sockets via the auxiliary data mechanism of
recvmsg.
Patch purpose:
This patch enables a security-aware application to retrieve the
security context of the peer of a Unix datagram socket. The application
can then use this security context to determine the security context for
processing on behalf of the peer who sent the packet.
Patch design and implementation:
The design and implementation is very similar to the UDP case for INET
sockets. Basically we build upon the existing Unix domain socket API for
retrieving user credentials. Linux offers the API for obtaining user
credentials via ancillary messages (i.e., out of band/control messages
that are bundled together with a normal message). To retrieve the security
context, the application first indicates to the kernel such desire by
setting the SO_PASSSEC option via getsockopt. Then the application
retrieves the security context using the auxiliary data mechanism.
An example server application for Unix datagram socket should look like this:
toggle = 1;
toggle_len = sizeof(toggle);
setsockopt(sockfd, SOL_SOCKET, SO_PASSSEC, toggle, toggle_len);
recvmsg(sockfd, msg_hdr, 0);
if (msg_hdr.msg_controllen sizeof(struct cmsghdr)) {
cmsg_hdr = CMSG_FIRSTHDR(msg_hdr);
if (cmsg_hdr-cmsg_len = CMSG_LEN(sizeof(scontext))
cmsg_hdr-cmsg_level == SOL_SOCKET
cmsg_hdr-cmsg_type == SCM_SECURITY) {
memcpy(scontext, CMSG_DATA(cmsg_hdr), sizeof(scontext));
}
}
sock_setsockopt is enhanced with a new socket option SOCK_PASSSEC to allow
a server socket to receive security context of the peer.
Testing:
We have tested the patch by setting up Unix datagram client and server
applications. We verified that the server can retrieve the security context
using the auxiliary data mechanism of recvmsg.
---
include/asm-alpha/socket.h |1 +
include/asm-arm/socket.h |1 +
include/asm-arm26/socket.h |1 +
include/asm-cris/socket.h|1 +
include/asm-frv/socket.h |1 +
include/asm-h8300/socket.h |1 +
include/asm-i386/socket.h|1 +
include/asm-ia64/socket.h|1 +
include/asm-m32r/socket.h|1 +
include/asm-m68k/socket.h|1 +
include/asm-mips/socket.h|1 +
include/asm-parisc/socket.h |1 +
include/asm-powerpc/socket.h |1 +
include/asm-s390/socket.h|1 +
include/asm-sh/socket.h |1 +
include/asm-sparc/socket.h |1 +
include/asm-sparc64/socket.h |1 +
include/asm-v850/socket.h|1 +
include/asm-x86_64/socket.h |1 +
include/asm-xtensa/socket.h |1 +
include/linux/net.h |1 +
include/linux/selinux.h | 15 +++
include/net/af_unix.h|2 ++
include/net/scm.h| 14 ++
net/core/sock.c | 11 +++
net/unix/af_unix.c |2 ++
security/selinux/exports.c | 11 +++
27 files changed, 76 insertions(+)
diff -puN include/asm-i386/socket.h~lsm-secpeer-unix include/asm-i386/socket.h
--- linux-2.6.17-rc6-mm2/include/asm-i386/socket.h~lsm-secpeer-unix
2006-06-12 17:56:06.0 -0400
+++ linux-2.6.17-rc6-mm2-cxzhang/include/asm-i386/socket.h 2006-06-13
15:45:34.0 -0400
@@ -48,5 +48,6 @@
#define SO_ACCEPTCONN 30
#define SO_PEERSEC 31
+#define SO_PASSSEC 34
#endif /* _ASM_SOCKET_H */
diff -puN include/asm-x86_64/socket.h~lsm-secpeer-unix
include/asm-x86_64/socket.h
--- linux-2.6.17-rc6-mm2/include/asm-x86_64/socket.h~lsm-secpeer-unix
2006-06-12 17:56:06.0 -0400
+++ linux-2.6.17-rc6-mm2-cxzhang/include/asm-x86_64/socket.h2006-06-13
15:45:34.0 -0400
@@ -48,5 +48,6 @@
#define SO_ACCEPTCONN 30
#define SO_PEERSEC 31
+#define SO_PASSSEC 34
#endif /* _ASM_SOCKET_H */
diff -puN include/asm-ia64/socket.h~lsm-secpeer-unix include/asm-ia64/socket.h
--- linux-2.6.17-rc6-mm2/include/asm-ia64/socket.h~lsm-secpeer-unix
2006-06-12 17:56:06.0 -0400
+++ linux-2.6.17-rc6-mm2-cxzhang/include/asm-ia64/socket.h 2006-06-13
15:45:34.0 -0400
@@ -57,5 +57,6 @@
#define SO_ACCEPTCONN 30
#define SO_PEERSEC 31
+#define SO_PASSSEC 34
#endif /* _ASM_IA64_SOCKET_H */
diff -puN include/asm-powerpc/socket.h~lsm-secpeer-unix
include/asm-powerpc/socket.h
--- linux-2.6.17-rc6-mm2/include/asm-powerpc/socket.h~lsm-secpeer-unix
2006-06-12 17:56:06.0 -0400
+++ linux-2.6.17-rc6-mm2-cxzhang/include/asm-powerpc/socket.h 2006-06-13
15:45:34.0 -0400
@@ -55,5 +55,6 @@
#define SO_ACCEPTCONN 30
#define SO_PEERSEC
Re: [Patch 1/1] AF_UNIX Datagram getpeersec (with minor fix)
On Sun, 18 Jun 2006, Catherine Zhang wrote:
Patch purpose:
This patch enables a security-aware application to retrieve the
security context of the peer of a Unix datagram socket. The application
can then use this security context to determine the security context for
processing on behalf of the peer who sent the packet.
I'd also mention here that this is to complement the SO_PEERSEC option for
stream sockets.
There's an implementation issue, which I'm sure has been mentioned
previously. This code should not be calling SELinux API functions.
@@ -62,6 +70,12 @@ static __inline__ void scm_recv(struct s
if (test_bit(SOCK_PASSCRED, sock-flags))
put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm-creds),
scm-creds);
+ if (test_bit(SOCK_PASSSEC, sock-flags)) {
+ err = selinux_ctxid_to_string(scm-sid, scontext,
scontext_len);
The above is SELinux-specific code sitting in core networking code.
Look at the peersec stuff, it calls out to LSM hooks:
socket_getpeersec_stream
socket_getpeersec_dgram
These are the abstractions to be used for this in the core kernel, and the
SELinux code can then figure out specifically what to do based on the
protocol. Have a look at selinux_socket_getpeersec_stream() and see how
it behaves based on the protocol, to get an idea of the changes needed for
_dgram().
This needs to be reworked.
Look at ip_cmsg_recv_security() to see how this is done cleanly via an LSM
hook, without modifying core networking structures.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: enable shared key authentication
On Sunday 18 June 2006 05:01, Dan Williams wrote: On Fri, 2006-06-16 at 20:50 +0100, Daniel Drake wrote: I recently patched softmac to enable shared key authentication. This small patch will enable crazy or unfortunate bcm43xx users to use this new capability. Meaning that _until now_, softmac couldn't do Shared Key auth??? Yep. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recommend a network card
From: Michael Buesch [EMAIL PROTECTED] To: bastard operater [EMAIL PROTECTED] CC: netdev@vger.kernel.org Subject: Re: recommend a network card Date: Sat, 17 Jun 2006 23:23:01 +0200 On Saturday 17 June 2006 23:12, bastard operater wrote: People on this list like Real Names and are more motivated to help, if they know your name. I forgot to change that. I will change it as soon as I send this email. My name is Jason. My 3Com 3C905B-TX is starting to malfunction and it is getting worse. So I I never had a malfunctioning NIC. What does it look like? Broken packages? It loses its network connection (the systems says the card is unplugged) for a second or two and then the connection comes back. Sometimes the connection just stops working and I have to restart the network service. I am in the market for a new NIC. The card has to work on Linux (natively) and windows. I thought I would ask the experts if you have any recommendations for a good 100MB PCI card? I have mostly RTL based cards (ranging from 10 to 1000 mbit). No problems so far. (But also no problem with my 3c905 since quite some time ;) ) How can I tell which cards use which chipset? Thanks, Jason - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recommend a network card
On Sunday 18 June 2006 17:28, bastard operater wrote: I never had a malfunctioning NIC. What does it look like? Broken packages? It loses its network connection (the systems says the card is unplugged) for a second or two and then the connection comes back. Sometimes the connection just stops working and I have to restart the network service. uh, oh. Interresting. Sure it is not a software bug in PCI hotplug or something? (or something accidentally poking with fakephp) I would test the card in another machine, before throwing it away. I am in the market for a new NIC. The card has to work on Linux (natively) and windows. I thought I would ask the experts if you have any recommendations for a good 100MB PCI card? I have mostly RTL based cards (ranging from 10 to 1000 mbit). No problems so far. (But also no problem with my 3c905 since quite some time ;) ) How can I tell which cards use which chipset? Look at the chip ;) One of my cards (100mbit) has a chip with the string RTL8139D printed on it. There's usually only one or two chips on the card. You can't miss it. It's the chip, which is connected directly to the PCI pins. btw: This is not really the right list to ask such questions, as it is not development related, but well... :) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recommend a network card
From: Michael Buesch [EMAIL PROTECTED] To: bastard operater [EMAIL PROTECTED] CC: netdev@vger.kernel.org Subject: Re: recommend a network card Date: Sun, 18 Jun 2006 17:48:55 +0200 On Sunday 18 June 2006 17:28, bastard operater wrote: I never had a malfunctioning NIC. What does it look like? Broken packages? It loses its network connection (the systems says the card is unplugged) for a second or two and then the connection comes back. Sometimes the connection just stops working and I have to restart the network service. uh, oh. Interresting. Sure it is not a software bug in PCI hotplug or something? (or something accidentally poking with fakephp) It worked great for the first 6 years. Only in the last year has it become unstable. There have been no driver changes since 2001. My motherboard (7 years old, tyan tiger S1832D) does not support hotplug. I moved it to another PC and it still has problems. I would test the card in another machine, before throwing it away. I am in the market for a new NIC. The card has to work on Linux (natively) and windows. I thought I would ask the experts if you have any recommendations for a good 100MB PCI card? I have mostly RTL based cards (ranging from 10 to 1000 mbit). No problems so far. (But also no problem with my 3c905 since quite some time ;) ) How can I tell which cards use which chipset? Look at the chip ;) One of my cards (100mbit) has a chip with the string RTL8139D printed on it. There's usually only one or two chips on the card. You can't miss it. It's the chip, which is connected directly to the PCI pins. I don't have x-ray vision so I can't see through cardboard. :) Can you recommand a specific card or groups of cards? btw: This is not really the right list to ask such questions, as it is not development related, but well... :) Yeah, I know. I wanted to ask the experts. I don't want to buy a cheap network card only to get it home and find it uses 75% of CPU during transfers. Or even worse it is not supported by Linux. If you know of a linux certified hardware list I would love to hear about it. Thanks, Jason - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH,RESEND] smc91x: support for logicpd pxa270 platform
This patch adds support for the smc91x on the LogicPD PXA270 to the smc91x driver. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] -- This patch was previously submitted on March 28, but doesn't seem to have made it into 2.6.17. Index: linux-2.6.17/drivers/net/smc91x.h === --- linux-2.6.17.orig/drivers/net/smc91x.h +++ linux-2.6.17/drivers/net/smc91x.h @@ -129,6 +129,19 @@ #define SMC_insb(a, r, p, l) readsb((a) + (r), p, (l)) #define SMC_outsb(a, r, p, l) writesb((a) + (r), p, (l)) +#elif defined(CONFIG_MACH_LOGICPD_PXA270) + +#define SMC_CAN_USE_8BIT 0 +#define SMC_CAN_USE_16BIT 1 +#define SMC_CAN_USE_32BIT 0 +#define SMC_IO_SHIFT 0 +#define SMC_NOWAIT 1 + +#define SMC_inw(a, r) readw((a) + (r)) +#define SMC_outw(v, a, r) writew(v, (a) + (r)) +#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l) +#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l) + #elif defined(CONFIG_ARCH_INNOKOM) || \ defined(CONFIG_MACH_MAINSTONE) || \ defined(CONFIG_ARCH_PXA_IDP) || \ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Hi, sorry for the delayed response... On 13/06/06 00:29, Francois Romieu wrote: wget goes faster, right ? Do you have some vmstat 1 output at hand for it ? It does indeed go faster, and it seems a little bit more reliable, but with big enough transfers it locks up too. See commandline-2.txt and vmstat-2.txt - it gets through around 600-700MB before locking up. I also noticed that at 3-4 points during the transfer it seemed to pause, and then continue. Ok but can you set correctly the link with the command which was told to fail in you first mail ? The patch could fix it. Yes, indeed: doing ethtool -s eth0 speed 10 autoneg off switches it to the slow speed, and keeps it there too (at 10Mb/s). ethtool eth0 still reports Advertised auto-negotiation: Yes and Auto-negotiation: on, which is probably not right. It also reports Advertised link modes: 10baseT/Full only, which is probably correct. It only actually restarts auto-negotiation when I issue the command ethtool -s eth0 autoneg on, at which point the speeds goes back up to 1000Mb/s - the expected behaviour. So it seems ethtool works better than before wrt auto-negotiation. Can you try something like: dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin Well this transfer (from shuttle - hell) completed successfully. See commandline-3.txt and vmstat-3.txt; However I noticed the speed was only around 7 MB/s and wondered if the link speed was maybe set to 100Mb/s, so I immediately afterwards did a wget-test again, which locked up after only 5%. The wget test however did confirm the link speed to be 1000Mb/s. See commandline-4.txt and vmstat-4.txt for that last, short test. May I assume that the freeze locks everything (keyboard, mouse, led) beyond the scp command itself ? Yes indeed. My (usb) keyboard doesn't respond at all anymore, networking is completely out, (usb) mouse freezes too. SysRq doesn't seem to help much either. -- Mourad shuttle:~# wget http://hell/testfile.bin --18:39:21-- http://hell/testfile.bin = `testfile.bin' Resolving hell... 10.10.1.1 Connecting to hell|10.10.1.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,073,741,824 (1.0G) [application/octet-stream] 56% [ ] 602,018,040 27.70M/sETA 00:17 shuttle:~# dd if=/dev/zero bs=1024k count=1000 | ssh -c blowfish hell dd of=/tmp/1000m.bin Password: 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 155.971 seconds, 6.7 MB/s 2047951+99 records in 2048000+0 records out 1048576000 bytes (1.0 GB) copied, 140.689 seconds, 7.5 MB/s shuttle:~# shuttle:~# wget http://hell/testfile.bin --18:57:26-- http://hell/testfile.bin = `testfile.bin' Resolving hell... 10.10.1.1 Connecting to hell|10.10.1.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,073,741,824 (1.0G) [application/octet-stream] 5% [] 57,266,17630.30M/s shuttle:~# vmstat 1 procs ---memory-- ---swap-- -io --system-- cpu r b swpd free buff cache si sobibo incs us sy id wa 0 0 0 983108 4672 29140003311 45264 1 6 92 1 0 0 0 983108 4672 2914000 0 0 45818 0 2 98 0 0 0 0 982556 4688 2958800 464 0 49265 1 2 90 7 0 0 0 981316 4692 3072000 0 0 2029 162 0 2 98 0 0 0 0 951804 4724 5932400 0 0 38927 3128 1 42 57 0 0 1 0 911380 4764 9652800 4 66940 50360 10405 3 63 33 1 0 1 0 875916 4796 13171600 0 0 41138 4251 5 69 0 26 1 1 0 842684 4828 16480400 0 0 38724 4368 3 66 0 31 1 1 0 807468 4872 19929600 0 204 43170 4254 4 59 9 28 1 0 0 772748 4908 23277200 4 32516 39246 4071 3 67 22 8 0 2 0 737656 4940 26625600 0 97720 38868 4612 4 66 30 0 0 2 0 737532 4940 26625600 0 32768 66323 0 5 0 95 0 2 0 738772 4940 26625600 0 6724 55119 0 3 0 97 1 1 0 718436 4972 28860800 0 196 26291 2494 3 47 1 49 0 0 0 676276 5012 32910800 0 0 54791 4380 3 59 2 36 0 2 0 639944 5048 36237600 4 81856 44893 7185 2 54 9 35 0 2 0 640564 5048 36237600 0 14268 61819 0 2 0 98 0 2 0 641928 5048 36237600 024 55318 0 2 0 98 0 1 0 608944 5088 39601600 0 128 45004 9135 4 52 6 38 0 1 0 571868 5124 43154400 0 0 47833 9603 2 59 12 27 1 1 0 529212 5160 47110400 0 84548 52399 4222 2 61 5 32 1 3 0 493500 5200 50649200 4 16384 40790 4236 6 74 0 20 0 3 0 459276 5232 54068400
Re: [RFC] [patch 0/6] [Network namespace] introduction
On Fri, Jun 09, 2006 at 11:02:02PM +0200, [EMAIL PROTECTED] wrote: What is missing ? - The routes are not yet isolated, that implies: - binding to another container's address is allowed - an outgoing packet which has an unset source address can potentially get another container's address - an incoming packet can be routed to the wrong container if there are several containers listening to the same addr:port - renaming an interface in one namespace affects everyone. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [patch 2/6] [Network namespace] Network device sharing by view
On Fri, Jun 09, 2006 at 11:02:04PM +0200, [EMAIL PROTECTED] wrote:
+ read_lock(dev_base_lock);
+
+ for (dev = dev_base; dev; dev = dev-next)
+ if (!strncmp(dev-name, devname, IFNAMSIZ))
+ break;
+
+ if (!dev) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ db = kmalloc(sizeof(*db), GFP_KERNEL);
deadlock.
Besides, holding references to net_device from userland is Not Good(tm).
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [patch 3/6] [Network namespace] Network devices isolation
On Fri, Jun 09, 2006 at 11:02:05PM +0200, [EMAIL PROTECTED] wrote:
struct net_device *dev_get_by_name(const char *name)
{
+ struct net_ns_dev_list *dev_list = (net_ns()-dev_list);
struct net_device *dev;
- read_lock(dev_base_lock);
+ read_lock(dev_list-lock);
dev = __dev_get_by_name(name);
if (dev)
dev_hold(dev);
- read_unlock(dev_base_lock);
+ read_unlock(dev_list-lock);
return dev;
And what would stop renames done via different lists from creating a
conflict? Incidentally, WTF protects the device name while we are
doing that lookup?
While we are at it, what are you going to do with sysfs?
ls /sys/class/net and watch the fun...
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
Stephen Hemminger wrote: Does this fix it? # sysctl -w net.ipv4.tcp_abc=0 Thanks for the suggestion. I will give it a try later tonight. Also Andrew - sorry for the incorrect placement of my follow-up comments. I do appreciate everyone's help in figuring this out. -- Dr. Harry EdmonE-MAIL: [EMAIL PROTECTED] 206-543-0547 [EMAIL PROTECTED] Dept of Atmospheric Sciences FAX:206-543-0308 University of Washington, Box 351640, Seattle, WA 98195-1640 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
System hangs after running 2.6.17rc6 with broadcom 4309 and device scape stack
After running 2.6.17rc6 with device scape stack (git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git) for a few hours, my system hangs. Here is the last thing I see in my logs: [4323255.189000] NETDEV WATCHDOG: wmaster0: transmit timed out [4323255.189000] wmaster0: resetting interface. [4323255.189000] bcm43xx_d80211: Controller RESET (IEEE reset) ... [4323255.191000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() [4323255.192000] ACPI: PCI interrupt for device :02:03.0 disabled [4323255.192000] ACPI: PCI Interrupt :02:03.0[A] - Link [LNKB] - GSI 7 (level, low) - IRQ 7 [4323255.198000] bcm43xx_d80211: Chip ID 0x4306, rev 0x3 [4323255.198000] bcm43xx_d80211: Number of cores: 5 [4323255.198000] bcm43xx_d80211: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled [4323255.198000] bcm43xx_d80211: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled [4323255.198000] bcm43xx_d80211: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled [4323255.198000] bcm43xx_d80211: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled [4323255.198000] bcm43xx_d80211: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled [4323255.201000] bcm43xx_d80211: PHY connected [4323255.201000] bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2 [4323255.201000] bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) [4323255.201000] bcm43xx_d80211: Radio turned off [4323255.201000] bcm43xx_d80211: Radio turned off [4323255.201000] bcm43xx_d80211: Controller restarted This has happened daily during the two days I've been running this version. My log also has lots of these messages: 4322054.949000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() [4322054.95] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2173:bcm43xx_mac_enable() [4322114.953000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() [4322114.97] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2173:bcm43xx_mac_enable() [4322174.973000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() [4322174.974000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2173:bcm43xx_mac_enable() [4322234.977000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() [4322234.994000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2173:bcm43xx_mac_enable() [4322294.997000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() The system hangs so hard not even alt-sysrq can wake it up. This problem did not occur in the 2.6.17r4 or rc5 versions of the dscape stack. System is a Dell Latitude D600 laptop. #lsmod rate_control5312 0 bcm43xx_d80211451456 0 80211 181512 2 rate_control,bcm43xx_d80211 snd_pcm_oss43680 0 snd_mixer_oss 18688 1 snd_pcm_oss ohci_hcd 21060 0 usbhid 41184 0 intel_agp 22044 1 uhci_hcd 23628 0 generic 4356 0 [permanent] snd_intel8x0 32028 0 snd_ac97_codec101408 1 snd_intel8x0 snd_ac97_bus2240 1 snd_ac97_codec snd_pcm89668 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 23172 1 snd_pcm snd52004 6 snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer soundcore 8160 1 snd snd_page_alloc 8904 2 snd_intel8x0,snd_pcm 8250_pci 20352 0 8250 26996 1 8250_pci serial_core19904 1 8250 tg3 114692 0 yenta_socket 26636 4 rsrc_nonstatic 12992 1 yenta_socket pcmcia 35116 0 firmware_class 8768 2 bcm43xx_d80211,pcmcia crc32 4096 1 pcmcia pcmcia_core40544 3 yenta_socket,rsrc_nonstatic,pcmcia nls_iso8859_1 4032 1 ntfs 107828 1 usbkbd 6784 0 usbmouse4992 0 agpgart32236 1 intel_agp usb_storage35972 2 sd_mod 18496 3 scsi_mod 131624 2 usb_storage,sd_mod ehci_hcd 31624 0 #lspci 02:03.0 Network controller: Broadcom Corporation BCM4309 802.11a/b/g (rev 03) relevant part of .config: CONFIG_BCM43XX_D80211=m
Re: System hangs after running 2.6.17rc6 with broadcom 4309 and device scape stack
--- Alex Davis [EMAIL PROTECTED] wrote: After running 2.6.17rc6 with device scape stack (git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git) for a few hours, my system hangs. Here is the last thing I see in my logs: [4323255.189000] NETDEV WATCHDOG: wmaster0: transmit timed out [4323255.189000] wmaster0: resetting interface. [4323255.189000] bcm43xx_d80211: Controller RESET (IEEE reset) ... [4323255.191000] bcm43xx_d80211: ASSERTION FAILED (bcm-mac_suspended = 0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:2191:bcm43xx_mac_suspend() [4323255.192000] ACPI: PCI interrupt for device :02:03.0 disabled [4323255.192000] ACPI: PCI Interrupt :02:03.0[A] - Link [LNKB] - GSI 7 (level, low) - IRQ 7 [4323255.198000] bcm43xx_d80211: Chip ID 0x4306, rev 0x3 [4323255.198000] bcm43xx_d80211: Number of cores: 5 [4323255.198000] bcm43xx_d80211: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled [4323255.198000] bcm43xx_d80211: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled [4323255.198000] bcm43xx_d80211: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled [4323255.198000] bcm43xx_d80211: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled [4323255.198000] bcm43xx_d80211: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled [4323255.201000] bcm43xx_d80211: PHY connected [4323255.201000] bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2 [4323255.201000] bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) [4323255.201000] bcm43xx_d80211: Radio turned off [4323255.201000] bcm43xx_d80211: Radio turned off [4323255.201000] bcm43xx_d80211: Controller restarted This has happened daily during the two days I've been running this version. [snip] Some more info: Here is dmesg output for module loading. Jun 16 20:04:06 siafu kernel: [4294720.383000] bcm43xx_d80211 driver Jun 16 20:04:06 siafu kernel: [4294720.393000] ACPI: PCI Interrupt :02:03.0[A] - Link [LNKB] - GSI 7 (level, low) - IRQ 7 Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Chip ID 0x4306, rev 0x3 Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Number of cores: 5 Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled Jun 16 20:04:06 siafu kernel: [4294720.393000] bcm43xx_d80211: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled Jun 16 20:04:06 siafu kernel: [4294720.396000] bcm43xx_d80211: PHY connected Jun 16 20:04:06 siafu kernel: [4294720.396000] bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2 Jun 16 20:04:06 siafu kernel: [4294720.396000] bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) Jun 16 20:04:06 siafu kernel: [4294720.396000] bcm43xx_d80211: Radio turned off Jun 16 20:04:06 siafu kernel: [4294720.396000] bcm43xx_d80211: Radio turned off Jun 16 20:04:06 siafu kernel: [4294720.464000] wmaster0: Selected rate control algorithm 'simple' Jun 16 20:04:06 siafu kernel: [4294720.505000] bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00:90:96:ba:32:20) Jun 16 20:04:06 siafu kernel: [4294720.511000] bcm43xx_d80211: PHY connected Jun 16 20:04:07 siafu kernel: [4294720.779000] bcm43xx_d80211: Radio turned on Jun 16 20:04:07 siafu kernel: [4294720.971000] bcm43xx_d80211: Chip initialized Jun 16 20:04:07 siafu kernel: [4294720.972000] bcm43xx_d80211: DMA initialized Jun 16 20:04:07 siafu kernel: [4294720.972000] bcm43xx_d80211: 80211 cores initialized Jun 16 20:04:07 siafu kernel: [4294720.972000] bcm43xx_d80211: Keys cleared Jun 16 20:04:07 siafu kernel: [4294720.988000] wmaster0: Does not support passive scan, disabled Jun 16 20:04:09 siafu kernel: [4294723.027000] bcm43xx_d80211: ASSERTION FAILED (bcm-interface.if_id == if_id) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:4344:bcm43xx_config_interface() Here is dmesg output while wpa_supplicant is starting: Jun 16 20:04:14 siafu kernel: [4294728.406000] wlan0: starting scan Jun 16 20:04:14 siafu kernel: [4294728.407000] HW CONFIG: channel=1 freq=2412 phymode=3 Jun 16 20:04:14 siafu kernel: [4294728.475000] HW CONFIG: channel=2 freq=2417 phymode=3 Jun 16 20:04:14 siafu kernel: [4294728.543000] HW CONFIG: channel=3 freq=2422 phymode=3 Jun 16 20:04:14 siafu kernel: [4294728.611000] HW CONFIG: channel=4 freq=2427 phymode=3 Jun 16 20:04:14 siafu kernel: [4294728.679000] HW CONFIG: channel=5 freq=2432 phymode=3 Jun 16 20:04:14 siafu kernel: [4294728.747000] HW CONFIG: channel=6 freq=2437 phymode=3 Jun 16 20:04:15 siafu kernel: [4294728.815000] HW CONFIG: channel=7 freq=2442 phymode=3 Jun 16
Re: [PATCH] Right prototype of __raw_v4_lookup()
On Wed, Jun 07, 2006 at 03:38:39PM +0400, Alexey Dobriyan wrote: I think, yes. Al Viro is sitting on terabytes of endian annotations in networking code. See net-endian.b* branches at git://git.kernel.org/pub/scm/linux/kernel/git/viro/bird.git I don't know if he considers them ready. I do not. I _am_ going to finish that in this cycle, though; this stuff got stalled on some sparse modifications needed to teach the sucker how to deal with the next biggest bunch of annotation problems. Need to sort that out first; I do know how to deal with that mess, just need to find time and do so. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/1] connector: export cn_already_initialized.
On Tue, May 16, 2006 at 04:14:06PM -0700, David S. Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 6 May 2006 12:40:45 +0400
Some external patches, which can be built both as static build and as
module just check that value, and thus will fail with unresolved symbol
when cn and module are built as modules.
The right set of operations should be following:
If external module is loaded and cn is not loaded or compiled into the
kernel, insmod will just fail with unresolved symbol (cn_add_callback and
others),
if cn is already loaded or was built into the tree, then it has been
initialized already and there is no need to check that value, external
module should be just loaded.
I think the right solution is to call external init functions after cn
init function, but it's ordering is not always known.
In-kernel build of connector subsystem can be handled by
making cn_init a subsystem_init(), it will then be setup
before any possible static or modular reference as long as
those modules use module_init().
For modular case of connector, dependency of module on connector
module should handle all ordering issues, making any ordering
issue take care of itself.
Attached patch declares connector init function as subsys_init()
and returns -EAGAIN in case connector is not initialized yet.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/drivers/connector/connector.c b/drivers/connector/connector.c
index 505677f..d1d964f 100644
--- a/drivers/connector/connector.c
+++ b/drivers/connector/connector.c
@@ -306,6 +306,9 @@ int cn_add_callback(struct cb_id *id, ch
int err;
struct cn_dev *dev = cdev;
+ if (!cn_already_initialized)
+ return -EAGAIN;
+
err = cn_queue_add_callback(dev-cbdev, name, id, callback);
if (err)
return err;
@@ -433,7 +436,7 @@ static void cn_callback(void *data)
up(notify_lock);
}
-static int __init cn_init(void)
+static int __devinit cn_init(void)
{
struct cn_dev *dev = cdev;
int err;
@@ -454,21 +458,22 @@ static int __init cn_init(void)
sock_release(dev-nls-sk_socket);
return -EINVAL;
}
+
+ cn_already_initialized = 1;
err = cn_add_callback(dev-id, connector, cn_callback);
if (err) {
+ cn_already_initialized = 0;
cn_queue_free_dev(dev-cbdev);
if (dev-nls-sk_socket)
sock_release(dev-nls-sk_socket);
return -EINVAL;
}
- cn_already_initialized = 1;
-
return 0;
}
-static void __exit cn_fini(void)
+static void __devexit cn_fini(void)
{
struct cn_dev *dev = cdev;
@@ -480,7 +485,7 @@ static void __exit cn_fini(void)
sock_release(dev-nls-sk_socket);
}
-module_init(cn_init);
+subsys_initcall(cn_init);
module_exit(cn_fini);
EXPORT_SYMBOL_GPL(cn_add_callback);
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
