Re: updated [Patch 1/1] AF_UNIX Datagram getpeersec
Hi, Stephen,
It appears that selinux_enabled is defined inside selinux module and not
visible to the rest of the kernel...
thanks,
Catherine
Stephen Hemminger [EMAIL PROTECTED] wrote on 06/17/2006 12:16:03 AM:
O
+void selinux_get_sock_sid(const struct socket *sock, u32 *sid)
+{
+ if (selinux_enabled) {
+ const struct inode *inode = SOCK_INODE(sock);
+ selinux_get_inode_sid(inode, sid);
+ return;
+ }
+ *sid = 0;
+}
+
This is so short, it would make sense to put it in scm.h
and why not have it return the value instead of call by reference?
Same goes for selinux_get_inode_sid
static inline void selinux_get_sock_sid(const struct socket *sock, u32
*sid)
{
if (selinux_enabled)
selinux_get_inode_sid(SOCK_INODE(sock), sid);
else
*sid = 0;
}
or
static inline u32 selinux_get_sock_sid(const struct socket *sock)
{
return selinux_enabled ? selinux_get_inode_sid(SOCK_INODE(sid)) : 0;
}
-
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.6.17 fix] bcm43xx: workaround init_board vs. IRQ race
Hi John,
Please try to push this for 2.6.17, as it is a crash fix.
--
Place the Init-vs-IRQ workaround before any card register
access, because we might not have the wireless core mapped
at all times in init. So this will result in a Machine Check
caused by a bus error.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
2006-06-17 15:06:38.0 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c2006-06-17
15:17:49.0 +0200
@@ -1885,6 +1885,15 @@
spin_lock(bcm-irq_lock);
+ /* Only accept IRQs, if we are initialized properly.
+* This avoids an RX race while initializing.
+* We should probably not enable IRQs before we are initialized
+* completely, but some careful work is needed to fix this. I think it
+* is best to stay with this cheap workaround for now... .
+*/
+ if (unlikely(bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED))
+ goto out;
+
reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (reason == 0x) {
/* irq not for us (shared irq) */
@@ -1906,19 +1915,11 @@
bcm43xx_interrupt_ack(bcm, reason);
- /* Only accept IRQs, if we are initialized properly.
-* This avoids an RX race while initializing.
-* We should probably not enable IRQs before we are initialized
-* completely, but some careful work is needed to fix this. I think it
-* is best to stay with this cheap workaround for now... .
-*/
- if (likely(bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED)) {
- /* disable all IRQs. They are enabled again in the bottom half.
*/
- bcm-irq_savedstate = bcm43xx_interrupt_disable(bcm,
BCM43xx_IRQ_ALL);
- /* save the reason code and call our bottom half. */
- bcm-irq_reason = reason;
- tasklet_schedule(bcm-isr_tasklet);
- }
+ /* disable all IRQs. They are enabled again in the bottom half. */
+ bcm-irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
+ /* save the reason code and call our bottom half. */
+ bcm-irq_reason = reason;
+ tasklet_schedule(bcm-isr_tasklet);
out:
mmiowb();
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
Except for the bluetooth radio key (which should be supported by the
radiobtn interface as well) the other buttons have support through already
excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models. That's why I pointed you to
the wistron_btns driver. Alternatively, look at the acerhk driver
(http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
number of additional buttons that need to be handled by a special driver, all
sent to userspace, and just one of them to trigger the wireless card. Other
models just handle the button in ACPI and generate an additional ACPI event.
Looking at the RT2400-driver, I see what you want to accomplish: Take the
view
of the WLAN card on the hardware controlled button enable/disable and
generate events on it. However, in many cases it is another driver (see
above) that sets or clears this state, and this should be the instance to
send the input event.
Note that I do not have objections against the driver being included in the
kernel - it just does not qualify as generic radiobutton support, but I know
it's hard to find a good name ;-)
Looking at the code only: There should be an additional non-polling interface
for drivers that can generate events on the own.
Sorry for the late reply, but I have been quite busy with other things lately.
I have created an updated patch, that is more generic than the previous.
I have also renamed it to laptopkey.
With this approach more buttons can be registered,
it includes the optional field to report an update of the key status
to the driver that registered it, and it supports for non-polling keys.
By default all events will go over the default input device, but a driver
can choose to create additional input devices.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 4bad588..097ae8c 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -79,4 +79,12 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config LAPTOPKEY
+ tristate Laptop keys support
+ help
+Say Y here if you have laptop with additional keys like hardware
+wireless or bluetooth radio control, or other (programmable) keys.
+This driver will create an input device to which other hardware
+drivers can register their keys to.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 415c491..e691fab 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_LAPTOPKEY)+= laptopkey.o
diff --git a/drivers/input/misc/laptopkey.c b/drivers/input/misc/laptopkey.c
new file mode 100644
index 000..7731554
--- /dev/null
+++ b/drivers/input/misc/laptopkey.c
@@ -0,0 +1,231 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/laptopkey.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(Laptop keys support);
+MODULE_LICENSE(GPL);
+
+/*
+ * Default laptop_key_device structure.
+ */
+static struct laptop_key_device default_keydev = {
+ .dev_name = laptopbtn,
+ .delay = 100,
+};
+
+void laptopkey_key_event(struct laptop_key *key, int status)
+{
+ /*
+* Check if the hardware needs to be informed of
+* the status change.
+*/
+ if (key-key_event)
+ key-key_event(key-data, status);
+
+ /*
+* Send input event to userspace.
+*/
+ input_report_key(key-keydev-input_dev, key-key, status);
+ input_sync(key-keydev-input_dev);
+
+}
+
+static void laptopkey_poll(unsigned long data)
+{
+ struct laptop_key_device *keydev = (struct laptop_key_device *)data;
+
Re: updated [Patch 1/1] AF_UNIX Datagram getpeersec
On Sat, 17 Jun 2006, Xiaolan Zhang wrote:
Hi, Stephen,
It appears that selinux_enabled is defined inside selinux module and not
visible to the rest of the kernel...
Yes, these are SELinux API functions, they belong in
security/selinux/exports.c
But what about Stephens question on the return value?
thanks,
Catherine
Stephen Hemminger [EMAIL PROTECTED] wrote on 06/17/2006 12:16:03 AM:
O
+void selinux_get_sock_sid(const struct socket *sock, u32 *sid)
+{
+ if (selinux_enabled) {
+ const struct inode *inode = SOCK_INODE(sock);
+ selinux_get_inode_sid(inode, sid);
+ return;
+ }
+ *sid = 0;
+}
+
This is so short, it would make sense to put it in scm.h
and why not have it return the value instead of call by reference?
Same goes for selinux_get_inode_sid
static inline void selinux_get_sock_sid(const struct socket *sock, u32
*sid)
{
if (selinux_enabled)
selinux_get_inode_sid(SOCK_INODE(sock), sid);
else
*sid = 0;
}
or
static inline u32 selinux_get_sock_sid(const struct socket *sock)
{
return selinux_enabled ? selinux_get_inode_sid(SOCK_INODE(sid)) : 0;
}
-
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
--
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: updated [Patch 1/1] AF_UNIX Datagram getpeersec
On Fri, 16 Jun 2006, Stephen Hemminger wrote: This is so short, it would make sense to put it in scm.h and why not have it return the value instead of call by reference? Same goes for selinux_get_inode_sid Actually, all of the SELinux API functions are like this, and I'm not sure why for void return methods (it's a good idea when they return errnos). Once this area has settled down (post 2.6.18), I'm planning to do some cleanups for this API anyway, and can fix these all at the same time. - 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
[PATCH, RFT] bcm43xx: Busting the 1G limit
Hi, This patch adds full 32-bit and 64-bit DMA support to the bcm43xx driver. Well, it _should_ do this. I can not test it, as I don't have a machine to trigger the 1G limit. The 1G limit should be exploitable on an AMD64 machine with more than 1G RAM. Please test and report, if it works or not. In the case of works not, please provide full dmesg log. Note that I am not sure which cards actually support full 32-bit or even 64-bit mode. Older cards might still only support 30-bit DMA. Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h === --- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx.h2006-06-17 17:48:26.0 +0200 +++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-06-17 18:01:34.0 +0200 @@ -32,14 +32,18 @@ #define BCM43xx_PCICFG_ICR 0x94 /* MMIO offsets */ -#define BCM43xx_MMIO_DMA1_REASON 0x20 -#define BCM43xx_MMIO_DMA1_IRQ_MASK 0x24 -#define BCM43xx_MMIO_DMA2_REASON 0x28 -#define BCM43xx_MMIO_DMA2_IRQ_MASK 0x2C -#define BCM43xx_MMIO_DMA3_REASON 0x30 -#define BCM43xx_MMIO_DMA3_IRQ_MASK 0x34 -#define BCM43xx_MMIO_DMA4_REASON 0x38 -#define BCM43xx_MMIO_DMA4_IRQ_MASK 0x3C +#define BCM43xx_MMIO_DMA0_REASON 0x20 +#define BCM43xx_MMIO_DMA0_IRQ_MASK 0x24 +#define BCM43xx_MMIO_DMA1_REASON 0x28 +#define BCM43xx_MMIO_DMA1_IRQ_MASK 0x2C +#define BCM43xx_MMIO_DMA2_REASON 0x30 +#define BCM43xx_MMIO_DMA2_IRQ_MASK 0x34 +#define BCM43xx_MMIO_DMA3_REASON 0x38 +#define BCM43xx_MMIO_DMA3_IRQ_MASK 0x3C +#define BCM43xx_MMIO_DMA4_REASON 0x40 +#define BCM43xx_MMIO_DMA4_IRQ_MASK 0x44 +#define BCM43xx_MMIO_DMA5_REASON 0x48 +#define BCM43xx_MMIO_DMA5_IRQ_MASK 0x4C #define BCM43xx_MMIO_STATUS_BITFIELD 0x120 #define BCM43xx_MMIO_STATUS2_BITFIELD 0x124 #define BCM43xx_MMIO_GEN_IRQ_REASON0x128 @@ -55,14 +59,27 @@ #define BCM43xx_MMIO_XMITSTAT_10x174 #define BCM43xx_MMIO_REV3PLUS_TSF_LOW 0x180 /* core rev = 3 only */ #define BCM43xx_MMIO_REV3PLUS_TSF_HIGH 0x184 /* core rev = 3 only */ -#define BCM43xx_MMIO_DMA1_BASE 0x200 -#define BCM43xx_MMIO_DMA2_BASE 0x220 -#define BCM43xx_MMIO_DMA3_BASE 0x240 -#define BCM43xx_MMIO_DMA4_BASE 0x260 + +/* 32-bit DMA */ +#define BCM43xx_MMIO_DMA32_BASE0 0x200 +#define BCM43xx_MMIO_DMA32_BASE1 0x220 +#define BCM43xx_MMIO_DMA32_BASE2 0x240 +#define BCM43xx_MMIO_DMA32_BASE3 0x260 +#define BCM43xx_MMIO_DMA32_BASE4 0x280 +#define BCM43xx_MMIO_DMA32_BASE5 0x2A0 +/* 64-bit DMA */ +#define BCM43xx_MMIO_DMA64_BASE0 0x200 +#define BCM43xx_MMIO_DMA64_BASE1 0x240 +#define BCM43xx_MMIO_DMA64_BASE2 0x280 +#define BCM43xx_MMIO_DMA64_BASE3 0x2C0 +#define BCM43xx_MMIO_DMA64_BASE4 0x300 +#define BCM43xx_MMIO_DMA64_BASE5 0x340 +/* PIO */ #define BCM43xx_MMIO_PIO1_BASE 0x300 #define BCM43xx_MMIO_PIO2_BASE 0x310 #define BCM43xx_MMIO_PIO3_BASE 0x320 #define BCM43xx_MMIO_PIO4_BASE 0x330 + #define BCM43xx_MMIO_PHY_VER 0x3E0 #define BCM43xx_MMIO_PHY_RADIO 0x3E2 #define BCM43xx_MMIO_ANTENNA 0x3E8 @@ -231,8 +248,14 @@ #define BCM43xx_SBTMSTATELOW_FORCE_GATE_CLOCK 0x2 /* sbtmstatehigh state flags */ -#define BCM43xx_SBTMSTATEHIGH_SERROR 0x1 -#define BCM43xx_SBTMSTATEHIGH_BUSY 0x4 +#define BCM43xx_SBTMSTATEHIGH_SERROR 0x0001 +#define BCM43xx_SBTMSTATEHIGH_BUSY 0x0004 +#define BCM43xx_SBTMSTATEHIGH_TIMEOUT 0x0020 +#define BCM43xx_SBTMSTATEHIGH_COREFLAGS0x1FFF +#define BCM43xx_SBTMSTATEHIGH_DMA64BIT 0x1000 +#define BCM43xx_SBTMSTATEHIGH_GATEDCLK 0x2000 +#define BCM43xx_SBTMSTATEHIGH_BISTFAILED 0x4000 +#define BCM43xx_SBTMSTATEHIGH_BISTCOMPLETE 0x8000 /* sbimstate flags */ #define BCM43xx_SBIMSTATE_IB_ERROR 0x2 @@ -566,8 +589,11 @@ struct bcm43xx_dmaring *tx_ring1; struct bcm43xx_dmaring *tx_ring2; struct bcm43xx_dmaring *tx_ring3; + struct bcm43xx_dmaring *tx_ring4; + struct bcm43xx_dmaring *tx_ring5; + struct bcm43xx_dmaring *rx_ring0; - struct bcm43xx_dmaring *rx_ring1; /* only available on core.rev 5 */ + struct bcm43xx_dmaring *rx_ring3; /* only available on core.rev 5 */ }; /* Data structures for PIO transmission, per 80211 core. */ @@ -708,7 +734,7 @@ /* Reason code of the last interrupt. */ u32 irq_reason; - u32 dma_reason[4]; + u32 dma_reason[6]; /* saved irq enable/disable state bitfield. */ u32 irq_savedstate; /* Link Quality calculation context. */ Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_dma.c === ---
[IOC3] IP27: Really set PCI64_ATTR_VIRTUAL, not PCI64_ATTR_PREC.
IOC3's homegrown DMA mapping functions that are used to optimize things
a little on IP27 set the wrong bit.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c
index ae71ed5..e76e6e7 100644
--- a/drivers/net/ioc3-eth.c
+++ b/drivers/net/ioc3-eth.c
@@ -145,7 +145,7 @@ static inline struct sk_buff * ioc3_allo
static inline unsigned long ioc3_map(void *ptr, unsigned long vdev)
{
#ifdef CONFIG_SGI_IP27
- vdev = 58; /* Shift to PCI64_ATTR_VIRTUAL */
+ vdev = 57; /* Shift to PCI64_ATTR_VIRTUAL */
return vdev | (0xaUL PCI64_ATTR_TARG_SHFT) | PCI64_ATTR_PREF |
((unsigned long)ptr TO_PHYS_MASK);
-
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: tg3 timeouts with 2.6.17-rc6
On Fri, 2006-06-16 at 20:37 -0700, Michael Chan wrote: David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Fri, 16 Jun 2006 18:27:32 -0700 In the meantime, I wonder if we should disable TSO by default on the 5780 chip for 2.6.17. Sounds reasonable. Would we disable it for all chips that set TG3_FLG2_5780_CLASS or a specific variant? Yes, let's disable it for all TG3_FLG2_5780_CLASS chips for now until we figure out what's going on. David, Here's the patch if you haven't already made one: [TG3]: Disable TSO by default on 5780 class chips. Disable TSO by default on 5780, 5714, and 5715 chips for now while we investigate the reported tx timeouts by Juergen Kreileder. Thanks to Juergen for reporting the problem. Update version to 3.60. Signed-off-by: Michael Chan [EMAIL PROTECTED] diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 862c226..607d87e 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -69,8 +69,8 @@ #define DRV_MODULE_NAMEtg3 #define PFX DRV_MODULE_NAME: -#define DRV_MODULE_VERSION 3.59 -#define DRV_MODULE_RELDATE June 8, 2006 +#define DRV_MODULE_VERSION 3.60 +#define DRV_MODULE_RELDATE June 17, 2006 #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 @@ -11385,7 +11385,11 @@ static int __devinit tg3_init_one(struct * Firmware TSO on older chips gives lower performance, so it * is off by default, but can be enabled using ethtool. */ - if (tp-tg3_flags2 TG3_FLG2_HW_TSO) + /* Disable TSO by default on all 5780 class chips because +* of reported tx timeouts. +*/ + if ((tp-tg3_flags2 TG3_FLG2_HW_TSO) + !(tp-tg3_flags2 TG3_FLG2_5780_CLASS)) dev-features |= NETIF_F_TSO; #endif - 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] d80211: allow NULL for control in beacon_get
bcm43xx has no use for the control data provided by
ieee80211_beacon_get(), so allow passing a NULL pointer
to avoid setting up a dummy struct and throwing the data
away afterwards in the driver.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c2006-06-17 22:51:20.0
+0200
+++ wireless-dev/net/d80211/ieee80211.c 2006-06-17 23:03:54.0 +0200
@@ -1683,28 +1683,30 @@
memcpy(skb_put(skb, bt_len), b_tail, bt_len);
}
- memset(extra, 0, sizeof(extra));
- extra.endidx = local-num_curr_rates;
+ if (control) {
+ memset(extra, 0, sizeof(extra));
+ extra.endidx = local-num_curr_rates;
- rate = rate_control_get_rate(dev, skb, extra);
- if (rate == NULL) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG %s: ieee80211_beacon_get: no rate
- found\n, dev-name);
+ rate = rate_control_get_rate(dev, skb, extra);
+ if (rate == NULL) {
+ if (net_ratelimit()) {
+ printk(KERN_DEBUG %s: ieee80211_beacon_get: no
rate
+ found\n, dev-name);
+ }
+ dev_kfree_skb(skb);
+ return NULL;
}
- dev_kfree_skb(skb);
- return NULL;
- }
- control-tx_rate = (local-short_preamble
- (rate-flags IEEE80211_RATE_PREAMBLE2)) ?
- rate-val2 : rate-val;
- control-antenna_sel = local-conf.antenna_sel;
- control-power_level = local-conf.power_level;
- control-no_ack = 1;
- control-retry_limit = 1;
- control-rts_cts_duration = 0;
- control-clear_dst_mask = 1;
+ control-tx_rate = (local-short_preamble
+ (rate-flags IEEE80211_RATE_PREAMBLE2)) ?
+ rate-val2 : rate-val;
+ control-antenna_sel = local-conf.antenna_sel;
+ control-power_level = local-conf.power_level;
+ control-no_ack = 1;
+ control-retry_limit = 1;
+ control-rts_cts_duration = 0;
+ control-clear_dst_mask = 1;
+ }
ap-num_beacons++;
return skb;
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recommend a network card
On Saturday 17 June 2006 23:12, bastard operater wrote: People on this list like Real Names and are more motivated to help, if they know your name. My 3Com 3C905B-TX is starting to malfunction and it is getting worse. So I I never had a malfunctioning NIC. What does it look like? Broken packages? am in the market for a new NIC. The card has to work on Linux (natively) and windows. I thought I would ask the experts if you have any recommendations for a good 100MB PCI card? I have mostly RTL based cards (ranging from 10 to 1000 mbit). No problems so far. (But also no problem with my 3c905 since quite some time ;) ) -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
On Fri, 16 Jun 2006 09:01:23 -0700 Harry Edmon [EMAIL PROTECTED] wrote: I have a system with a strange network performance degradation from 2.6.11.12 to most recent kernels including 2.6.16.20 and 2.6.17-rc6. The system is has Dual single core Xeons with hyperthreading on. The application is the LDM system from UCAR/Unidata (http://www.unidata.ucar.edu/software/ldm). This system requests weather data from a variety of systems using RPC calls over a reserved TCP port (388), puts them into a memory mapped queue file, and then sends the data out to a variety of downstream requesting systems, again using RPC calls. When the load is heavy, the 2.6.16.20 kernel falls way behind with the data ingestion. The 2.6.11.12 kernel does not. I have tried an experiment with a 2.6.17-rc6 system where it just does the ingestion, and not the downstream distribution, and it is able to keep up. I would really appreciate any pointers as to where the problem may be and how to diagnose it. I have attached the config files from both kernels and the sysctl.conf file I am using. I have also included the output from netstat -s on the 2.6.16.20 system during a time when it was having problems. (added netdev) A quick grep indicates that it isn't using TCP_NODELAY - we've had problems with that in the past. Perhaps a tcpdump of the net traffic will help to determine what's going on. - 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] driver for PPTP, second edition
Hello.
I have developed the driver for Point-to-Point Tunneling Protocol (PPTP).
This driver works in pair with plugin for pppd.
It is enough to use pppd's plugin for start of the client.
Also there is a server (based on pptpd) which uses this driver.
By results of my testing the speed of transfer has increased on 50% and cpu
usage has decreased on 50% in comparison with original pptpd and pptpclient.
I have published the project on http://accel-pptp.sourceforge.net/
diff -uprN linux-2.6.16.orig/drivers/net/Kconfig
linux-2.6.16.pptp/drivers/net/Kconfig
--- linux-2.6.16.orig/drivers/net/Kconfig 2006-06-18 00:51:35.0
+0400
+++ linux-2.6.16.pptp/drivers/net/Kconfig 2006-06-18 01:10:19.0
+0400
@@ -2603,6 +2603,15 @@ config PPPOE
which contains instruction on how to use this driver (under
the heading Kernel mode PPPoE).
+config PPTP
+ tristate PPTP (Point-to-Point Tunneling Protocol) (EXPERIMENTAL)
+ depends on EXPERIMENTAL PPP
+ help
+ Support for Microsoft Point-to-Point Tunneling Protocol.
+
+ See http://accel-pptp.sourceforge.net/ for information on
+ configuring PPTP clients and servers to utilize this driver.
+
config PPPOATM
tristate PPP over ATM
depends on ATM PPP
diff -uprN linux-2.6.16.orig/drivers/net/Makefile
linux-2.6.16.pptp/drivers/net/Makefile
--- linux-2.6.16.orig/drivers/net/Makefile 2006-06-18 00:51:34.0
+0400
+++ linux-2.6.16.pptp/drivers/net/Makefile 2006-06-18 00:57:02.0
+0400
@@ -118,6 +118,7 @@ obj-$(CONFIG_PPP_DEFLATE) += ppp_deflate
obj-$(CONFIG_PPP_BSDCOMP) += bsd_comp.o
obj-$(CONFIG_PPP_MPPE) += ppp_mppe.o
obj-$(CONFIG_PPPOE) += pppox.o pppoe.o
+obj-$(CONFIG_PPTP) += pppox.o pptp.o
obj-$(CONFIG_SLIP) += slip.o
ifeq ($(CONFIG_SLIP_COMPRESSED),y)
diff -uprN linux-2.6.16.orig/drivers/net/pptp.c
linux-2.6.16.pptp/drivers/net/pptp.c
--- linux-2.6.16.orig/drivers/net/pptp.c1970-01-01 03:00:00.0
+0300
+++ linux-2.6.16.pptp/drivers/net/pptp.c2006-06-18 01:30:40.0
+0400
@@ -0,0 +1,928 @@
+/*
+ * Point-to-Point Tunneling Protocol for Linux
+ *
+ * Authors: Kozlov D. ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include linux/string.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/netdevice.h
+#include linux/net.h
+#include linux/skbuff.h
+#include linux/init.h
+#include linux/ppp_channel.h
+#include linux/ppp_defs.h
+#include linux/if_ppp.h
+#include linux/if_pppox.h
+#include linux/notifier.h
+#include linux/file.h
+#include linux/proc_fs.h
+#include linux/in.h
+#include linux/ip.h
+#include linux/netfilter.h
+#include linux/netfilter_ipv4.h
+#include linux/workqueue.h
+#include linux/version.h
+
+#include net/sock.h
+#include net/protocol.h
+#include net/ip.h
+#include net/icmp.h
+#include net/route.h
+
+#include asm/uaccess.h
+
+#define PPTP_DRIVER_VERSION 0.7
+
+MODULE_DESCRIPTION(Point-to-Point Tunneling Protocol for Linux);
+MODULE_AUTHOR(Kozlov D. ([EMAIL PROTECTED]));
+MODULE_LICENSE(GPL);
+
+static int log_level=0;
+static int min_window=5;
+static int max_window=100;
+module_param(min_window,int,5);
+MODULE_PARM_DESC(min_window,Minimum sliding window size (default=3));
+module_param(max_window,int,100);
+MODULE_PARM_DESC(max_window,Maximum sliding window size (default=100));
+module_param(log_level,int,0);
+
+static struct proc_dir_entry* proc_dir;
+
+#define HASH_SIZE 16
+#define HASH(addr) ((addr^(addr4))0xF)
+static DEFINE_RWLOCK(chan_lock);
+static struct pppox_sock *chans[HASH_SIZE];
+
+static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb);
+static int read_proc(char *page, char **start, off_t off,int count,
+ int *eof, void *data);
+static int __pptp_rcv(struct pppox_sock *po,struct sk_buff *skb,int new);
+
+static struct ppp_channel_ops pptp_chan_ops= {
+ .start_xmit = pptp_xmit,
+};
+
+/* gre header structure: */
+
+#define PPTP_GRE_PROTO 0x880B
+#define PPTP_GRE_VER0x1
+
+#define PPTP_GRE_FLAG_C0x80
+#define PPTP_GRE_FLAG_R0x40
+#define PPTP_GRE_FLAG_K0x20
+#define PPTP_GRE_FLAG_S0x10
+#define PPTP_GRE_FLAG_A0x80
+
+#define PPTP_GRE_IS_C(f) ((f)PPTP_GRE_FLAG_C)
+#define PPTP_GRE_IS_R(f) ((f)PPTP_GRE_FLAG_R)
+#define PPTP_GRE_IS_K(f) ((f)PPTP_GRE_FLAG_K)
+#define PPTP_GRE_IS_S(f) ((f)PPTP_GRE_FLAG_S)
+#define PPTP_GRE_IS_A(f) ((f)PPTP_GRE_FLAG_A)
+
+struct pptp_gre_header {
+ u_int8_t flags; /* bitfield */
+ u_int8_t ver;/* should be PPTP_GRE_VER (enhanced
GRE) */
+ u_int16_t protocol;
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
I assume you are talking about using TCP_NODELAY as a socket option within the LDM software. I could give that a try. There is a lot of traffic on this node, on the order of 2000 packets in and out per second, so the tcpdump output will grow pretty fast. How long a tcpdump would be useful, and what options would you suggest? I should also note that my network interfaces are Intel, using the latest e1000 driver. Andrew Morton wrote: On Fri, 16 Jun 2006 09:01:23 -0700 Harry Edmon [EMAIL PROTECTED] wrote: I have a system with a strange network performance degradation from 2.6.11.12 to most recent kernels including 2.6.16.20 and 2.6.17-rc6. The system is has Dual single core Xeons with hyperthreading on. The application is the LDM system from UCAR/Unidata (http://www.unidata.ucar.edu/software/ldm). This system requests weather data from a variety of systems using RPC calls over a reserved TCP port (388), puts them into a memory mapped queue file, and then sends the data out to a variety of downstream requesting systems, again using RPC calls. When the load is heavy, the 2.6.16.20 kernel falls way behind with the data ingestion. The 2.6.11.12 kernel does not. I have tried an experiment with a 2.6.17-rc6 system where it just does the ingestion, and not the downstream distribution, and it is able to keep up. I would really appreciate any pointers as to where the problem may be and how to diagnose it. I have attached the config files from both kernels and the sysctl.conf file I am using. I have also included the output from netstat -s on the 2.6.16.20 system during a time when it was having problems. (added netdev) A quick grep indicates that it isn't using TCP_NODELAY - we've had problems with that in the past. Perhaps a tcpdump of the net traffic will help to determine what's going on. -- Dr. Harry EdmonE-MAIL: [EMAIL PROTECTED] 206-543-0547 [EMAIL PROTECTED] Dept of Atmospheric Sciences FAX:206-543-0308 University of Washington, Box 351640, Seattle, WA 98195-1640 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
On Sat, 17 Jun 2006 16:23:34 -0700 Harry Edmon [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Fri, 16 Jun 2006 09:01:23 -0700 Harry Edmon [EMAIL PROTECTED] wrote: I have a system with a strange network performance degradation from 2.6.11.12 to most recent kernels including 2.6.16.20 and 2.6.17-rc6. The system is has Dual single core Xeons with hyperthreading on. The application is the LDM system from UCAR/Unidata (http://www.unidata.ucar.edu/software/ldm). This system requests weather data from a variety of systems using RPC calls over a reserved TCP port (388), puts them into a memory mapped queue file, and then sends the data out to a variety of downstream requesting systems, again using RPC calls. When the load is heavy, the 2.6.16.20 kernel falls way behind with the data ingestion. The 2.6.11.12 kernel does not. I have tried an experiment with a 2.6.17-rc6 system where it just does the ingestion, and not the downstream distribution, and it is able to keep up. I would really appreciate any pointers as to where the problem may be and how to diagnose it. I have attached the config files from both kernels and the sysctl.conf file I am using. I have also included the output from netstat -s on the 2.6.16.20 system during a time when it was having problems. (added netdev) A quick grep indicates that it isn't using TCP_NODELAY - we've had problems with that in the past. Perhaps a tcpdump of the net traffic will help to determine what's going on. [ edit, edit - please don't top-post ] I assume you are talking about using TCP_NODELAY as a socket option within the LDM software. I could give that a try. The use of TCP_NODELAY caused problems with the JVM debugger. I'm not suggesting that enabling it will fix anything here. There is a lot of traffic on this node, on the order of 2000 packets in and out per second, so the tcpdump output will grow pretty fast. How long a tcpdump would be useful, and what options would you suggest? I don't know, frankly - first one needs to develop some sort of theory, then use the diagnostic tools to prove or disprove that theory. And I don't have a theory. I guess a simple one-second bare `tcpdump -i eth0' would be a starting point. Perhaps compare the output of that with the output from a correctly-operating kernel, see if anything suggests itself. That might also give us something which the networking developers can use. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: enable shared key authentication
On Fri, 2006-06-16 at 20:50 +0100, Daniel Drake wrote:
I recently patched softmac to enable shared key authentication. This small
patch
will enable crazy or unfortunate bcm43xx users to use this new capability.
Meaning that _until now_, softmac couldn't do Shared Key auth??? That
might explain a few NM bugs I think I've seen floating around.
Dan
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3599,6 +3599,10 @@ static void bcm43xx_ieee80211_set_securi
secinfo-encrypt = sec-encrypt;
dprintk(KERN_INFO PFX.encrypt = %d\n, sec-encrypt);
}
+ if (sec-flags SEC_AUTH_MODE) {
+ secinfo-auth_mode = sec-auth_mode;
+ dprintk(KERN_INFO PFX.auth_mode = %d\n, sec-auth_mode);
+ }
if (bcm-initialized !bcm-ieee-host_encrypt) {
if (secinfo-enabled) {
/* upload WEP keys to hardware */
-
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: Network performance degradation from 2.6.11.12 to 2.6.16.20
Andrew Morton wrote: On Sat, 17 Jun 2006 16:23:34 -0700 Harry Edmon [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Fri, 16 Jun 2006 09:01:23 -0700 Harry Edmon [EMAIL PROTECTED] wrote: I have a system with a strange network performance degradation from 2.6.11.12 to most recent kernels including 2.6.16.20 and 2.6.17-rc6. The system is has Dual single core Xeons with hyperthreading on. The application is the LDM system from UCAR/Unidata (http://www.unidata.ucar.edu/software/ldm). This system requests weather data from a variety of systems using RPC calls over a reserved TCP port (388), puts them into a memory mapped queue file, and then sends the data out to a variety of downstream requesting systems, again using RPC calls. When the load is heavy, the 2.6.16.20 kernel falls way behind with the data ingestion. The 2.6.11.12 kernel does not. I have tried an experiment with a 2.6.17-rc6 system where it just does the ingestion, and not the downstream distribution, and it is able to keep up. I would really appreciate any pointers as to where the problem may be and how to diagnose it. I have attached the config files from both kernels and the sysctl.conf file I am using. I have also included the output from netstat -s on the 2.6.16.20 system during a time when it was having problems. (added netdev) A quick grep indicates that it isn't using TCP_NODELAY - we've had problems with that in the past. Perhaps a tcpdump of the net traffic will help to determine what's going on. [ edit, edit - please don't top-post ] I assume you are talking about using TCP_NODELAY as a socket option within the LDM software. I could give that a try. The use of TCP_NODELAY caused problems with the JVM debugger. I'm not suggesting that enabling it will fix anything here. There is a lot of traffic on this node, on the order of 2000 packets in and out per second, so the tcpdump output will grow pretty fast. How long a tcpdump would be useful, and what options would you suggest? I don't know, frankly - first one needs to develop some sort of theory, then use the diagnostic tools to prove or disprove that theory. And I don't have a theory. I guess a simple one-second bare `tcpdump -i eth0' would be a starting point. Perhaps compare the output of that with the output from a correctly-operating kernel, see if anything suggests itself. That might also give us something which the networking developers can use. - 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 Does this fix it? # sysctl -w net.ipv4.tcp_abc=0 - 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: tg3 timeouts with 2.6.17-rc6
From: Michael Chan [EMAIL PROTECTED] Date: Sat, 17 Jun 2006 11:23:28 -0700 David, Here's the patch if you haven't already made one: [TG3]: Disable TSO by default on 5780 class chips. Sorry, I didn't get a chance to push this into 2.6.17 in time. I will push it into the first 2.6.17.x -stable release. - 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: updated [Patch 1/1] AF_UNIX Datagram getpeersec
On 6/17/06, James Morris [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006, Stephen Hemminger wrote: This is so short, it would make sense to put it in scm.h and why not have it return the value instead of call by reference? Same goes for selinux_get_inode_sid Actually, all of the SELinux API functions are like this, and I'm not sure why for void return methods (it's a good idea when they return errnos). Yes, the reason I used void return method is consistency with the remaining SELinux API functions. Once this area has settled down (post 2.6.18), I'm planning to do some cleanups for this API anyway, and can fix these all at the same time. OK. Thanks, Catherine - 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 2.6.18 1/3] tg3: Remove unnecessary tx_lock
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 05 Jun 2006 12:47:23 -0700 Remove tx_lock where it is unnecessary. tg3 runs lockless and so it requires interrupts to be disabled and sync'ed, netif_queue and NAPI poll to be stopped before the device can be reconfigured. After stopping everything, it is no longer necessary to get the tx_lock. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, 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
Re: [PATCH 2.6.18 2/3] tg3: Convert to non-LLTX
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 05 Jun 2006 12:47:32 -0700 Herbert Xu pointed out that it is unsafe to call netif_tx_disable() from LLTX drivers because it uses dev-xmit_lock to synchronize whereas LLTX drivers use private locks. Convert tg3 to non-LLTX to fix this issue. tg3 is a lockless driver where hard_start_xmit and tx completion handling can run concurrently under normal conditions. A tx_lock is only needed to prevent netif_stop_queue and netif_wake_queue race condtions when the queue is full. So whether we use LLTX or non-LLTX, it makes practically no difference. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] [NET]: Add NETIF_F_GEN_CSUM and NETIF_F_ALL_CSUM
From: Herbert Xu [EMAIL PROTECTED] Date: Tue, 13 Jun 2006 21:25:11 +1000 [NET]: Add NETIF_F_GEN_CSUM and NETIF_F_ALL_CSUM The current stack treats NETIF_F_HW_CSUM and NETIF_F_NO_CSUM identically so we test for them in quite a few places. For the sake of brevity, I'm adding the macro NETIF_F_GEN_CSUM for these two. We also test the disjunct of NETIF_F_IP_CSUM and the other two in various places, for that purpose I've added NETIF_F_ALL_CSUM. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied, thanks Herbert. - 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: [2/2] [BRIDGE]: Add support for NETIF_F_HW_CSUM devices
From: Herbert Xu [EMAIL PROTECTED] Date: Tue, 13 Jun 2006 21:25:43 +1000 [BRIDGE]: Add support for NETIF_F_HW_CSUM devices As it is the bridge will only ever declare NETIF_F_IP_CSUM even if all its constituent devices support NETIF_F_HW_CSUM. This patch fixes this by supporting the first one out of NETIF_F_NO_CSUM, NETIF_F_HW_CSUM, and NETIF_F_IP_CSUM that is supported by all constituent devices. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Also applied, thanks a lot! - 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
