Re: [RFC] SECMARK 1.1
James Morris wrote: On Mon, 15 May 2006, Patrick McHardy wrote: This will load the conntrack modules even if the track flag is not set. I guess need_conntrack() could be moved to checkentry() and only called if the track flag is set. That won't help, the function itself does nothing, its just a symbol dependency. Not sure what you mean: it will cause ip_conntrack to be loaded, which is needed when you specify the track flag. Yes, but the reason why it is loaded is because the module loader needs to resolve the symbol, not because of anything done at module runtime. - 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
ipv6 routing broken in 2.6.17-rc3,4
On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to 6to4 tunnel (the default route). It worked with fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel). Example (I add an unreachable route to an ipv6 address to force going there by ipv4 and it still uses the route): vaarikas:~# ip -6 route add unreachable 2001:7a8:1:5::14 vaarikas:~# ping6 2001:7a8:1:5::14 PING 2001:7a8:1:5::14(2001:7a8:1:5::14) 56 data bytes 64 bytes from 2001:7a8:1:5::14: icmp_seq=1 ttl=55 time=56.7 ms 64 bytes from 2001:7a8:1:5::14: icmp_seq=2 ttl=55 time=55.5 ms --- 2001:7a8:1:5::14 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 55.573/56.155/56.738/0.628 ms vaarikas:~# ip -6 route ::/96 via :: dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 unreachable 2001:7a8:1:5::14 dev lo metric 1024 expires 21334221sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2002:5283:297e:2::/64 dev eth0 metric 256 expires 21332659sec mtu 1500 advmss 1440 hoplimit 4294967295 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21332650sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1 metric 256 expires 21332654sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth1 metric 256 expires 21332654sec mtu 1500 advmss 1440 hoplimit 4294967295 ff00::/8 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth0 metric 256 expires 21332650sec mtu 1500 advmss 1440 hoplimit 4294967295 unreachable default dev lo proto none metric -1 error -101 hoplimit 255 Additional example: nothing goes in the direction of eth0, the packets that should go there also go to tun6to4 interface as confirmed by tcpdump. I have a laptop on eth0 and when I tracepath6 some external address, I get this from tun4to4 device on the gw: vaarikas:~# tcpdump -n -s 1500 -vv -i tun6to4 tcpdump: WARNING: tun6to4: no IPv4 address assigned tcpdump: listening on tun6to4, link-type RAW (Raw IP), capture size 1500 bytes 09:14:08.053137 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10 09:14:09.050230 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10 09:14:10.091294 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, time exceeded in-transit, length 1240 for 2001:ad0::10 09:14:11.090985 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 09:14:12.090354 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 09:14:13.090373 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 09:14:14.091355 IP6 (hlim 64, next-header: ICMPv6 (58), length: 1240) 2002:5283:297e::42 2002:5283:297e:2:210:60ff:fe5a:d6f5: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 ... -- Meelis Roos ([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: [RFC] SECMARK 1.1
On Mon, 15 May 2006, Patrick McHardy wrote: Not sure what you mean: it will cause ip_conntrack to be loaded, which is needed when you specify the track flag. Yes, but the reason why it is loaded is because the module loader needs to resolve the symbol, not because of anything done at module runtime. Am I missing something? This is what I want to happen. If you specify SECMARK --track, ip_conntrack is to be loaded. -- 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: [RFC] SECMARK 1.1
James Morris wrote:
On Mon, 15 May 2006, Patrick McHardy wrote:
Not sure what you mean: it will cause ip_conntrack to be loaded, which
is needed when you specify the track flag.
Yes, but the reason why it is loaded is because the module loader needs
to resolve the symbol, not because of anything done at module runtime.
Am I missing something? This is what I want to happen. If you specify
SECMARK --track, ip_conntrack is to be loaded.
But if you don't specify --track, the module loader will still have to
resolve the symbol, so it gets loaded anyway, before your code will
even run. Just look at need_conntrack():
/* Some modules need us, but don't depend directly on any symbol.
They should call this. */
void need_conntrack(void)
{
}
-
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] SECMARK 1.1
On Mon, 15 May 2006, Patrick McHardy wrote: But if you don't specify --track, the module loader will still have to resolve the symbol, so it gets loaded anyway, before your code will even run. Just look at need_conntrack(): Doh. It should be try_module_get(). Sound ok? - 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: [RFC] SECMARK 1.1
On Mon, 15 May 2006, James Morris wrote: Doh. It should be try_module_get(). Sound ok? Of course, I mean request_module(). -- 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: [RFC] SECMARK 1.1
James Morris wrote: On Mon, 15 May 2006, Patrick McHardy wrote: But if you don't specify --track, the module loader will still have to resolve the symbol, so it gets loaded anyway, before your code will even run. Just look at need_conntrack(): Doh. It should be try_module_get(). Sound ok? try_module_get already needs a module reference, so this won't work either. As far as I can tell the only thing you can do besides putting it in a seperate module is to manually call request_module(). - 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 wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Fri, 12 May 2006 16:35:27 -0400, Michael Wu wrote: Hm, so why not add something that will tell you what modes are supported by the hardware? Sounds reasonable. Only problem with this patch is if the hardware adds any modes after registration, they will be disabled initially. Hopefully, no drivers will actually need to do that. bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't know allowed modes until it loads firmware. And the firmware is not loaded until the device is opened (they probably have a reason for this). This issue can be easily solved by not masking hw_modes by valid_hw_modes in ieee80211_ioctl_prism2_param and ieee80211_precalc_modes. Just check (hw_modes valid_hw_modes) instead of hw_modes in ieee80211_sta_scan_timer. And yes, hw_modes is a confusing name. It should be named hw_modes_mask_disabled_by_user or so. Maybe at least some better comment about this in ieee80211_i.h won't be a bad idea. Thanks, Jiri -- Jiri Benc SUSE Labs - 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 wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote: bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't know allowed modes until it loads firmware. And the firmware is not loaded until the device is opened (they probably have a reason for this). No, that's not right, the firmware has nothing to do with it. At least not that we know of, so we treat it as all doing the same :) johannes signature.asc Description: This is a digitally signed message part
[RFC] changing value of NETDEV_ALIGN to cacheline size
while digging through the alloc_netdev function I asked myself why there is a fixed alignment for netdevices. Is there a special reason for choosing 32? If yes, I suggest to add a comment to the definition. If not, I suspect cacheline alignment might be beneficial: struct net_device contains several variables which are cache aligned (poll_list, queue_lock .). As far as I can see, the compiler tries to increase the size of the structure to make that possible, but expects the whole structure to be aligned to cache line size as well. With the current value for NETDEV_ALIGN we dont align struct net_device to the cache line, instead we align it to 32 bytes. That means that poll_list, queue_lock and friends are not always cache aligned, but 32 bytes aligned. The only reason why everything worked so far is the slab allocator design, which gives us a page aligned struct net_device in most cases. I think we should not rely on the behaviour of the memory allocator and use a different value for NETDEV_ALIGN instead. Any comments or corrections? cheers Christian The patch below is compile and boot tested on s390 and x86. Signed-off-by: Christian Borntraeger [EMAIL PROTECTED] include/linux/netdevice.h |2 +- net/core/dev.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- --- a/include/linux/netdevice.h 4 Apr 2006 07:25:47 - +++ b/include/linux/netdevice.h 15 May 2006 11:06:05 - @@ -504,7 +504,7 @@ struct class_device class_dev; }; -#defineNETDEV_ALIGN32 +#defineNETDEV_ALIGNL1_CACHE_BYTES #defineNETDEV_ALIGN_CONST (NETDEV_ALIGN - 1) static inline void *netdev_priv(struct net_device *dev) --- a/net/core/dev.c4 Apr 2006 07:25:50 - +++ b/net/core/dev.c15 May 2006 11:06:05 - @@ -2986,7 +2986,7 @@ struct net_device *dev; int alloc_size; - /* ensure 32-byte alignment of both the device and private area */ + /* ensure cacheline alignment of both the device and private area */ alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) ~NETDEV_ALIGN_CONST; alloc_size += sizeof_priv + NETDEV_ALIGN_CONST; - 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] SECMARK 1.1
On Sun, 2006-05-14 at 02:03 -0400, James Morris wrote:
Included below is an incremental patch against the initial secmark posting
last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927
This posting to gather feedback on changes made since then primarily to
address concerns raised by Karl MacMillan on providing fine-grained
assurances for network applications which pass connections (e.g. xinetd).
If all looks ok, I'll rebase the entire patchset (also merging elements
from the patch below back into other patches), and submit it for inclusion
in 2.6.18. As it touches a bunch of networking code, it may be best to
aim for Dave's tree, although it could also go into -mm.
Anyway, the way the issue has been addressed is to implement something
similar to CONNMARK, but specific to this useage scenario and dealing with
security markings instead of network markings.
In a nutshell:
1. A --track option was added to the SECMARK target, which causes the
security mark being applied to the packet to also be applied to a new
secmark field on the conntrack (only if it is unmarked).
2. A new CONNSECMARK target was added which copies the secmark value to
packets.
This allows all packets on a connection (or related to it) to be marked
with the same security label, so that they can be explicitly
differentiated.
This also turns out to simplify the SELinux policy, while the xtables
implementation has been designed to remain as simple as possible (e.g. it
only copies lables to packets, and has no options).
So, here's an example of per-packet network policy for vsftpd with the new
code:
allow ftpd_t ftpd_packet_t:packet { recv send };
Assuming it doesn't do DNS lookups, that's it in terms of access control
rules for packets. This covers all established and related packets,
including ICMP and the FTP data connetion.
James,
This seems to address my concerns - thanks.
Karl
--
Karl MacMillan
Tresys Technology
www.tresys.com
-
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: SIOCSIWESSID + SIOCSIWAP behaviour
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. I don't think there is requirement for doing a new scan here if recent scan results are available. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. Same here. Neither of these commands should drop IEEE 802.11 authentication. I would say that neither should drop association either until a new association is available or it is clear that current configuration does not allow association to be created. First case would just report a new association (no disassociation reported) and second case would report disassociation to user space. Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, which causes softmac to associate twice, and that quickly confuses things. (I don't really understand why wpa_supplicant uses SIWAP when a BSSID isn't specified in the config file, but...) There are two different modes and what is being described here is ap_scan=1, i.e., wpa_supplicant being responsible for requesting scanning and selecting an AP. In this mode, it is actually assumed that the driver does not do extra scans with SIWAP or SIWESSID. wpa_supplicant is telling the driver which channel (SIOCSIWFREQ), SSID, and BSSID to use. In the other mode, ap_scan=2, wpa_supplicant is only configuring the SSID and requesting the driver (or well, kernel side 802.11 management code) to figure out which AP to use. -- Jouni MalinenPGP id EFC895FA - 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: Hardware button support for Wireless cards
On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote: Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Distributions will need to accommodate to the way d80211 stack works anyway, so I see no problem with this. B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Voting for this. It brings more flexibility. This is not a problem of your card only. Is there a standard ACPI rf-kill event? Jiri -- Jiri Benc SUSE Labs - 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 wireless-dev] d80211: Don't discriminate against 802.11b drivers
[removed some people from Cc: list as this is probably not much interesting for them] On Mon, 15 May 2006 14:04:44 +0200, Johannes Berg wrote: On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote: bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't know allowed modes until it loads firmware. And the firmware is not loaded until the device is opened (they probably have a reason for this). No, that's not right, the firmware has nothing to do with it. At least not that we know of, so we treat it as all doing the same :) Hm, so your calls to ieee80211_update_hw are probably unnecessary. Anyway, I'm still inclined towards not masking hw_modes by valid_hw_modes. Jiri -- Jiri Benc SUSE Labs - 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: Hardware button support for Wireless cards
On Monday 15 May 2006 15:25, Jiri Benc wrote: On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote: Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Distributions will need to accommodate to the way d80211 stack works anyway, so I see no problem with this. B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Voting for this. It brings more flexibility. This is not a problem of your card only. Is there a standard ACPI rf-kill event? Not sure actually. the approach rt2x00 takes is sending an event ACPI_TYPE_EVENT with as argument a 0 or 1 depending on the new state of the button. But I don't know if there is another event that would be more suitable for a hardware button. pgp49L2gsD2N8.pgp Description: PGP signature
Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Monday 15 May 2006 15:35, you wrote: [removed some people from Cc: list as this is probably not much interesting for them] On Mon, 15 May 2006 14:04:44 +0200, Johannes Berg wrote: On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote: bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't know allowed modes until it loads firmware. And the firmware is not loaded until the device is opened (they probably have a reason for this). No, that's not right, the firmware has nothing to do with it. At least not that we know of, so we treat it as all doing the same :) Hm, so your calls to ieee80211_update_hw are probably unnecessary. No, We must allocate the ieee80211_hw, before we can attach the board. But before we attached the board, we don't know what hardware it is. Sure, this can be worked around by some very ugly hack (It was done in an early version of the dscape port, because there was no ieee80211_update_hw), but I am not very happy to add the hack again. (I am not sure anymore _what_ we actually did to workaround it. I would have to look up the SVN repository ;) ) - 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: Hardware button support for Wireless cards
On Mon, 15 May 2006 22:57:12 +1000 Mark Wallis wrote: What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. Using ACPI events for this purpose seems wrong: - ACPI is not available on all architectures supported by Linux, therefore it cannot be an universal solution; - even if ACPI is available, it may be turned off for some reason. In fact, many people consider the separate /proc/acpi/event interface for ACPI events to be a mistake, and there is some movement to make ACPI use the input layer instead: http://lkml.org/lkml/2006/4/19/275 There is even a KEY_RADIO defined in linux/input.h (however, it was probably intended to be used for a remote control key, like TV/VCR/CD/Tape/... defined near it, so I'm not sure whether it would be the proper event to use here). pgpSYqPPUc94E.pgp Description: PGP signature
Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Mon, 15 May 2006 16:01:48 +0200, Michael Buesch wrote: No, We must allocate the ieee80211_hw, before we can attach the board. But before we attached the board, we don't know what hardware it is. Sure, this can be worked around by some very ugly hack (It was done in an early version of the dscape port, because there was no ieee80211_update_hw), but I am not very happy to add the hack again. (I am not sure anymore _what_ we actually did to workaround it. I would have to look up the SVN repository ;) ) Isn't it possible to do attaching of the board between ieee80211_alloc_hw and ieee80211_register_hw calls? You don't need to call ieee80211_update_hw then. Anyway, the ieee80211_update_hw function is here for a reason (solving issues with a firmware primarily, but not exclusively), so use it if it is easier for you. Jiri -- Jiri Benc SUSE Labs - 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, 2006-05-15 at 06:16 -0700, Jouni Malinen wrote: On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. I don't think there is requirement for doing a new scan here if recent scan results are available. Yeah, thought that was understood. No reason to do another scan if you just did one in the driver 5 seconds ago. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. Same here. Neither of these commands should drop IEEE 802.11 authentication. I would say that neither should drop association either until a new association is available or it is clear that current configuration does not allow association to be created. First case would I assume that by or it is clear that the current configuration does not allow association to be created means that the driver cannot find an AP matching both the ESSID and the BSSID the user set, right? If so, then quite correct, the driver shouldn't disassociate until it's certain that the current user-specified configuration (ie, any combination of ESSID and BSSID set) does not apply to any known access points in the scan list. It's perfectly legal to send a new SIWAP event with a different BSSID if the driver simply associates with a new access point in the same ESSID too. In this case, the driver does _not_ need to send a blank SIWAP disassoc event to userspace, since it's staying within the same ESSID. I think at this point I'm still still assuming that APs with the same ESSID are on the same network by default. Although that's not entirely valid, especially in the realm of consumer gear (multiple 'linksys' APs on the same channel even, each with different upstream connection), in this case the user space application will have to know to lock the BSSID of the card/driver to the one it wants. That's a user space issue, not a driver issue. Driver's shouldn't be too smart about this stuff without providing standard overrides. configuration does not allow association to be created. First case would just report a new association (no disassociation reported) and second case would report disassociation to user space. If no association has been completed yet before the user sets SIWESSID or SIWAP, then of course no disassociation event needs to get sent to userspace because there's been no association from which to disassociate. I believe the following sequence is correct: boot user app issues SIWESSID 'foo' driver finds associates/authenticates to 'foo' (if not available, it Just Does Nothing) (if available, sends SIWAP of 'whatever foo is' to userspace) user app issues SIWAP '12:34:56:78:91:23' driver sends SIWAP of 00:00:00:00:00:00 (disassoc) to userspace driver finds and associates with '12:34:56:78:91:23' (if not available, it Just Does Nothing) (if available, sends SIWAP of '12:34:56:78:91:23' to userspace) Similarly, I believe the following is correct: boot user app issues SIWESSID 'foo' driver searches for 'foo' but does not find it (if driver does background scanning and finds 'foo', it may associate) (if driver does not do background scanning, must wait until user app requests a scan, and if 'foo' is in results, may associate) user app issues SIWAP '12:34:56:78:91:23' (no SIWAP driver disassoc event needed because no association exists) driver finds and associates with '12:34:56:78:91:23' (if not available, it Just Does Nothing) (if available, sends SIWAP of '12:34:56:78:91:23' to userspace) Dan - 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: Hardware button support for Wireless cards
On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote: Hi everyone, Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. (had this issue in the back of my head for a while already...) Isn't the rf-kill switch specific to the manufacturer lots of times? Is the switch connected directly to the card, or is it incumbent on the driver to notice the event and disable the card via software? We need to handle this for Bluetooth too, in situations where there's both a bluetooth and an 802.11 card in the box. Does the rf-kill apply to both? Or just to one? WRT to disabling the radio, I'm not sure it makes a difference either way. Hitting a button generally means do this _NOW_, so it makes sense for the driver to disable the radio and then send out the event. Apps need to be able to deal with these resources going out from underneath them, and I'm not sure it makes sense to wait around for some scripts to run that just might possibly at some future point disable it, but you're never sure. In the end, an ACPI event is probably fine. I must stress that we NEED to have a common event structure for this, such that every driver and card presents the same interface. I don't want to have to write stuff for each of 3 or 4 different cards to notice the rf-kill stuff. Witness all the extra binaries that each driver has already for this sort of thing. What interface does the ipw[2|3]xxx driver and hardware present? What common bits can be drawn out from both? Ideally, here's what would happen: the driver/card/whatever generates an ACPI event, which is noticed by HAL. HAL sets a property on the _exact_ device which the event is for, and propagates the signal out over dbus. Any interested application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) Dan - 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] changing value of NETDEV_ALIGN to cacheline size
On Mon, 15 May 2006 14:08:29 +0200 Christian Borntraeger wrote: while digging through the alloc_netdev function I asked myself why there is a fixed alignment for netdevices. Is there a special reason for choosing 32? If yes, I suggest to add a comment to the definition. If not, I suspect cacheline alignment might be beneficial: struct net_device contains several variables which are cache aligned (poll_list, queue_lock .). As far as I can see, the compiler tries to increase the size of the structure to make that possible, but expects the whole structure to be aligned to cache line size as well. With the current value for NETDEV_ALIGN we dont align struct net_device to the cache line, instead we align it to 32 bytes. That means that poll_list, queue_lock and friends are not always cache aligned, but 32 bytes aligned. The only reason why everything worked so far is the slab allocator design, which gives us a page aligned struct net_device in most cases. I think we should not rely on the behaviour of the memory allocator and use a different value for NETDEV_ALIGN instead. Any comments or corrections? cheers Christian The patch below is compile and boot tested on s390 and x86. Signed-off-by: Christian Borntraeger [EMAIL PROTECTED] include/linux/netdevice.h |2 +- net/core/dev.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- --- a/include/linux/netdevice.h 4 Apr 2006 07:25:47 - +++ b/include/linux/netdevice.h 15 May 2006 11:06:05 - @@ -504,7 +504,7 @@ struct class_device class_dev; }; -#define NETDEV_ALIGN32 +#define NETDEV_ALIGNL1_CACHE_BYTES #define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1) I don't know about the fixed value of 32, but if this patch is accepted, I'd prefer NETDEV_ALIGN_MASK instead of NETDEV_ALIGN_CONST. static inline void *netdev_priv(struct net_device *dev) --- a/net/core/dev.c 4 Apr 2006 07:25:50 - +++ b/net/core/dev.c 15 May 2006 11:06:05 - @@ -2986,7 +2986,7 @@ struct net_device *dev; int alloc_size; - /* ensure 32-byte alignment of both the device and private area */ + /* ensure cacheline alignment of both the device and private area */ alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) ~NETDEV_ALIGN_CONST; alloc_size += sizeof_priv + NETDEV_ALIGN_CONST; --- ~Randy - 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: Hardware button support for Wireless cards
On Monday 15 May 2006 16:37, Dan Williams wrote: On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote: Hi everyone, Currently, in our rt2x00 (using the devicescape stack) we are firing off an ACPI event so that the hardware button can be handled in userspace. This allows the user to basically do whatever they want when this button is pressed - including bringing down the wireless interface. The problem here is no distro's currently contain scripts to run from this event so for many users it just doesn't work without them manually having to write scripts to handle the ACPI even themselves. Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or B. should we be firing an ACPI event and getting the distro's to add scripts so when this event is fired they bring down all the wireless interfaces. (had this issue in the back of my head for a while already...) Isn't the rf-kill switch specific to the manufacturer lots of times? Is the switch connected directly to the card, or is it incumbent on the driver to notice the event and disable the card via software? We need to handle this for Bluetooth too, in situations where there's both a bluetooth and an 802.11 card in the box. Does the rf-kill apply to both? Or just to one? The rt2x00 device itself does nothing when the button is pressed, it only updates certain fields in a register to indicate the button is pressed. The driver should read from the EEPROM if a hardware button is available, after that it should poll the register to see if the button has been pressed, and it is up to the driver what to do. WRT to disabling the radio, I'm not sure it makes a difference either way. Hitting a button generally means do this _NOW_, so it makes sense for the driver to disable the radio and then send out the event. Apps need to be able to deal with these resources going out from underneath them, and I'm not sure it makes sense to wait around for some scripts to run that just might possibly at some future point disable it, but you're never sure. Well I would think it is cleaner to inform userspace that the button is pressed and let userspace sort out what exactly should happen. But I doubt it will be a good idea when the driver is sending and event _and_ disabled the radio. It could be that the user wants something to be done before the radio is being disabled. In the end, an ACPI event is probably fine. I must stress that we NEED to have a common event structure for this, such that every driver and card presents the same interface. I don't want to have to write stuff for each of 3 or 4 different cards to notice the rf-kill stuff. Witness all the extra binaries that each driver has already for this sort of thing. What interface does the ipw[2|3]xxx driver and hardware present? What common bits can be drawn out from both? Ideally, here's what would happen: the driver/card/whatever generates an ACPI event, which is noticed by HAL. HAL sets a property on the _exact_ device which the event is for, and propagates the signal out over dbus. Any interested application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) This idea sounds good, but is ACPI the thing to be used. Escpially since ACPI is a bit architectures dependent. And the solution should be supported on various architectures. But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) system-wide would not be a good idea, we need something to determine which driver exactly has triggered the event. Some laptops have several hardware buttons 1 for Bluetooth and 1 for Wifi for example. So we could just pass the name the driver has created for that button to userspace. At least that is a similar approach to ACPI where the class, bid and name fields are all names set by the driver. pgpdHFhb9PNpa.pgp Description: PGP signature
Re: Hardware button support for Wireless cards
[EMAIL PROTECTED] said: Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. This is actually quite nice for testing roaming setups. You can roam in and out of range by toggling the button. The other laptop in the house has a physical _switch_, which implies that it too cuts off the radio in hardware (though I haven't investigated this, so I'm only speculating). So if there's any desire for consistency of wireless button support, then I think the software-controlled ones should always shut off the radio, and optionally inform userspace or the wireless stack using some event mechanism. What is the purpose of these switches anyway? Power saving? Or is it for situations like an airplane or hospital where you want to be sure your wireless won't cause any interference? If the latter, than that also argues for always shutting off the radio immediately. 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: [PATCH] pcnet32.c: modify RX ring size through module parameter
I have several problems with this patch. First, it assumes you only have one device or you want all devices to operate with the same receive ring size. (use module_param_array like full_duplex or options). Second, the mininum number of descriptors should be 4 not 2, or the loopback test will look past the end of the receive ring looking for status to change, and then try and pick up an skb pointer past the end of the array and try to dereference it. Either fix the loopback test to work with the minimum number of tx and rx descriptors instead of the hard coded 4, or make the minimum rx ring size be 4. numbuffs = min(4 , min(lp-tx_ring_size, lp-rx_ring_size)); Another nit is the description says it is the RX Ring Buffer Size which might be misunderstood as the size of the receive buffer, not the size of the receive descriptor ring. (RX Ring Size would be better). Lastly, the patch also will not apply against pcnet32.c in mainline 2.6.17-rc4 due to whitespace changes. On Mon, May 15, 2006 at 11:32:14AM +0800, Wen Hsin Chang wrote: This patch is created from pcnet32.c v1.32. it will allow users to specify RX ring size upon module insertion via module parameter 'rx_log_size'. This is needed in some cases where too small the rx ring size will cause RX errors upon remote installation via pcnet32 NIC card. Signed-off-by: Wen Hsin Chang [EMAIL PROTECTED] -- Don Fry [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: ipv6 routing broken in 2.6.17-rc3,4
On Mon, 15 May 2006, Meelis Roos wrote: On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to 6to4 tunnel (the default route). It worked with fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel). ... vaarikas:~# ip -6 route 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 You're using the wrong prefix length. The right one is /16. Does that work? Maybe the 6to4 hack which didn't heed routing table (so either prefix length was OK) was removed or changed... -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - 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] pcnet32.c: modify RX ring size through module parameter
Why is this necessary? There is already an ethtool function to set the rx ring size (pcnet32_set_ringparam). Since module parameters are being phased out in favor of the ethtool functions, why not use the existing ethtool infrastructure for this? Thanks, Jon On Mon, May 15, 2006 at 11:32:14AM +0800, Wen Hsin Chang wrote: This patch is created from pcnet32.c v1.32. it will allow users to specify RX ring size upon module insertion via module parameter 'rx_log_size'. This is needed in some cases where too small the rx ring size will cause RX errors upon remote installation via pcnet32 NIC card. Signed-off-by: Wen Hsin Chang [EMAIL PROTECTED] --- a/drivers/net/pcnet32.c2006-03-30 09:49:10.0 +0800 +++ b/drivers/net/pcnet32.c2006-05-15 11:14:45.0 +0800 @@ -93,6 +93,9 @@ static struct net_device *pcnet32_dev; static int max_interrupt_work = 2; static int rx_copybreak = 200; +/* Module parameter to specify RX ring size at module insertion */ +static int rx_log_size = 0; + #define PCNET32_PORT_AUI 0x00 #define PCNET32_PORT_10BT 0x01 #define PCNET32_PORT_GPSI 0x02 @@ -1264,7 +1267,10 @@ pcnet32_probe1(unsigned long ioaddr, int lp-name = chipname; lp-shared_irq = shared; lp-tx_ring_size = TX_RING_SIZE;/* default tx ring size */ -lp-rx_ring_size = RX_RING_SIZE;/* default rx ring size */ +if (!rx_log_size) +lp-rx_ring_size = RX_RING_SIZE;/* default rx ring size */ +else +lp-rx_ring_size = (1 (rx_log_size)); lp-tx_mod_mask = lp-tx_ring_size - 1; lp-rx_mod_mask = lp-rx_ring_size - 1; lp-tx_len_bits = (PCNET32_LOG_TX_BUFFERS 12); @@ -2707,6 +2713,11 @@ module_param(tx_start_pt, int, 0); MODULE_PARM_DESC(tx_start_pt, DRV_NAME transmit start point (0-3)); module_param(pcnet32vlb, int, 0); MODULE_PARM_DESC(pcnet32vlb, DRV_NAME Vesa local bus (VLB) support (0/1)); + +/* Module parameter to specify RX ring size at module insertion */ +module_param(rx_log_size, int, 0); +MODULE_PARM_DESC(rx_log_size, DRV_NAME RX Ring Buffer Size (log_2 #BUF) ); + module_param_array(options, int, NULL, 0); MODULE_PARM_DESC(options, DRV_NAME initial option setting(s) (0-15)); module_param_array(full_duplex, int, NULL, 0); @@ -2731,6 +2742,12 @@ static int __init pcnet32_init_module(vo if ((tx_start_pt = 0) (tx_start_pt = 3)) tx_start = tx_start_pt; + +/* validating rx_log_size */ +if ((rx_log_size = 0) || +(rx_log_size PCNET32_LOG_MAX_RX_BUFFERS)) +rx_log_size = 0; + /* find the PCI devices */ if (!pci_module_init(pcnet32_driver)) - 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 - 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: Hardware button support for Wireless cards
On Monday 15 May 2006 17:27, you wrote: [EMAIL PROTECTED] said: Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate some Radio is hardware-disabled state. We currently don't use that flag correctly in the driver. Could you please assist me on testing if your switch actually toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users - 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: Hardware button support for Wireless cards
On Mon, 2006-05-15 at 10:37 -0400, Dan Williams wrote: Ideally, here's what would happen: the driver/card/whatever generates an ACPI event, which is noticed by HAL. HAL sets a property on the _exact_ device which the event is for, and propagates the signal out over dbus. Any interested application can listen for, and respond to, the rf-kill signal. (or, the event can be handled by acpid and the distro can run scripts for it. 01dsk001. whatever) Yes, I agree this needs to happen in user space partly because it's policy even though I can only come up with crack reasons on why you wouldn't want to turn off the radio when the button is pressed. However, I suppose we need to do it in user space for some laptops anyway since I'm not sure the RF Kill Switch button and the networking hardware may be related; see below. But this means a few things. We need: 1) common interface/signal for _all_ cards and drivers Right, this would be nice. This is sorta like the mess that is hotkeys on laptops. We sorta deal with those in HAL but it's a lot of ugly code to present a sane abstract interface to user space. 2) Enough information to identify which specific pci/pcmcia/etc device the event is for (or system-wide?) No, I'm not really sure we need to know exactly what device this is triggered for and I'm not even sure that the kernel can figure this out anyway: the RF Kill buttons may be implemented as a USB HID device for example which may have little relation to the hardware. Another example is where the user is using a USB or PC Card Wifi adapter instead of the built-in Wifi. We want to turn off the radio on the USB or PC Card in these cases too. So what we need from user space is basically just an event saying RF Kill button pressed perhaps with some detail such as 'bluetooth' or 'wifi' depending on the graphics of the button (no, I'm not kidding). It would also be nice with some way to query state, e.g. is the button pressed or not if the hardware supports this. So, I think perhaps it may make sense to model this as an input device. Then we can simply query this input device from user space (in HAL) and emit the right events and provide an interface to query whether the button is pressed or not [1]. Specifically, on startup, NetworkManager would just ask HAL whether the button is pressed or not (if the hardware supports it) and do the right thing, e.g. selectively suspend all networking devices with a radio via the power/state file in sysfs which will turn off the radio. When the user presses the button, NetworkManager enables / disables the device [2] and so on. Hope this helps. David [1] : we do the same thing for other buttons in HAL; e.g. the power button on some Powerbooks. [2] : this raises another problem. What happens to class devices when a bus device is turned off (e.g. selective suspend). For example, does the class device /sys/class/net/eth0 go away when I put the physical to sleep via the /sys/class/net/eth0/device/power/state file? Maybe off topic, but what happens in general? For example what happens when I selectively suspend a USB harddisk enclosure, does /sys/block/sda go away? If it doesn't, does '# touch /dev/sda' wake it up? (it probably shouldn't)... This kind of stuff needs to be precisely defined, yes? Is it already defined? - 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 for 2.6.17] [1/5] x86_64: Check for bad dma address in b44 1GB DMA workaround
Needed for interaction with the nommu code in x86-64 which
will return bad_dma_address if the address exceeds dma_mask.
Cc: netdev@vger.kernel.org
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
drivers/net/b44.c | 28 ++--
1 files changed, 18 insertions(+), 10 deletions(-)
Index: linux/drivers/net/b44.c
===
--- linux.orig/drivers/net/b44.c
+++ linux/drivers/net/b44.c
@@ -650,9 +650,11 @@ static int b44_alloc_rx_skb(struct b44 *
/* Hardware bug work-around, the chip is unable to do PCI DMA
to/from anything above 1GB :-( */
- if (mapping + RX_PKT_BUF_SZ B44_DMA_MASK) {
+ if (dma_mapping_error(mapping) ||
+ mapping + RX_PKT_BUF_SZ B44_DMA_MASK) {
/* Sigh... */
- pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_DMA);
if (skb == NULL)
@@ -660,8 +662,10 @@ static int b44_alloc_rx_skb(struct b44 *
mapping = pci_map_single(bp-pdev, skb-data,
RX_PKT_BUF_SZ,
PCI_DMA_FROMDEVICE);
- if (mapping + RX_PKT_BUF_SZ B44_DMA_MASK) {
- pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
+ if (dma_mapping_error(mapping) ||
+ mapping + RX_PKT_BUF_SZ B44_DMA_MASK) {
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp-pdev, mapping,
RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
return -ENOMEM;
}
@@ -967,9 +971,10 @@ static int b44_start_xmit(struct sk_buff
}
mapping = pci_map_single(bp-pdev, skb-data, len, PCI_DMA_TODEVICE);
- if (mapping + len B44_DMA_MASK) {
+ if (dma_mapping_error(mapping) || mapping + len B44_DMA_MASK) {
/* Chip can't handle DMA to/from 1GB, use bounce buffer */
- pci_unmap_single(bp-pdev, mapping, len, PCI_DMA_TODEVICE);
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp-pdev, mapping, len,
PCI_DMA_TODEVICE);
bounce_skb = __dev_alloc_skb(TX_PKT_BUF_SZ,
GFP_ATOMIC|GFP_DMA);
@@ -978,8 +983,9 @@ static int b44_start_xmit(struct sk_buff
mapping = pci_map_single(bp-pdev, bounce_skb-data,
len, PCI_DMA_TODEVICE);
- if (mapping + len B44_DMA_MASK) {
- pci_unmap_single(bp-pdev, mapping,
+ if (dma_mapping_error(mapping) || mapping + len B44_DMA_MASK)
{
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp-pdev, mapping,
len, PCI_DMA_TODEVICE);
dev_kfree_skb_any(bounce_skb);
goto err_out;
@@ -1203,7 +1209,8 @@ static int b44_alloc_consistent(struct b
DMA_TABLE_BYTES,
DMA_BIDIRECTIONAL);
- if (rx_ring_dma + size B44_DMA_MASK) {
+ if (dma_mapping_error(rx_ring_dma) ||
+ rx_ring_dma + size B44_DMA_MASK) {
kfree(rx_ring);
goto out_err;
}
@@ -1229,7 +1236,8 @@ static int b44_alloc_consistent(struct b
DMA_TABLE_BYTES,
DMA_TO_DEVICE);
- if (tx_ring_dma + size B44_DMA_MASK) {
+ if (dma_mapping_error(tx_ring_dma) ||
+ tx_ring_dma + size B44_DMA_MASK) {
kfree(tx_ring);
goto out_err;
}
-
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 4/6] myri10ge - First half of the driver
On Fri, 2006-05-12 at 01:53 +0200, Brice Goglin wrote: Francois Romieu wrote: + spin_lock(mgp-cmd_lock); + response-result = 0x; + mb(); + myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf)); + + /* wait up to 2 seconds */ You must not hold a spinlock for up to 2 seconds. We are working on reducing the delay to about 15ms. It only occurs when the driver is loaded or the link brought up. I think 15ms is quite a long time to hold a spinlock also - most spinlocks in the kernel are held for less than 500 microseconds. Can't you use a mutex? Lee - 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: ipv6 routing broken in 2.6.17-rc3,4
vaarikas:~# ip -6 route 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 You're using the wrong prefix length. The right one is /16. Does that work? Will try soon today. But the other routes had mor specific masks anyway - /64 and /128, so why should it change anything? -- Meelis Roos ([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: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables userland binary is from the latest Debian unstable (1.3.3-2). The symptoms: iptables usually just tells Invalid Argument on any modification attempt. I'm trying to set up a simple one-rule NAT for test: iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -j SNAT --to 10.0.0.1 and it usually fails but has succeeded 2 times (I now have 2 rules of this kind and they seem to just wotk once set up). Trying to delete the second rule (either by replacing -A with -D or using just -D 2) gives the same error. This should already be fixed in -rc4. Unfortunately it was still there with yesterdays rc4+git. -- Meelis Roos ([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: ipv6 routing broken in 2.6.17-rc3,4
vaarikas:~# ip -6 route 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480 advmss 1420 hoplimit 4294967295 You're using the wrong prefix length. The right one is /16. Does that work? Changed tun6to4 to 2002::/16, still the same (packets for eth0 and the unreachable destination still go to tun6to4). # ip -6 route ::/96 via :: dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 unreachable 2001:7a8:1:5::14 dev lo metric 1024 expires 21334363sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295 2002:5283:2811:2::/64 dev eth0 metric 256 expires 21334342sec mtu 1500 advmss 1440 hoplimit 4294967295 2002::/16 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 fe80::/64 dev eth0 metric 256 expires 21332676sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev eth1 metric 256 expires 21334336sec mtu 1500 advmss 1440 hoplimit 4294967295 fe80::/64 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth1 metric 256 expires 21334336sec mtu 1500 advmss 1440 hoplimit 4294967295 ff00::/8 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295 ff00::/8 dev eth0 metric 256 expires 21332676sec mtu 1500 advmss 1440 hoplimit 4294967295 unreachable default dev lo proto none metric -1 error -101 hoplimit 255 -- Meelis Roos ([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 wireless-dev] d80211: Don't discriminate against 802.11b drivers
On Monday 15 May 2006 07:37, Jiri Benc wrote:
This issue can be easily solved by not masking hw_modes by
valid_hw_modes in ieee80211_ioctl_prism2_param and
ieee80211_precalc_modes. Just check (hw_modes valid_hw_modes) instead
of hw_modes in ieee80211_sta_scan_timer.
And yes, hw_modes is a confusing name. It should be named
hw_modes_mask_disabled_by_user or so. Maybe at least some better comment
about this in ieee80211_i.h won't be a bad idea.
Okay, how about this? Instead of adding valid_hw_modes, I added enabled_modes,
and replaced all instances of local-hw_modes with local-enabled_modes.
local-hw_modes now really means what modes are supported by the hardware.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index ffb7985..135db24 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -3999,14 +3999,17 @@ void ieee80211_if_setup(struct net_devic
}
-static void ieee80211_precalc_rates(struct ieee80211_hw *hw)
+static void ieee80211_precalc_modes(struct ieee80211_hw *hw,
+ struct ieee80211_local *local)
{
struct ieee80211_hw_modes *mode;
struct ieee80211_rate *rate;
int m, r;
+ local-hw_modes = 0;
for (m = 0; m hw-num_modes; m++) {
mode = hw-modes[m];
+ local-hw_modes |= 1 mode-mode;
for (r = 0; r mode-num_rates; r++) {
rate = mode-rates[r];
rate-rate_inv = CHAN_UTIL_RATE_LCM / rate-rate;
@@ -4087,7 +4090,7 @@ struct net_device *ieee80211_alloc_hw(si
local-rate_ctrl_num_down = RATE_CONTROL_NUM_DOWN;
local-scan.in_scan = 0;
- local-hw_modes = (unsigned int) -1;
+ local-enabled_modes = (unsigned int) -1;
init_timer(local-scan.timer); /* clear it out */
@@ -4257,7 +4260,7 @@ int ieee80211_update_hw(struct net_devic
!hw-modes-num_channels || !hw-modes-num_rates)
return -1;
- ieee80211_precalc_rates(hw);
+ ieee80211_precalc_modes(hw, local);
local-conf.phymode = hw-modes[0].mode;
local-curr_rates = hw-modes[0].rates;
local-num_curr_rates = hw-modes[0].num_rates;
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ee0b399..595f6b1 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -409,7 +409,6 @@ #define IEEE80211_IRQSAFE_QUEUE_LIMIT 12
int scan_oper_antenna_max;
u8 scan_ssid[IEEE80211_MAX_SSID_LEN];
size_t scan_ssid_len;
- int scan_skip_11b;
struct list_head sta_bss_list;
struct ieee80211_sta_bss *sta_bss_hash[STA_HASH_SIZE];
spinlock_t sta_bss_lock;
@@ -500,7 +499,9 @@ #endif /* CONFIG_D80211_DEBUG_COUNTERS *
int wifi_wme_noack_test;
unsigned int wmm_acm; /* bit field of ACM bits (BIT(802.1D tag)) */
- unsigned int hw_modes; /* bitfield of allowed hardware modes;
+ unsigned int enabled_modes; /* bitfield of allowed modes;
+ * (1 MODE_*) */
+ unsigned int hw_modes; /* bitfield of supported hardware modes;
* (1 MODE_*) */
};
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 5d31a8f..04df0a9 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1699,7 +1699,7 @@ int ieee80211_ioctl_siwfreq(struct net_d
if (chan-flag IEEE80211_CHAN_W_SCAN
((freq-e == 0 chan-chan == freq-m) ||
(freq-e 0 nfreq == chan-freq))
- (local-hw_modes (1 mode-mode))) {
+ (local-enabled_modes (1 mode-mode))) {
/* Use next_mode as the mode preference to
* resolve non-unique channel numbers. */
if (set mode-mode != local-next_mode)
@@ -2447,7 +2447,7 @@ static int ieee80211_ioctl_prism2_param(
break;
case PRISM2_PARAM_HW_MODES:
- local-hw_modes = value;
+ local-enabled_modes = value;
break;
case PRISM2_PARAM_CREATE_IBSS:
@@ -2620,7 +2620,7 @@ static int ieee80211_ioctl_get_prism2_pa
break;
case PRISM2_PARAM_HW_MODES:
- *param = local-hw_modes;
+ *param = local-enabled_modes;
break;
case PRISM2_PARAM_CREATE_IBSS:
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 2720f1d..af58013 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2462,13 +2462,13 @@ static void ieee80211_sta_scan_timer(uns
}
return;
}
- skip = !(local-hw_modes (1 mode-mode));
+ skip = !(local-enabled_modes (1 mode-mode));
Re: [PATCH 4/6] myri10ge - First half of the driver
Lee Revell wrote: On Fri, 2006-05-12 at 01:53 +0200, Brice Goglin wrote: Francois Romieu wrote: + spin_lock(mgp-cmd_lock); + response-result = 0x; + mb(); + myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf)); + + /* wait up to 2 seconds */ You must not hold a spinlock for up to 2 seconds. We are working on reducing the delay to about 15ms. It only occurs when the driver is loaded or the link brought up. I think 15ms is quite a long time to hold a spinlock also - most spinlocks in the kernel are held for less than 500 microseconds. Can't you use a mutex? It looks like rtnl_lock protects us here. We are working on it. Brice - 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: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
Meelis Roos wrote: Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables userland binary is from the latest Debian unstable (1.3.3-2). The symptoms: iptables usually just tells Invalid Argument on any modification attempt. I'm trying to set up a simple one-rule NAT for test: iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -j SNAT --to 10.0.0.1 and it usually fails but has succeeded 2 times (I now have 2 rules of this kind and they seem to just wotk once set up). Trying to delete the second rule (either by replacing -A with -D or using just -D 2) gives the same error. This should already be fixed in -rc4. Unfortunately it was still there with yesterdays rc4+git. I may have misinterpreted your report - are you running a 32bit or 64bit kernel? - 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: Hardware button support for Wireless cards
On Mon, 2006-05-15 at 18:01 +0200, Michael Buesch wrote: On Monday 15 May 2006 17:27, you wrote: [EMAIL PROTECTED] said: Some people are saying that instead of throwing and ACPI event we should be either use hotplug or internally just disable the radio and somehow inform the dscape stack that the radio has been disabled. What are peoples thoughts here, should we A. be handling this within our drivers and doing what the user expects and disabling the hardware radio, or On my HP laptop with bcm43xx wireless, the button disables the radio in HARDWARE, and afaict the driver has no idea about it. The driver notices that it's not connected and happily starts scanning again, unaware that anything is wrong. There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate some Radio is hardware-disabled state. We currently don't use that flag correctly in the driver. Could you please assist me on testing if your switch actually toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users When those bits get set in the register, is the radio already disabled? ie, for the bcm43xx chip, is it really force-disabled by the button, or does the driver have some control? Dan - 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: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
This should already be fixed in -rc4. Unfortunately it was still there with yesterdays rc4+git. I may have misinterpreted your report - are you running a 32bit or 64bit kernel? 32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP subarch, only buildable from the old ARCH=ppc code (not yet migrated to ARCH=powerpc). -- Meelis Roos ([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: Hardware button support for Wireless cards
On Monday 15 May 2006 21:12, you wrote: There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate some Radio is hardware-disabled state. We currently don't use that flag correctly in the driver. Could you please assist me on testing if your switch actually toggles the bit? I think best place for this would be on irc.freenode.net #bcm-users When those bits get set in the register, is the radio already disabled? ie, for the bcm43xx chip, is it really force-disabled by the button, or does the driver have some control? Hm, actually, We don't know what the bit means. Could be some completely different meaning. That is what I am trying to find out. But it seems to have something to do with the power control of the chip. - 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: ixp2000: handle enp2611s with two gigabit ports
On Thu, 27 Apr 2006 00:24:11 +0200
Lennert Buytenhek [EMAIL PROTECTED] wrote:
The ixp2000 driver for the enp2611 was developed on a board with
three gigabit ports, but some enp2611 models only have two ports
(and only one onboard PM3386.) The current driver assumes there
are always three ports and so it doesn't work on the two-port
version of the board at all.
This patch adds a bit of logic to the enp2611 driver to limit the
number of ports to 2 if the second PM3386 isn't detected.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
This patch got mangled, that is probably why jeff didn't apply it before
he left. I had to fix it manually.
patching file drivers/net/ixp2000/enp2611.c
patch: malformed patch at line 106:
module_init(enp2611_init_module);
In this part...
@@ -236,8 +240,10 @@
del_timer_sync(link_check_timer);
ixpdev_deinit();
- for (i = 0; i 3; i++)
- free_netdev(nds[i]);
+ for (i = 0; i 3; i++) {
+ if (nds[i] != NULL)
free_netdev(nds[i]);
+ }
}
module_init(enp2611_init_module);
-
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: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
Meelis Roos wrote: This should already be fixed in -rc4. Unfortunately it was still there with yesterdays rc4+git. I may have misinterpreted your report - are you running a 32bit or 64bit kernel? 32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP subarch, only buildable from the old ARCH=ppc code (not yet migrated to ARCH=powerpc). Ah OK, I thought it was related to the new compat code, but that isn't the case. Your trace doesn't give much clues, except that it shows that iptables dies with a SIGSEGV, which might be a bug in userspace or in the kernel. Which was the last kernel that worked for you, and can you try that version again to rule out userspace bugs? - 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: Hardware button support for Wireless cards
On Mon, May 15, 2006 at 03:27:54PM +, Jason Lunz wrote: So if there's any desire for consistency of wireless button support, then I think the software-controlled ones should always shut off the radio, and optionally inform userspace or the wireless stack using some event mechanism. FWIW, I think this position makes the most sense... John -- John W. Linville [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: SIOCSIWESSID + SIOCSIWAP behaviour
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: Hi Jean, Hi, Nice discussion you got going here ;-) I'd just like to check my understanding (and softmacs implementation) of SIWESSID and SIWAP behaviour, for managed mode. When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. I'll chime in too... My understanding of WE is that your understanding of WE is correct. Yes. There is one case where you don't need to reassociate : if you already have the correct ESSID or BSSID. This mostly happens when you set the ESSID to any or the BSSID to off or any. Also, Jouni is correct that you don't need to scan if your scan results are fresh enough. But if the user has already set the SSID and _then_ sets the BSSID, the driver must attempt to associate with an AP that has _both_ those properties. Setting one doesn't cancel the other out (Jean, correct if I'm wrong here?) Correct. AFAIK, you can actually set any old BSSID you like on the access point, so there's no guarantee that the BSSID any access point advertises is unique. Furthermore I believe you can have one AP with one BSSID server more than one ESSID. Higher-end Cisco/3Com/etc products allow this. I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). Is it correct that SIWAP can legally select *any* AP? (As opposed to only being for selecting a specific AP *on the ESS* indicated by a past or future SIWESSID call) Correct. The user may SIWAP _any_ BSSID at all, not necessarily related to the SSID. However, if the user just set an ESSID with SIWESSID, I'm fairly sure that ESSID must be honored as well. The main configuration is SIWESSID, that's the only config that is required by the standard. WIWAP is only a secondary configuration, that is optional and not supported in all drivers. The ESSID set should always be respected. If an ESSID is set, SIWAP should only look within APs having this ESSID, and not use a different ESSID. Only if the ESSID is set to 'any' should the card really pick any AP regardless of ESSID. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. No matter how I think of it, this strikes me as a hard interface to implement. Because association isn't an atomic operation, it is tricky to get the sequencing right, e.g. if the user does SIWESSID to start association, and then SIWAP to select a different AP before the original association has completed. Hmm, what problems does this have? It's not really any different than if the user issues two SIWESSID calls in short sequence, so you have to handle the start assoc-disassoc-start assoc sequence anyway... I agree that it make things messy in the driver. I also agree that the user can do stupid things with iwconfig, and therefore there is no real difference. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. But, you won't get away that end-users can do stupid stuff with iwconfig. Dan Have fun... Jean - 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] tcpdump may trace some outbound packets twice.
From: Ranjit Manomohan [EMAIL PROTECTED] Date: Mon, 15 May 2006 14:19:06 -0700 (PDT) Heres a new version which does a copy instead of the clone to avoid the double cloning issue. I still very much dislike this patch because it is creating 1 more clone per packet than is actually necessary and that is very expensive. dev_queue_xmit_nit() is going to clone whatever SKB you send into there, so better to just bump the reference count (with skb_get()) instead of cloning or copying. - 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: Hardware button support for Wireless cards
On Monday 15 May 2006 21:46, Jason Lunz wrote: On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote: When those bits get set in the register, is the radio already disabled? ie, for the bcm43xx chip, is it really force-disabled by the button, or does the driver have some control? I assume it disables the radio without any help from the driver, because it definitely turns off my radio, but the bcm43xx driver i'm using (in 2.6.17-rc4) currently doesn't pay any attention to those registers afaik. Correct, my laptop with an integrated BCM43xx chip works this was as well. I can use the button to enable and disable the device (led is switching on and off) without a bcm43xx driver installed. Hardware detection just picks it up when I enable the device with the button as new device. So the hardware button works directly with the hardware. pgpfqFfVjvAF7.pgp Description: PGP signature
Re: [RFC] changing value of NETDEV_ALIGN to cacheline size
David S. Miller wrote: From: Randy.Dunlap [EMAIL PROTECTED] Date: Mon, 15 May 2006 08:02:58 -0700 -#defineNETDEV_ALIGN32 +#defineNETDEV_ALIGNL1_CACHE_BYTES #define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1) I don't know about the fixed value of 32, but if this patch is accepted, I'd prefer NETDEV_ALIGN_MASK instead of NETDEV_ALIGN_CONST. The reason it's 32 is that old drivers depended on the struct being at least 32-byte aligned because they would embed structures DMA'd to/from the card in their private area and just assumed that would be aligned enough for the card's restrictions. So setting it to L1_CACHE_BYTES would be wrong, because if that happens to be less than 32 it would violate said assumption which we are catering to. How about: #define NETDEV_ALIGN_MIN 32 #if L1_CACHE_BYTES NETDEV_ALIGN_MIN # define NETDEV_ALIGN L1_CACHE_BYTES #else # define NETDEV_ALIGN NETDEV_ALIGN_MIN #endif rick jones - 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote: I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). What the standard says is somewhat irrelevant since there are APs that use multiple SSID with the same BSSID. I would say that it is reasonable for users to expect that this works with Linux, too. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. Keep in mind that it is also used by some programs (e.g., wpa_supplicant in ap_scan=1) without the user having to know anything about that level of details.. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. Number of drivers use an atomic associate command (usually, a private ioctl) with wpa_supplicant. If there were a standard way of doing that, it could be helpful. -- Jouni MalinenPGP id EFC895FA - 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, May 15, 2006 at 02:40:14PM -0700, Jouni Malinen wrote: On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote: I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). What the standard says is somewhat irrelevant since there are APs that use multiple SSID with the same BSSID. I would say that it is reasonable for users to expect that this works with Linux, too. Yeah, I guess it's required when you are using standard client card, but using the same BSSID is not as clean. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. Keep in mind that it is also used by some programs (e.g., wpa_supplicant in ap_scan=1) without the user having to know anything about that level of details.. My point is that we don't have to be perfect with respect to the end user through SIWAP. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. Number of drivers use an atomic associate command (usually, a private ioctl) with wpa_supplicant. If there were a standard way of doing that, it could be helpful. My goal was to offer the commit mechanism to solve those issues. The basic plumbing is in place, so we just a slightly more clever commit mechanism. The advantage is that the mechanism is generic, so will work for anything. Jouni MalinenPGP id EFC895FA Jean - 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] tcpdump may trace some outbound packets twice.
David S. Miller wrote: From: Ranjit Manomohan [EMAIL PROTECTED] Date: Mon, 15 May 2006 14:19:06 -0700 (PDT) Heres a new version which does a copy instead of the clone to avoid the double cloning issue. I still very much dislike this patch because it is creating 1 more clone per packet than is actually necessary and that is very expensive. dev_queue_xmit_nit() is going to clone whatever SKB you send into there, so better to just bump the reference count (with skb_get()) instead of cloning or copying. I think this would break the tc actions. Some actions call pskb_expand_head() on input, which BUGs on skb_shared(skb). They can't clone the skb instead because the functions doing that don't own it, the caller would continue with the old skb. - 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: send(), sendmsg(), sendto() not thread-safe
From: Mark A Smith [EMAIL PROTECTED] Date: Mon, 15 May 2006 14:39:06 -0700 I discovered that in some cases, send(), sendmsg(), and sendto() are not thread-safe. Although the man page for these functions does not specify whether these functions are supposed to be thread-safe, my reading of the POSIX/SUSv3 specification tells me that they should be. I traced the problem to tcp_sendmsg(). I was very curious about this issue, so I wrote up a small page to describe in more detail my findings. You can find it at: http://www.almaden.ibm.com/cs/people/marksmith/sendmsg.html . I don't understand why the desire is so high to ensure that individual threads get atomic writes, you can't even ensure that in the general case. Only sloppy programs that don't do their own internal locking hit into issues in this area. From your findings, the vast majority of systems you investigated do not provide atomic thread safe write semantics over TCP sockets. And frankly, BSD defines BSD socket semantics here not some wording in the POSIX standards. Finally, this discussion belongs on the networking development mailing list, netdev@vger.kernel.org, not linux-kernel. - 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] changing value of NETDEV_ALIGN to cacheline size
David S. Miller wrote: From: Rick Jones [EMAIL PROTECTED] Date: Mon, 15 May 2006 14:39:23 -0700 How about: How about, just leave it alone? :-) That would work too :) but I guess I figured based on the reason given just before I posted, for why setting to L1_CACHE_SIZE was wrong that there was an implication that tweaking it might be right. rick - 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] net_sched: potential jiffy wrap bug in dev_watchdog
There is a potential jiffy wraparound bug in the transmit watchdog
that is easily avoided by using time_after().
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- linux-2.6.orig/net/sched/sch_generic.c
+++ linux-2.6/net/sched/sch_generic.c
@@ -193,8 +193,10 @@ static void dev_watchdog(unsigned long a
netif_running(dev)
netif_carrier_ok(dev)) {
if (netif_queue_stopped(dev)
- (jiffies - dev-trans_start) dev-watchdog_timeo)
{
- printk(KERN_INFO NETDEV WATCHDOG: %s: transmit
timed out\n, dev-name);
+ time_after(jiffies, dev-trans_start +
dev-watchdog_timeo)) {
+
+ printk(KERN_INFO NETDEV WATCHDOG: %s: transmit
timed out\n,
+ dev-name);
dev-tx_timeout(dev);
}
if (!mod_timer(dev-watchdog_timer, jiffies +
dev-watchdog_timeo))
-
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/2] skge: bad checksums on big-endian platforms
Skge driver always causes bad checksums on big-endian.
The checksum in the receive control block was being swapped
when it doesn't need to be.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -2717,8 +2717,7 @@ static int skge_poll(struct net_device *
if (control BMU_OWN)
break;
- skb = skge_rx_get(skge, e, control, rd-status,
- le16_to_cpu(rd-csum2));
+ skb = skge_rx_get(skge, e, control, rd-status, rd-csum2);
if (likely(skb)) {
dev-last_rx = jiffies;
netif_receive_skb(skb);
-
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 2/2] skge: don't allow transmit ring to be too small
The driver will get stuck (permanent transmit timeout), if the transmit ring size is set too small. It needs to have enough ring elements to hold one maximum size transmit. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- skge-2.6.orig/drivers/net/skge.c +++ skge-2.6/drivers/net/skge.c @@ -402,7 +402,7 @@ static int skge_set_ring_param(struct ne int err; if (p-rx_pending == 0 || p-rx_pending MAX_RX_RING_SIZE || - p-tx_pending == 0 || p-tx_pending MAX_TX_RING_SIZE) + p-tx_pending MAX_SKB_FRAGS+1 || p-tx_pending MAX_TX_RING_SIZE) return -EINVAL; skge-rx_ring.count = p-rx_pending; - 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: send(), sendmsg(), sendto() not thread-safe
On Mon, 15 May 2006 16:17:48 -0700 Rick Jones [EMAIL PROTECTED] wrote: David S. Miller wrote: From: Mark A Smith [EMAIL PROTECTED] Date: Mon, 15 May 2006 14:39:06 -0700 I discovered that in some cases, send(), sendmsg(), and sendto() are not thread-safe. Although the man page for these functions does not specify whether these functions are supposed to be thread-safe, my reading of the POSIX/SUSv3 specification tells me that they should be. I traced the problem to tcp_sendmsg(). I was very curious about this issue, so I wrote up a small page to describe in more detail my findings. You can find it at: http://www.almaden.ibm.com/cs/people/marksmith/sendmsg.html . # ./sendmsgclient localhost ERROR! We should have all 0! We don't! buff[16384]=1 buff[16385]=1 buff[16386]=1 buff[16387]=1 buff[16388]=1 buff[16389]=1 buff[16390]=1 buff[16391]=1 buff[16392]=1 buff[16393]=1 That's 10/32768 bad bytes # uname -a HP-UX tarry B.11.23 U ia64 2397028692 unlimited-user license Given that the URL above asserts that HP-UX claims atomicity, either there is a bug in the UX stack, or perhaps the test? I took a quick look at the HP-UX 11iv2 (aka 11.23) manpage for sendmsg and didn't see anything about atomicity there - on which manpage(s) or docs was the assertion of HP-UX atomicity made? I presume this is only for blocking sockets? I cannot at least off the top of my head see how a stack could offer it on non-blocking sockets. The test seems to be based on sending a big message. In this case, on non-blocking sockets, the send call will return partial status. The return from the system call will be less than the number of bytes requested. And frankly, BSD defines BSD socket semantics here not some wording in the POSIX standards. Have BSD socket semantics ever been updated/clarified any any quasi-official manner since the popular presence of threads? Or are/were Posix/Xopen filling a gap? rick jones - 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 - 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] tcpdump may trace some outbound packets twice.
On Mon, 15 May 2006 16:11:05 -0700 (PDT)
Ranjit Manomohan [EMAIL PROTECTED] wrote:
On Mon, 15 May 2006, David S. Miller wrote:
From: Ranjit Manomohan [EMAIL PROTECTED]
Date: Mon, 15 May 2006 14:19:06 -0700 (PDT)
Heres a new version which does a copy instead of the clone to avoid
the double cloning issue.
I still very much dislike this patch because it is creating
1 more clone per packet than is actually necessary and that
is very expensive.
dev_queue_xmit_nit() is going to clone whatever SKB you send into
there, so better to just bump the reference count (with skb_get())
instead of cloning or copying.
I was a bit apprehensive about just incrementing the refcnt but that works
too. Attached is the modified version.
-Thanks,
Ranjit
--- linux-2.6/net/sched/sch_generic.c 2006-05-10 12:34:52.0 -0700
+++ linux/net/sched/sch_generic.c 2006-05-15 15:48:03.0 -0700
@@ -136,8 +136,12 @@
if (!netif_queue_stopped(dev)) {
int ret;
+ struct sk_buff *skbc = NULL;
+ /* Increment the reference count on the skb so
+ * that we can use it after a successful xmit.
+ */
if (netdev_nit)
- dev_queue_xmit_nit(skb, dev);
+ skbc = skb_get(skb);
skbc = netdev_nit ? skb_get(skb) : NULL;
ret = dev-hard_start_xmit(skb, dev);
if (ret == NETDEV_TX_OK) {
@@ -145,9 +149,20 @@
dev-xmit_lock_owner = -1;
spin_unlock(dev-xmit_lock);
}
+ if (skbc) {
+ /* transmit succeeded,
+ * trace the buffer. */
+ dev_queue_xmit_nit(skbc,dev);
+ kfree_skb(skbc);
+ }
spin_lock(dev-queue_lock);
return -1;
}
+
+ /* Call free in case we incremented refcnt */
+ if (skbc)
+ kfree_skb(skbc);
kfree_skb(NULL) is legal so the conditional here is unneeded.
But the increased calls to kfree_skb(NULL) would probably bring the
unlikely() hordes descending on kfree_skb, so maybe:
if (unlikely(netdev_nit))
kfree_skb(skbc);
-
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: send(), sendmsg(), sendto() not thread-safe
I presume this is only for blocking sockets? I cannot at least off the top of my head see how a stack could offer it on non-blocking sockets. The test seems to be based on sending a big message. In this case, on non-blocking sockets, the send call will return partial status. The return from the system call will be less than the number of bytes requested. Right, and at that point it is already too late to do anything about keeping some other thread of execution from shoving _its_ bytes into the socket before the rest of the first sends' can be put there. (Perhaps I'm preaching to the choir) rick jones - 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] tcpdump may trace some outbound packets twice.
From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 May 2006 16:41:01 -0700 kfree_skb(NULL) is legal so the conditional here is unneeded. But the increased calls to kfree_skb(NULL) would probably bring the unlikely() hordes descending on kfree_skb, so maybe: And unfortunately as Patrick McHardy states, we can't use this trick here because things like tc actions can do stuff like pskb_expand_head() which cannot handle shared SKBs. We need another solution to this problem, because cloning an extra SKB is just rediculious overhead so isn't something we can seriously consider to solve this problem. Another option is to say this anomaly doesn't matter enough to justify the complexity we're looking at here just to fix this glitch. Other implementation possibility suggestions welcome :-) - 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] tcpdump may trace some outbound packets twice.
David S. Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 May 2006 16:41:01 -0700 kfree_skb(NULL) is legal so the conditional here is unneeded. But the increased calls to kfree_skb(NULL) would probably bring the unlikely() hordes descending on kfree_skb, so maybe: And unfortunately as Patrick McHardy states, we can't use this trick here because things like tc actions can do stuff like pskb_expand_head() which cannot handle shared SKBs. We need another solution to this problem, because cloning an extra SKB is just rediculious overhead so isn't something we can seriously consider to solve this problem. Another option is to say this anomaly doesn't matter enough to justify the complexity we're looking at here just to fix this glitch. Other implementation possibility suggestions welcome :-) We could just mark the skb to make sure its only passed to taps on the first transmission attempt. Since we have the timestamp optimization there shouldn't be any visible change besides the desired effect. - 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] tcpdump may trace some outbound packets twice.
David S. Miller [EMAIL PROTECTED] wrote:
Other implementation possibility suggestions welcome :-)
I see two possibilities:
1) Move the af_packet hook into the NIC driver.
2) Rethink the lockless tx setup. If all NICs followed the tg3 and
replaced spin_lock_irqsave with spin_lock then we should be able
to go back to just using the xmit_lock.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] tcpdump may trace some outbound packets twice.
On Tue, May 16, 2006 at 02:21:27AM +0200, Patrick McHardy wrote: David S. Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 May 2006 16:41:01 -0700 kfree_skb(NULL) is legal so the conditional here is unneeded. But the increased calls to kfree_skb(NULL) would probably bring the unlikely() hordes descending on kfree_skb, so maybe: And unfortunately as Patrick McHardy states, we can't use this trick here because things like tc actions can do stuff like pskb_expand_head() which cannot handle shared SKBs. We need another solution to this problem, because cloning an extra SKB is just rediculious overhead so isn't something we can seriously consider to solve this problem. Another option is to say this anomaly doesn't matter enough to justify the complexity we're looking at here just to fix this glitch. Other implementation possibility suggestions welcome :-) We could just mark the skb to make sure its only passed to taps on the first transmission attempt. Since we have the timestamp optimization there shouldn't be any visible change besides the desired effect. It would be nice to have a solution that taps after its been sent to the driver. I clearly need to investigate the tc problems, but I've been using a similar patch now for a few weeks to allow more accurate timestamps to be performed in the driver without cloning problems getting in the way. (the tap skb only gets cloned after the driver has time stamped it). This is more accuracy than most need but is required for the clock synchronisation i'm working on. It also seems less intrusive to let the driver have the skb first before pushing it to the taps. Tom -- Thomas Young http://cubinlab.ee.unimelb.edu.au/~tyo/ Research Assistant CUBIN Research Centre - University of Melbourne - 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] tcpdump may trace some outbound packets twice.
Herbert Xu wrote: David S. Miller [EMAIL PROTECTED] wrote: Other implementation possibility suggestions welcome :-) I see two possibilities: 1) Move the af_packet hook into the NIC driver. 2) Rethink the lockless tx setup. If all NICs followed the tg3 and replaced spin_lock_irqsave with spin_lock then we should be able to go back to just using the xmit_lock. 3) Clone the skb and have dev_queue_xmit_nit() consume it. That should actually be pretty easy. - 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] tcpdump may trace some outbound packets twice.
On Tue, May 16, 2006 at 03:17:59AM +0200, Patrick McHardy wrote:
3) Clone the skb and have dev_queue_xmit_nit() consume it.
That should actually be pretty easy.
Unfortunately that would mean an unconditional copy for all TSO packets
on NICs such as tg3/e1000. These drivers have to modify the data area
of the skb.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] tcpdump may trace some outbound packets twice.
Patrick McHardy wrote: 3) Clone the skb and have dev_queue_xmit_nit() consume it. That should actually be pretty easy. On second thought, thats not so great either. netdev_nit just globally signals that there are some taps, but we don't know if they're interested in a specific packet. - 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: send(), sendmsg(), sendto() not thread-safe
I cannot think of another possible definition for thread-safe in the
context of these functions. Certainly they should not cause a crash when
called from multiple threads, but that's a requirement independent of
thread-safety. The POSIX specification doesn't mention atomicity with
respect to these functions. In the context of read(), it defines atomicity
as follows: Atomic means that all the bytes from a single operation that
started out together end up together, without interleaving from other I/O
operations. This seems to be the semantics I'm expecting from a
thread-safe sendmsg(). What else could thread-safe mean for send(),
sendmsg()?
As for fork() vs. pthreads, my original post indicated that this occurs
with or without pthreads, the same problem occurs if you use pthreads. I
tried to indicate that I was using the term thread to be independent of
whether the address space was shared or not.
If you do not see any send() sent 10 bytes messages in your server
output, it means that the problem occured the very first time the 10-byte
send was attempted. If you watch the data going over the wire, you'll see
those 10 bytes of 1's.
That write() document is excellent, and reads exactly like the POSIX
specification.
As for limits, I modified my test to use very small buffers, below any
reasonable limit. By removing the printf's, which slow the server
considerably, I can still get the problem to produce.
I think the question really boils down to: What does thread-safe mean with
respect to send()? It might be more easily answered by asking, How would
a non-thread-safe send() behave? I think it would behave the way we're
seeing it behave.
-Mark
That's excellent documentation, and reads exactly to the write()
specification in POSIX.
|-+
| | Rick Jones |
| | [EMAIL PROTECTED]|
| | om |
| ||
| | 05/15/2006 05:43 |
| | PM |
|-+
-|
|
|
| To: Mark A Smith/Almaden/[EMAIL PROTECTED]
|
| cc: [EMAIL PROTECTED], Linux Network Development list
netdev@vger.kernel.org|
| Subject: Re: send(), sendmsg(), sendto() not thread-safe
|
-|
Mark A Smith wrote:
Hi Rick, Stephen,
The thread-safe claim is at:
http://devrsrc1.external.hp.com/STKS/cgi-bin/man2html?manpage=/usr/share/man/man2.Z/send.2
Specifically,
MULTITHREAD USAGE
The send(), sendmsg(), and sendto() system calls are thread-safe.
They each have a cancellation point; and they are async-cancel
safe,
async-signal safe, and fork-safe.
That looks to be the 11iv1 manpage (aka 11.11).I wonder if perhaps
there is a distinction made between thread-safety and an atomicity
semantic?
Also, _strictly_ speaking, since your test is calling fork() rather than
pthread_create(), it isn't really testing thread safty but multiple
process atomicity right?
I noticed that you were thinking that the problem may be with my test and
that the send call is returning partial status.
Either the test, or the stack.
Actually, that's exactly
the issue. On the systems I tested on, and I assume HP-UX, send is _not_
returning partial status, it is returning that the entire buffer has been
written, and yet is interleaving data from packets in the other thread.
Ostensibly, I should see some ten byte send messages in the output of
sendmsgserver yes? I just ran a test where it was all 32768's, no 10's
but the client still reported an error. Is that supposed to be possible?
# sendmsgserver sendmsgserver.log
# wc sendmsgserver.log
165888 663552 3981312 sendmsgserver.log
# grep -v 32768 sendmsgserver.log
#
# ./sendmsgclient localhost
ERROR! We should have all 0! We don't!
buff[16384]=1
buff[16385]=1
buff[16386]=1
buff[16387]=1
buff[16388]=1
buff[16389]=1
buff[16390]=1
buff[16391]=1
buff[16392]=1
buff[16393]=1
That's 10/32768 bad bytes
I've also seen it fail at 12288 rather than 16384. I wonder if perhaps
there are unstated limits to the size of the write that can be atomic?
Looking at the 11.11 manpage for write(2) in the discussion of writes to
a pipe or FIFO it says:
+ Write requests of {PIPE_BUF} bytes or less will not be
interleaved with data from other processes doing writes on the
same pipe. Writes of greater than {PIPE_BUF} bytes may have
data interleaved, on arbitrary boundaries, with
Re: too many iterations (6) in nv_nic_irq
Carl-Daniel Hailfinger wrote: Hi Jeff, IIRC you had too many iterations (6) in nv_nic_irq appear regularly in your dmesg with kernel 2.6.16. Did this disappear in more recent kernels? If not, can you try the disable_msi and disable_msix module parameters if they help in your case? Yes, it disappeared in recent kernels. Jeff - 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] pcnet32.c: modify RX ring size through module parameter
There are cases where rx errors were found due to rx ring size being too small during remote installation using pcnet32. It is found that ethtool functionality may not be available under such circumenstance. This is the purpose behind this patch. However, as Don pointed out, there are several points that need to be considered. I'll further revise this patch and see how to come up with a better solution. Thanks for your comment~ Wen Hsin Chang Jon Mason wrote: Why is this necessary? There is already an ethtool function to set the rx ring size (pcnet32_set_ringparam). Since module parameters are being phased out in favor of the ethtool functions, why not use the existing ethtool infrastructure for this? Thanks, Jon On Mon, May 15, 2006 at 11:32:14AM +0800, Wen Hsin Chang wrote: This patch is created from pcnet32.c v1.32. it will allow users to specify RX ring size upon module insertion via module parameter 'rx_log_size'. This is needed in some cases where too small the rx ring size will cause RX errors upon remote installation via pcnet32 NIC card. Signed-off-by: Wen Hsin Chang [EMAIL PROTECTED] --- a/drivers/net/pcnet32.c2006-03-30 09:49:10.0 +0800 +++ b/drivers/net/pcnet32.c2006-05-15 11:14:45.0 +0800 @@ -93,6 +93,9 @@ static struct net_device *pcnet32_dev; static int max_interrupt_work = 2; static int rx_copybreak = 200; +/* Module parameter to specify RX ring size at module insertion */ +static int rx_log_size = 0; + #define PCNET32_PORT_AUI 0x00 #define PCNET32_PORT_10BT 0x01 #define PCNET32_PORT_GPSI 0x02 @@ -1264,7 +1267,10 @@ pcnet32_probe1(unsigned long ioaddr, int lp-name = chipname; lp-shared_irq = shared; lp-tx_ring_size = TX_RING_SIZE;/* default tx ring size */ -lp-rx_ring_size = RX_RING_SIZE;/* default rx ring size */ +if (!rx_log_size) +lp-rx_ring_size = RX_RING_SIZE;/* default rx ring size */ +else +lp-rx_ring_size = (1 (rx_log_size)); lp-tx_mod_mask = lp-tx_ring_size - 1; lp-rx_mod_mask = lp-rx_ring_size - 1; lp-tx_len_bits = (PCNET32_LOG_TX_BUFFERS 12); @@ -2707,6 +2713,11 @@ module_param(tx_start_pt, int, 0); MODULE_PARM_DESC(tx_start_pt, DRV_NAME transmit start point (0-3)); module_param(pcnet32vlb, int, 0); MODULE_PARM_DESC(pcnet32vlb, DRV_NAME Vesa local bus (VLB) support (0/1)); + +/* Module parameter to specify RX ring size at module insertion */ +module_param(rx_log_size, int, 0); +MODULE_PARM_DESC(rx_log_size, DRV_NAME RX Ring Buffer Size (log_2 #BUF) ); + module_param_array(options, int, NULL, 0); MODULE_PARM_DESC(options, DRV_NAME initial option setting(s) (0-15)); module_param_array(full_duplex, int, NULL, 0); @@ -2731,6 +2742,12 @@ static int __init pcnet32_init_module(vo if ((tx_start_pt = 0) (tx_start_pt = 3)) tx_start = tx_start_pt; + +/* validating rx_log_size */ +if ((rx_log_size = 0) || +(rx_log_size PCNET32_LOG_MAX_RX_BUFFERS)) +rx_log_size = 0; + /* find the PCI devices */ if (!pci_module_init(pcnet32_driver)) - 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 - 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 - 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: Hardware button support for Wireless cards
On Tue, May 16, 2006, Jouni Malinen wrote: Some hardware designs disable the radio in hardware, some don't.. In other words, the behavior would not be consistent between hardware designs unless the radio would be disabled unconditionally in software-processed case. I would like to be able to trust on the rfkill to really kill the radio regardless of whether the user space mechanism is in place or not, i.e., I see this as a function that can be used to disable radio in environments were use of wireless devices is not allowed for some reason. Sending an event to user space would be a good additional indication that the radio was disabled. If user space wants to do something first, I would think that doing this with full software control (i.e., not depending on any particular hardware button and just having a UI mechanism for triggering this) would allow more consistent behavior. Sounds like this is the popular option - I agree that immediate radio-off is the safe way to go here as at least the driver can guarantee that the radio is disabled no matter the userspace config. Does someone want to put their hand up and specify the userspace interface here and now so we all keep to a standard ? Working as an input device as David suggested seems to give us the most flexibility. Regards, Mark Wallis E: [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] tcpdump may trace some outbound packets twice.
From: Patrick McHardy [EMAIL PROTECTED] Date: Tue, 16 May 2006 03:22:21 +0200 Patrick McHardy wrote: 3) Clone the skb and have dev_queue_xmit_nit() consume it. That should actually be pretty easy. On second thought, thats not so great either. netdev_nit just globally signals that there are some taps, but we don't know if they're interested in a specific packet. Yes, and all of these issues coming up are why we do the dev_queue_xmit_nit() before not after we try to give it to the device. Even the NIT done bit doesn't work, for cases like ICMP replies which can reuse the SKB received, over loopback. Sure we can try to forcefully clear the bit everywhere we reuse buffers for replies like that, but I wish anyone trying to implement that the best of luck finding all spots successfully. To be honest, I don't think this bug is worth all the energy we are trying to put into fixing it. We get a double packet when the spinlock is hit, big deal. - 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] net_sched: potential jiffy wrap bug in dev_watchdog
From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 15 May 2006 16:28:58 -0700 There is a potential jiffy wraparound bug in the transmit watchdog that is easily avoided by using time_after(). Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Applied, thanks Stephen. - 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 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Kelly Daly [EMAIL PROTECTED]
Date: Tue, 16 May 2006 11:02:29 +1000
+/* handles default chan buffers that nobody else wants */
+static int default_netchannel_thread(void *unused)
+{
+ wait_queue_t wait;
+ struct netchannel_buftrailer *bp;
+ struct sk_buff *skbp;
+
+ wait.private = current;
+ wait.func = default_wake_function;;
+ INIT_LIST_HEAD(wait.task_list);
+
+ add_wait_queue(default_netchannel_wq, wait);
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ while (!kthread_should_stop()) {
+ bp = __netchannel_dequeue(default_netchannel);
+ skbp = skb_netchan_graft(bp, GFP_ATOMIC);
+ netif_receive_skb(skbp);
+ }
+ remove_wait_queue(default_netchannel_wq, wait);
+ __set_current_state(TASK_RUNNING);
+ return 0;
+}
+
When does this thread ever go to sleep? Seems like it will loop
forever and not block when the default_netchannel queue is empty.
:-)
+ unsigned long dlen = np-netchan_buf_len - np-netchan_buf_offset;
Probably deserves a netchan_buf_len(bp) inline in linux/netchannel.h
diff -urp davem_orig/net/ipv4/inet_hashtables.c
kelly/net/ipv4/inet_hashtables.c
--- davem_orig/net/ipv4/inet_hashtables.c 2006-04-27 00:08:33.0
+1000
+++ kelly/net/ipv4/inet_hashtables.c 2006-05-05 12:45:44.0 +1000
The hash table bits look good, just as they did last time :-)
So I'll put this part into my vj-2.6 tree now, thanks.
-
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
