From: Randy Dunlap <[EMAIL PROTECTED]>
Date: Tue, 24 Oct 2006 21:24:58 -0700
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Correct message typo/spello.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Applied, thanks a lot Randy.
-
To unsubscribe from this list: send the line "unsubscribe net
From: Gavin McCullagh <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2006 09:47:26 +0100
> When using H-TCP with a single flow on a 500Mbit connection (or less
> actually), alpha can exceed 65000, so alpha needs to be a u32.
>
> Signed-off-by: Gavin McCullagh <[EMAIL PROTECTED]>
> Signed-off-by: Doug Leit
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2006 10:52:29 -0700
> Doug Leith observed a discrepancy between the version of CUBIC described
> in the papers and the version in 2.6.18. A math error related to scaling
> causes Cubic to grow too slowly.
>
> Patch is from "Sangtae Ha"
On Wednesday 25 October 2006 10:05 pm, Randy.Dunlap wrote:
> >
> > ... MII should still depend on ETHERNET, right?
> > Just not limited to 10/100 Ethernet.
>
> There is no such config symbol. NET_ETHERNET means 10/100 ethernet.
> Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use
On Wed, Oct 25, 2006 at 11:08:43AM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> If user asks for a congestion control type with setsockopt() then it
> may be available as a module not included in the kernel already.
> It should be autoloaded if needed. This is done already when
> the de
Re: registering as a real protocol - yes this I have been going on about
for a while. This needs a few changes in how things work:
1. Register as a real protocol.
2. Change drivers to use netif_rx to receive frames (will also be more
efficient)
I would also like to see:
Drivers to use register_n
David Brownell wrote:
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
The other parts are right, this isn't.
Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit
On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote:
> Doing this will slow down the qdisc - it does already run an external
> classifier first if you install one. On typical laptops performance is
> not a problem, but one common usage does have problems. The performance
> of a wireless ho
The e100 fix finally fixes the netconsole problems.
The e1000 fixes look pretty safe, but don't have hardware at the
moment to test. A non-Intel list member verified the e1000 stuff at
least works for him.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/j
On Wed, Oct 25, 2006 at 11:38:38AM +0200, Michael Buesch wrote:
> On Wednesday 25 October 2006 02:37, John W. Linville wrote:
> > Michael,
> >
> > It looks like you have a patch that I don't have, one that moves the
> > netif_tx_disable and spin_lock_irqsave outside of the "if (badness >
> > BADNE
Doing this will slow down the qdisc - it does already run an external
classifier first if you install one. On typical laptops performance is
not a problem, but one common usage does have problems. The performance
of a wireless home gateway based on a simple linux kernel configuration
(NAT, iptables
It's not possible to 'negotiate keys at the beginning' - since there is
no indication of a new station joining an IBSS. The first you ever know
about a station joining an IBSS is when you receive a frame from that
station.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
The Wi-Fi alliance's test plans for their WMM specification are written
assuming you use certain specific DSCP values. Since WMM is the only QoS
mechanism that is widely used with 802.11 I followed the WMM values in
the default 802.11 qdisc implementation. Most windows 802.11 drivers do
the same th
On Wed, 2006-10-25 at 23:48, Jouni Malinen wrote:
> On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote:
>
> > I am reading the 802.11i IBSS spec and
> > trying to find if it is OK to add patches to d80211 to support this feature.
>
> Large parts of this will be outside d80211, but yes, I th
On Mon, 2006-10-23 at 10:09, Zang Roy-r61911 wrote:
> On Thu, 2006-09-21 at 12:46, Jeff Garzik wrote:
>
> > you should have a chip structure, that contains two structs (one for
> > each interface/port)
> >
> Jeff,
>
> I updated the code according to all your feedback and post it here
>
> http:
On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote:
> Considering that it is possibly and may be desirable to attach a
> different qdisc than the built-in multiband qdisc, it might also
> make sense to split the 80211 specific classification in a seperate
> classifier module to allow s
Hi,
The following eleven patches have all been queued in -mm for quite some
time; the only change is that one suggestion by Pavel Roskin (to remove the
"RevA" part of the new ID for hostap_cs.c) is implemented. Please let me
know if there are any objections to any of these patches; if not, I'll
su
On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to CONFIG_MII ... since it's completely legit to
> > use usbnet with peripherals that don't need MII
From: Dominik Brodowski <[EMAIL PROTECTED]>
Date: Sun, 2 Jul 2006 21:21:51 +0200
Subject: [PATCH] pcmcia: add more IDs to hostap_cs.c
As a replacement for the broad manufactor/card ID match we commented out
because of conflicts with pcnet_cs, add two product ID matches.
Signed-off-by: Dominik Bro
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > The other parts are right, this isn't.
> >
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to CONFIG_MII ... since it's completely legit to
> >
Simon Barber wrote:
> Pfifo_fast does not make sense because the 802.11 qdisc already
> categorizes the frames based on DSCP. The better thing would be to
> extract the pfifo qdisc so that it does not require NET_SCHED, but this
> is more work.
This patch should be enough to use it without NET_SCH
Simon Barber wrote:
> Pfifo_fast does not make sense because the 802.11 qdisc already
> categorizes the frames based on DSCP. The better thing would be to
> extract the pfifo qdisc so that it does not require NET_SCHED, but this
> is more work.
It wouldn't really hurt though since all frames queue
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECT
On Wed, 25 Oct 2006 18:34:17 -0400
"Injong Rhee" <[EMAIL PROTECTED]> wrote:
> Not sure why the slow start for cubic is slower than the others.
> We will check on this.
>
I think it is because cubic initializes with a ssthresh of 100,
and others leave ssthresh uninitialized until the first loss.
Patrick McHardy wrote:
> David Kimdon wrote:
>
>>wme.c needs a generic fifo qdisc for each hardware queue. Switch
>>wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
>>removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
>>IEEE 802.11 in any way.
>>
>>-#de
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any msleep(
On Wed, Oct 25, 2006 at 03:41:50PM -0700, David Kimdon wrote:
>
> I don't actually know the implications of that first hunk where we do
> "arc4" -> "ecb(arc4)". I look though the various commits by Herbert
> Xu and that appeared to be the right thing.
Basically if you encrypt/decrypt more than a
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
> The other parts are right, this isn't.
>
> Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> according to CONFIG_MII ... since it's completely legit to
> use usbnet with peripherals that don't need MII.
Ugh. OK. How's this
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
> Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> according to CONFIG_MII ... since it's completely legit to
> use usbnet with peripherals that don't need MII.
---
From: Randy Dunlap <[EMAIL PROTECTED]>
usbnet driver should
Auke Kok wrote:
> Allthough the spec itself didn't talk about phy reset times, I've ran this
> patch with
> some debugging output on a few boxes and did some speed/duplex settings,
> and the PHY
> reset returned succesfull after the very first mdio_read, which is before
> any msleep(10)
> is execut
David Kimdon wrote:
> wme.c needs a generic fifo qdisc for each hardware queue. Switch
> wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
> removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
> IEEE 802.11 in any way.
>
> -#define CHILD_QDISC_OPS pfifo_q
Stephen Hemminger wrote:
> If user asks for a congestion control type with setsockopt() then it
> may be available as a module not included in the kernel already.
> It should be autoloaded if needed. This is done already when
> the default selection is change with sysctl, but not when application
Doug Leith observed a discrepancy between the version of CUBIC described
in the papers and the version in 2.6.18. A math error related to scaling
causes Cubic to grow too slowly.
Patch is from "Sangtae Ha" <[EMAIL PROTECTED]>. I validated that
it does fix the problems.
See the following to show b
The purpose of this patch is to fix the compile-time warnings usch as:
warning: 'crypto_cipher_encrypt' is deprecated (declared at
include/linux/crypto.h:842)
I have tested static WEP and it still works after this change.
AECS/CCM and TKIP I am assuming work as well.
I don't actually know the i
Not sure why the slow start for cubic is slower than the others.
We will check on this.
- Original Message -
From: "Stephen Hemminger" <[EMAIL PROTECTED]>
To: "Douglas Leith" <[EMAIL PROTECTED]>; "Sangtae Ha" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, October 25, 2006 2:02 PM
Subject: TC
> @@ -94,6 +95,7 @@ config USB_RTL8150
>
> config USB_USBNET
> tristate "Multi-purpose USB Networking Framework"
> + select MII
> ---help---
> This driver supports several kinds of network links over USB,
> with "minidrivers" built around a common network driver c
If user asks for a congestion control type with setsockopt() then it
may be available as a module not included in the kernel already.
It should be autoloaded if needed. This is done already when
the default selection is change with sysctl, but not when application
requests via sysctl.
Only reser
From: Randy Dunlap <[EMAIL PROTECTED]>
USB network drivers that use mii_*() interfaces should
cause those interfaces to be built. Or depend on them,
but this is what all drivers/net/ drivers do.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/usb/net/Kconfig |3 +++
1 file chang
I ran some congestion window tests against 2.6.19-rc3.
For congestion window graphs see:
http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/
The connection was a single flow with a 500ms RTT and a
100Mbit slowest link speed.
BIC OK
CUBIC OK (after p
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless
Auke Kok <[EMAIL PROTECTED]> :
[...]
> okay, I don't think this is needed at all:
>
> Allthough the spec itself didn't talk about phy reset times, I've ran this
> patch with some debugging output on a few boxes and did some speed/duplex
> settings, and the PHY reset returned succesfull after the
On Wed, 2006-10-25 at 13:43 -0400, Luis R. Rodriguez wrote:
> I guess my hope was that d80211 would just be more than a softmac
> implementation. When I hear wireless stack I don't think "softmac
> implementation", I think a robust set of headers and device
> definitions which all wireless devices
On Wed, 2006-10-25 at 08:48 -0700, Jouni Malinen wrote:
> > 1. for the d80211 part: I don't think there will be much efforts.
> >We may add a group key to each sta_info for decrypting multicast data
> > from that STA.
> >And in RX path, we need to add code to select the correct group key
Auke Kok wrote:
Francois Romieu wrote:
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of
iterations
- put the
On Wed, Oct 25, 2006 at 10:11:24AM -0500, Linas Vepstas wrote:
>
> > Also we have to add following if statement in beginning of s2io_isr().
Done, below,
> > If it is ok to do BAR0 read/write in error_detected() then patch is OK.
I re-wrote that section to avoid doing I/O. It seems to work well
Francois Romieu wrote:
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of iterations
- put the break on a line of
One area that needs work is the 802.11 qdisc - there is no provision in
the current implementation for queueing certain frames because the
802.11 link is not ready to traqnsmit them yet, while letting other
frames through.
E.G. for normal client mode links it would be nice for the qdisc to
allow m
On 10/25/06, Michael Chan <[EMAIL PROTECTED]> wrote:
This confirms that it's some kind of interrupt problem as David had
suggested, at least on eth2. You can try booting with "noapic" to see
if it works if you haven't got the patch from Adrian Bunk yet.
No joy. Here's the dmesg after boot w/
On Wed, Oct 25, 2006 at 12:17:02PM -0700, David Kimdon wrote:
> That is how I originally had the patch, but then had a question about
> increasing structure size so I dropped flags to u16 or u8 for
> structures that were made larger by the bitfield removal.
On non-x86 platforms, u16 and u8 generat
On Wed, Oct 25, 2006 at 03:01:29PM -0400, Jeff Garzik wrote:
> On Wed, Oct 25, 2006 at 11:42:44AM -0700, David Kimdon wrote:
> > Continue d80211 bitfield removal. In general, compilers have
> > difficulty generating efficient code for bitfields. This patchset
> > removes all bitfields from includ
Anders Grafstrom <[EMAIL PROTECTED]> :
[...]
> I'm thinking something like this patch.
I do not have the spec for the max duration at hand but it makes sense.
Can you:
- decrease the duration of each sleep and increase the count of iterations
- put the break on a line of its own
- add a Signed-of
On Wed, Oct 25, 2006 at 11:42:44AM -0700, David Kimdon wrote:
> Continue d80211 bitfield removal. In general, compilers have
> difficulty generating efficient code for bitfields. This patchset
> removes all bitfields from include/net/d80211.h.
>
> I converted the 1 bit bitfields into a bit in a
Both one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TX_STATUS_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless
All twelve one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_HW_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
All four one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_CONF_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless-
All one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TXCTL_* definitions. The
multiple bit members were converted to u8, s8 or u16 as appropriate.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
Continue d80211 bitfield removal. In general, compilers have
difficulty generating efficient code for bitfields. This patchset
removes all bitfields from include/net/d80211.h.
I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags
structure member. Larger bitfields I converted into
All three one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_KEY_* definitions. The 8 bit
keyidx bitfield is converted to type s8.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
=
tmp is unused.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wireless-dev/net/d80211/ieee80211.c
@@ -3843,7 +3843,7 @@ void ieee80211_r
On 10/24/06, Michael Wu <[EMAIL PROTECTED]> wrote:
On Tuesday 24 October 2006 18:03, Luis R. Rodriguez wrote:
> 1. Anyone working on completing FullMAC support on d80211?
That doesn't really make sense. Fullmac devices should just use WE or cfg80211
because they, for the most part, do what d80211
Shouldn't the e100 driver wait for PHY reset to complete before
proceeding in e100_set_settings()?
I'm asking because the interface (82551) sometimes ends up in loopback
when I try to set AUTONEG.
I'm thinking something like this patch.
Anders
--- linux-2.6.18.orig/drivers/net/e100.c20
On Wed, 2006-10-25 at 09:02 -0400, Richard Bollinger wrote:
> # ethtool -t eth2
> The test result is FAIL
> The test extra info:
> nvram test (online) 0
> link test (online) 1
> register test (offline) 0
> memory test(offline) 0
> loopback test (off
Jeff Garzik wrote:
On Tue, Oct 24, 2006 at 09:35:49PM -0700, Randy Dunlap wrote:
Please grep for sysfs_create_bin_file, you will find plenty of examples.
Hm, I thought that sysfs binary files were supposed to be
for "transparent" blobs of data, not for structured data.
E.g., a "firmwa
Hi,
> +#ifdef CONFIG_PPC_64K_PAGES
> + /* To support 64k pages we must round to 64k page boundary */
> + epas->kernel.addr =
> + ioremap((paddr_kernel & 0x), PAGE_SIZE) +
> + (paddr_kernel & 0x);
> +#else
> epas->kernel.addr = ioremap(padd
On Tue, 24 Oct 2006 11:50:19 +0200
Ingo Oeser <[EMAIL PROTECTED]> wrote:
> Hi Stephen,
>
> Stephen Hemminger schrieb:
> > Add ability to take old raw dumps from a file and decode them.
> > It is kind of limited because you still need to have same device
> > as the raw file, but useful for maintai
On 10/25/06, Jiri Benc <[EMAIL PROTECTED]> wrote:
On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote:
> Sure -- we can have on the ieee80211_conf struct an array of all
> regulatory domains stack values that the device supports
> (REGDOMAIN_FCC or 0x10 for FCC for example) if the develop
On Wed, 25 Oct 2006 17:51:28 +0200
Daniel Lezcano <[EMAIL PROTECTED]> wrote:
> Hi Stephen,
>
> currently the work to make the container enablement into the kernel is
> doing good progress. The ipc, pid, utsname and filesystem system
> ressources are isolated/virtualized relying on the namespace
Hello,
the build with the attached .config failed, make ends with:
...
LD arch/i386/boot/compressed/vmlinux
OBJCOPY arch/i386/boot/vmlinux.bin
HOSTCC arch/i386/boot/tools/build
BUILD arch/i386/boot/bzImage
Root device is (3, 8)
Boot sector 512 bytes.
Setup is 4714 bytes.
System is
Hi Stephen,
currently the work to make the container enablement into the kernel is
doing good progress. The ipc, pid, utsname and filesystem system
ressources are isolated/virtualized relying on the namespaces concept.
But, there is missing the network virtualization/isolation. Two
approache
On Wed, Oct 25, 2006 at 04:54:41PM +0800, Hong Liu wrote:
> I am reading the 802.11i IBSS spec and
> trying to find if it is OK to add patches to d80211 to support this feature.
Large parts of this will be outside d80211, but yes, I think d80211
should be made ready to support this (mainly in the
On 10/24/06, Anand Kumria <[EMAIL PROTECTED]> wrote:
On Mon, 23 Oct 2006 18:47:25 -0400, Luis R. Rodriguez wrote:
> ieee80211_regdomains
>
> Breaks down regulatory domains into data structures which allow
> drivers to share channel and power contraints based on stack
> regulatory domain. This dr
Kenzo Iwami wrote:
Hi,
This problem originally occurred in a very large cluster system using snmp
for server management. About two servers panicked each day. The program I sent
is to reproduce this problem in a very short time. It does occur under normal
load when there is a lot of servers.
hmm
On 10/24/06, Anand Kumria <[EMAIL PROTECTED]> wrote:
On Mon, 23 Oct 2006 18:45:23 -0400, Luis R. Rodriguez wrote:
> iso3166-1
>
> ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names
> of countries and dependent areas. It was first published in 1974 by
> the International O
On Wed, Oct 25, 2006 at 02:29:33AM -0400, Ananda Raju wrote:
> Hi,
>
> s2io_card_down() will do few BAR0 read/write. As per
> pci-error-recovery.txt Documentation we are not supposed to do any new
> IO in error_detected().
Hmm, actually, its harmless to do further i/o. The s2io driver barks
(as
On 10/24/06, Johannes Berg <[EMAIL PROTECTED]> wrote:
On Tue, 2006-10-24 at 11:59 -0400, Luis R. Rodriguez wrote:
> also if we index based on alpha3 we get O(1)
> access to the elements. Will make these changes.
I wouldn't do that, it's bound to make the array size explode because
there'll be o
Hi,
>> This problem originally occurred in a very large cluster system using snmp
>> for server management. About two servers panicked each day. The program I
>> sent
>> is to reproduce this problem in a very short time. It does occur under normal
>> load when there is a lot of servers.
>
> hmm,
On 10/25/06, David Miller <[EMAIL PROTECTED]> wrote:
It's an interrupt routing problem for sure, Adrian Bunk
posted a potential fix to this poster an hour or so
ago.
I'm running with arch=i386 and the only related postings I see are for
x86_64 :-(.
-
To unsubscribe from this list: send the line
Physical pages are used instead of 16kB contiguous buffers for the
skb frags. And we also put as much fragments as possible in any page
so that we do not have to allocate a page for every fragments.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
Signed-off-by: Andrew J. Gallatin <[EMAIL PROTECTED
The following patch reworks the myri10ge driver to use physical pages for skb
allocation. A similar patch has been submitted about a month ago within our LRO
patches. The LRO code won't be sent here since we are waiting for the core
stack to implement a generic LRO.
Please consider this single
On Wednesday 25 October 2006 10:54, Hong Liu wrote:
> 2. wpa_supplicant: this is the big part, we need to implement the
> authenticator
>in it. Not sure how much efforts needed?
Well, I think that should go together with a merge of wpa_supplicant
with hostapd (which I think is desired anyway)
On 10/25/06, Michael Chan <[EMAIL PROTECTED]> wrote:
...
Can you cat /proc/interrupts a few times to see if the interrupt
counts on eth1 and eth2 are increasing?
# grep eth /proc/interrupts
9: 0 0 0 0IO-APIC-edge eth2
16: 177724 0 371238
* Ben Greear | 2006-10-23 17:44:24 [-0700]:
>Since IOCTLs are out of favor these days, what would be
>a preferred way to get a block of binary data out of the
>kernel?
I suggest netlink socket for that purpose! Netlink scales also well if the
amount of data "surprisedly" rise.
>Thanks,
>Ben
HGN
This patch fixes the 64K page support
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_phyp.h | 14 +-
drivers/net/ehea/ehea_qmr.c | 13 +++--
3 files changed, 21 insertions(+), 8 deletions(-)
diff --g
This patch fixes kzalloc parameters (GFP_ATOMIC instead of GFP_KERNEL)
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index eb7d44d..4538c99 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_mai
On Wednesday 25 October 2006 00:39, Johannes Berg wrote:
> resulted in this:
>
> [10261.556773] BUG: sleeping function called from invalid context at
> kernel/mutex.c:86
Yeah, there are a few bugs of this type left and I know most of them. ;)
The stack should never call atomically into the drive
On Wednesday 25 October 2006 02:37, John W. Linville wrote:
> Michael,
>
> It looks like you have a patch that I don't have, one that moves the
> netif_tx_disable and spin_lock_irqsave outside of the "if (badness >
> BADNESS_LIMIT)" conditional.
>
> Could you pass that one along as well, or corre
Hi,
I am reading the 802.11i IBSS spec and
trying to find if it is OK to add patches to d80211 to support this feature.
For 802.11i IBSS to work, each STA assumes two roles: supplicant +
authenticator.
Usually in BSS network, authenticator is in AP.
The problem is the distribution of group keys.
On Wed, 2006-10-25 at 16:28 +0800, Hong Liu wrote:
> I'd prefer to let the stack tell the driver when there is new phase1 key
> generated.
Fine too, I guess.
> + u8 tkip_keylen;
What do you need that for? The driver should know whether it requested a
phase 1 or phase 2 key.
> + u8 tkip
When using H-TCP with a single flow on a 500Mbit connection (or less
actually), alpha can exceed 65000, so alpha needs to be a u32.
Signed-off-by: Gavin McCullagh <[EMAIL PROTECTED]>
Signed-off-by: Doug Leith <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp_htcp.c b/net/ipv4/tcp_htcp.c
index 6edfe
On Tue, 2006-10-24 at 17:10, Johannes Berg wrote:
> On Tue, 2006-10-24 at 16:38 +0800, Hong Liu wrote:
>
> > The first time when we set the TKIP key, we can set the phase1 key if
> > the driver requires.
>
> Right.
>
> > The problem is when IV16 wraps, who will generate the new phase1 key?
>
>
On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote:
> Sure -- we can have on the ieee80211_conf struct an array of all
> regulatory domains stack values that the device supports
> (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees
> the device has been certified to match t
91 matches
Mail list logo
