Someone any ideas regarding the following bug report,
which happened on
* a dual-Pentium-3 server with SMP enabled
* latest davem-2.6 (pulled yesterday)
* nfs-utils 1.0.10
* lock validation turned on
If this is not enough information please point out what
is missing.
--
From: Auke Kok <[EMAIL PROTECTED]>
Date: Thu, 02 Nov 2006 13:48:48 -0800
> the hang is caused by a bad eeprom bit. A script that fixes it for
> 82573-series with eeproms that need this bit fixed is attached to
> the bugreport. It detects the proper chipset and patches if required
> (uses ethtool).
On Thursday 02 November 2006 23:30, John W. Linville wrote:
> One big addition is the cfg80211/nl80211 stuff from Johannes. I'm not
> quite confident that the Kconfig stuff is right, but the code is there.
It doesn't seem to compile on my system:
net/built-in.o: In function `iw_send_thrspy_event'
I'm basically caught-up on merging for wireless-dev. Here is the URL,
just in case you forgot... :-)
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
This includes a pull from Michael Buesch for bcm43xx stuff, a fresh
pull from Jiri for stack stuff, the addition of
On Fri, Nov 03, 2006 at 01:46:31AM +0100, Johannes Berg wrote:
>
> > Ok, that one was wrong. But what is it doing in the public API? We need
> > to remove it from the public API and leave struct net_device *dev as the
> > parameter. adm8211 actually uses it and increases the tx_fifo_error
> > coun
In the softmac version of bcm43xx, the core scan logs whether each core is
enabled or disabled. This information is useless as one of the next steps
is to enable all cores. This patch removes this output from the log.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
These are more janit
It seems we don't have any protection when accessing the key.
The RX/TX path may acquire a key which can be freed by the
ioctl cmd.
I put a key_lock spinlock to protect all the accesses to the key
(whether the sta_info->key or ieee80211_sub_if_data->keys[]).
Don't find a good way to handle it :(
On Wed, Oct 25, 2006 at 03:28:03PM -0400, Jeff Garzik wrote:
> 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 larg
On Thu, 2 Nov 2006, David Brownell wrote:
> On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
>
> > It seems to lack the "select MII" at the USB_RTL8150 option that was in
> > Randy's first patch?
>
> I was just addressing the usbnet issues ... that driver doesn't
> use the usbnet framework
On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
> It seems to lack the "select MII" at the USB_RTL8150 option that was in
> Randy's first patch?
I was just addressing the usbnet issues ... that driver doesn't
use the usbnet framework.
- Dave
-
To unsubscribe from this list: send the li
2006/11/2, Eric Dumazet <[EMAIL PROTECTED]>:
zhou drangon a écrit :
> performance is great, and we are exciting at the result.
>
> I want to know why there can be so much improvement, can we improve
> epoll too ?
Why did you remove most of CC addresses but lkml ?
Dont do that please...
I seldom
On Thursday 02 November 2006 19:22, Johannes Berg wrote:
> Ok, that one was wrong. But what is it doing in the public API? We need
> to remove it from the public API and leave struct net_device *dev as the
> parameter. adm8211 actually uses it and increases the tx_fifo_error
> counter, but that's a
On Thu, Nov 02, 2006 at 12:29:12PM -0800, David Brownell wrote:
> On Wednesday 01 November 2006 11:15 pm, Greg KH wrote:
>
> > Argh, there were just too many different versions of these patches
> > floating around. Can you resend the final versions please?
>
> This should replace BOTH of Randy's
On Wed, Oct 18, 2006 at 03:44:05PM -0700, David Kimdon wrote:
> ieee80211_beacon_get() was already described. The doc entry in
> question describes ieee80211_get_buffered_bc().
>
> Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Applied to wireless-dev.
--
John W. Linville
[EMAIL PROTECTED]
-
T
On Mon, Oct 30, 2006 at 10:08:58AM -0800, David Kimdon wrote:
> On Thu, Oct 26, 2006 at 10:06:24AM +1000, Herbert Xu wrote:
> > If you're only encrypting/decrypting a single block then you should
> > use the cipher interface. So net/d80211/aes_ccm.c should do that
> > instead. See drivers/net/wir
On Wed, Oct 25, 2006 at 11:16:21AM -0700, David Kimdon wrote:
> tmp is unused.
Applied to wireless-dev.
--
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.kern
adm8211: fix suspend code
Apparently, I forgot to port the suspend and resume code in the
d80211 port of adm8211. Thanks to Johannes Berg for finding this.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
drivers/net/wireless/d80211/adm8211/adm8211.c | 19 ---
1 files change
> Ok, that one was wrong. But what is it doing in the public API? We need
> to remove it from the public API and leave struct net_device *dev as the
> parameter. adm8211 actually uses it and increases the tx_fifo_error
> counter, but that's a bit strange.
Fixed, and since, as always, netdev doesn
On Fri, 2006-11-03 at 00:09 +0100, Johannes Berg wrote:
> /* Return a pointer to network statistics data area for the given device. */
> -void * ieee80211_dev_stats(struct net_device *dev);
> +void *ieee80211_dev_stats(struct ieee80211_local *ieee80211_ptr);
Ok, that one was wrong. But what is i
On Wed, Nov 01, 2006 at 03:06:24PM +0100, Florian Westphal wrote:
> convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const.
Ahhh, I missed the start of threads.
Patch is useless because it changes one unbounded string function into
another unbounded string function.
> --- a/net/tipc/
On Thursday 02 November 2006 17:38, Johannes Berg wrote:
> Now, I tried to update adm8211 and rt2x00 as well, but faced some
> problems. adm8211 actually accesses the struct net_device and
> calls it's open() call! This is broken.
>
Good catch. Looks like I never updated the suspend/resume code pro
On 11/2/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
Please have Ethernet (and wireless) devices show up as eth%d. For the
master device, choose something else (mac%d ?).
If ultimately we're going to make wireless devices, as John puts it,
"1st class citizens" by making 802.11 a full proto
On Thu, 2006-11-02 at 14:34 -0800, Stephen Hemminger wrote:
> It makes 802.11 packet capture easier as well. Please don't invent yet
> another network access object for the master device.
Oh, but the master device doesn't get any packets you could capture. For
that, you need to add a monitor int
On Thu, 2 Nov 2006 13:27:59 -0800
"Simon Barber" <[EMAIL PROTECTED]> wrote:
> Perhaps the solution is to allow the prefix to be a kernel configuration
> item?
>
> Simon
All modern distro's support device naming stuff through hotplug.
Don't put effort into keeping the kernel defaults absolute.
On Thu, 02 Nov 2006 17:43:57 +0100
Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-11-02 at 08:33 -0800, Simon Barber wrote:
> > There are many reasons to have the master device - and many reasons not
> > to get rid of it. The only excpetion is when using a limited fullmac
> > card. Some
Andrew Morton wrote:
Begin forwarded message:
Date: Thu, 2 Nov 2006 06:41:04 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected
Tx Unit Hang
http://bugzilla.kernel.org/show_bug.cgi?id=7450
Summary: e1
On Thu, Nov 02, 2006 at 04:21:16PM -0500, Ivan Matveich wrote:
> On 11/2/06, Dan Williams <[EMAIL PROTECTED]> wrote:
> >Do you know which kernel version that patch first appeared in?
>
> It was committed on 1 Dec 2005, and 2.6.15 was released on 3 Jan 2006.
>
> >That would be a great idea, let us
Perhaps the solution is to allow the prefix to be a kernel configuration
item?
Simon
-Original Message-
From: Jiri Benc [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 10:39 AM
To: Sven-Haegar Koch
Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Simon Barber;
Jeff G
On Thursday 02 November 2006 13:47, Larry Finger wrote:
> These patches modify adm8211-d80211 to use the wireless statics added in
> patch 1.
>
> Signed-Off-By: Larry [EMAIL PROTECTED]>
ACK. I can put better values in later.
Thanks,
-Michael Wu
pgpduYKxxEeea.pgp
Description: PGP signature
On 11/2/06, Dan Williams <[EMAIL PROTECTED]> wrote:
Do you know which kernel version that patch first appeared in?
It was committed on 1 Dec 2005, and 2.6.15 was released on 3 Jan 2006.
That would be a great idea, let us know what the results are, especially
if you cna figure out which firmwa
On Thu, 2006-11-02 at 19:38 +0100, Jiri Benc wrote:
> On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote:
> > At least the ones used on my machines all do.
> > (Debian Sarge, Etch and Unstable)
> > The configfiles can be changed without problems to use any device name,
> > but needing
On Tuesday 31 October 2006 5:23 pm, Adrian Bunk wrote:
> select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n
Thing is, I'm seeing that get morphed inside Kconfig to "select MII" in
some cases ... the "if x != n" gets ignored, MII can't be deselected.
That looks to me like a Kconfig de
On Wednesday 01 November 2006 11:15 pm, Greg KH wrote:
> Argh, there were just too many different versions of these patches
> floating around. Can you resend the final versions please?
This should replace BOTH of Randy's patches. It addresses all the
issues I've heard raised, and resolves the r
[TG3]: Fix 2nd ifup failure on 5752M.
This fixes a bug reported in:
http://bugzilla.kernel.org/show_bug.cgi?id=7438
tg3_close() turns off the PHY if WoL and ASF are both disabled. On
the next tg3_open(), some devices such as the 5752M will not be
brought up correctly without a PHY reset early i
On Wed, 01 Nov 2006 21:44:18 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Tue, 31 Oct 2006 21:58:48 -0800
>
> > Some basic stuff is on the parent page
> > http://developer.osdl.org/shemminger/tcp
>
> Are you using tcptrace to gener
On 11/1/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
On Wed, Nov 01, 2006 at 06:12:41PM -0800, Nate Diller ([EMAIL PROTECTED]) wrote:
> Indesiciveness has certainly been an issue here, but I remember akpm
> and Ulrich both giving concrete suggestions. I was particularly
> interested in Andrew
Begin forwarded message:
Date: Thu, 2 Nov 2006 06:41:04 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected
Tx Unit Hang
http://bugzilla.kernel.org/show_bug.cgi?id=7450
Summary: e1000: eth0: e1000_clean
On Thu, 2006-11-02 at 13:30 -0500, Ivan Matveich wrote:
> On 11/2/06, Dan Williams <[EMAIL PROTECTED]> wrote:
> > It appears that the driver cannot talk to your card; see the "max tries
> > exceeded when issueing command". Did this card work previously with a
> > kernel? Can narrow down which ker
On Thursday 02 November 2006 19:48, Larry Finger wrote:
> These patches modify the rt2x00-d80211 family of drivers to use
> the wireless statics added in patch 1.
>
> Signed-Off-By: Larry [EMAIL PROTECTED]>
I will put the search for the correct values on my TODO list,
but that needs some heavy le
On Thursday 02 November 2006 19:46, Larry Finger wrote:
> These patches modify bcm43xx-d80211 to use the wireless statics added in
> patch 1.
>
> Signed-Off-By: Larry [EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> Please apply to wireless-dev
>
>
> Index: wire
These patches modify the rt2x00-d80211 family of drivers to use
the wireless statics added in patch 1.
Signed-Off-By: Larry [EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
===
--- wireless-dev.ori
These patches modify bcm43xx-d80211 to use the wireless statics added in patch
1.
Signed-Off-By: Larry [EMAIL PROTECTED]>
---
Please apply to wireless-dev
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- w
These patches modify adm8211-d80211 to use the wireless statics added in patch
1.
Signed-Off-By: Larry [EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
===
--- wireless-dev.orig/drivers/net/wireles
This patch modifies d80211 to support wireless statistics.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
---
John,
Please add to wireless-dev.
Larry
Index: wireless-dev/include/net/d80211.h
===
--- wireless-dev.orig/include/net/
On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote:
> At least the ones used on my machines all do.
> (Debian Sarge, Etch and Unstable)
> The configfiles can be changed without problems to use any device name,
> but needing to edit various files just for a kernel update would inhibt m
On Thu, 2006-11-02 at 11:09 -0500, Vlad Yasevich wrote:
> Meelis Roos wrote:
> >> Actually, I'm backing this one out, it creates new warnings because
> >> callers of this function pass in a "const" pointer.
> >
> > Yes, it now seems it's not so simple. Marking it non-const there would
> > mark the
On 11/2/06, Dan Williams <[EMAIL PROTECTED]> wrote:
It appears that the driver cannot talk to your card; see the "max tries
exceeded when issueing command". Did this card work previously with a
kernel? Can narrow down which kernels have problems and which don't?
It spontaneously stopped worki
This set of patches modifies the d80211 stack and the drivers that use it to support wireless
statistics.
1. Adds the necessary data and code to the d80211 routines.
2. Modifies bcm43xx-d80211 to conform.
3. Modifies adm8211-d80211 to conform.
4. Modifies the rt2x00-d80211 drivers to conform.
On Thu, 2006-11-02 at 14:32 +0200, Ville Nuorvala wrote:
> On 10/27/06 20:47, Sridhar Samudrala wrote:
> > On Tue, 2006-10-17 at 03:19 +0300, Ville Nuorvala wrote:
> >> As the IPv6 route lookup now also returns the selected source address
> >> there is no need for a separate source address lookup.
All,
This patch applies to the netfilter file nat_ip_snmp_basic.c
The algorithm now applies NAT to the complete IP address (and not only
the first byte)
It also recomputes the UDP checksum accordingly.
Please apply this patch to the 2.6.18.1 official release.
Many thanks to Remy Harel for his
Le 02.11.2006 18:02, Vlad Yasevich a écrit :
Nicolas DICHTEL wrote:
Hello,
Suppose that a host has autoconfiguration enabled. It will take RA to
autoconfigure an IPv6 address. For example,
2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64.
This host will create a route entry for this onlink prefix (dst
Nicolas DICHTEL wrote:
> Hello,
>
> Suppose that a host has autoconfiguration enabled. It will take RA to
> autoconfigure an IPv6 address. For example,
> 2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64.
> This host will create a route entry for this onlink prefix (dst:
> 2001:0db8:3008:c1ca::/64)
> in t
On Thu, 2006-11-02 at 08:33 -0800, Simon Barber wrote:
> There are many reasons to have the master device - and many reasons not
> to get rid of it. The only excpetion is when using a limited fullmac
> card. Some fullmac cards only support a single ethernet interface, so
> for these cards a single
I don't believe it makes sense to change the frame type except for the
master interface. The interface to an 802.11 MAC (the MAC-SAP) is very
similar to the interface to an 802.3 MAC. It is a 2 address format - not
3 or 4. The master interface is an internal part of the MAC, and here
802.11 frames
There are many reasons to have the master device - and many reasons not
to get rid of it. The only excpetion is when using a limited fullmac
card. Some fullmac cards only support a single ethernet interface, so
for these cards a single device may be OK, if we want to allow multiple
different appea
Hello,
Suppose that a host has autoconfiguration enabled. It will take RA to
autoconfigure an IPv6 address. For example,
2001:0db8:3008:c1ca:2d0:b7ff:febb:4aee/64.
This host will create a route entry for this onlink prefix (dst:
2001:0db8:3008:c1ca::/64)
in the MAIN table with the lifetime pre
On Wed, 2006-11-01 at 22:14 -0500, Ivan Matveich wrote:
> hardware: ibm thinkpad t30
> kernel: 2.6.18
> problem:
>
> airo(): Probing for PCI adapters
> ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
> ACPI: PCI Interrupt :02:02.0[A] -> Link [LNKC] -> GSI 11 (level,
> low) -> IRQ 11
> airo(e
On Thu, 2 Nov 2006, Jiri Benc wrote:
On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote:
This is not about the name that makes sense. I think using ethX names
for wireless devices is utterly stupid, but it's what all current upstream
drivers do, and at least for WE compat we'll have to
Meelis Roos wrote:
>> Actually, I'm backing this one out, it creates new warnings because
>> callers of this function pass in a "const" pointer.
>
> Yes, it now seems it's not so simple. Marking it non-const there would
> mark the it non-const in the whole family of sctp_state_fn_t and I'm not
> s
On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote:
> This is not about the name that makes sense. I think using ethX names
> for wireless devices is utterly stupid, but it's what all current upstream
> drivers do, and at least for WE compat we'll have to stick to it.
That's not true. Loo
Hi,
Florian Westphal wrote:
>> walter harms <[EMAIL PROTECTED]> wrote:
>>> These line
>>> + strcpy(bcbearer->media.name, "tipc-multicast");
>>> i gues that means tipc_bclink_name ?
>>
>> The idea was to change how things are done, not _what_ is being done.
>>
>>> an even more secure versio
On Thu, 2006-11-02 at 14:45 +, Christoph Hellwig wrote:
> I never said the name was related to WE - in fact there are tons of out of
> tree drivers with different names. The important bit is that upgrading a
> kernel adn changing the wireless stack must not change the device name.
Ah, but if
On Thu, Nov 02, 2006 at 03:32:34PM +0100, Johannes Berg wrote:
> On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote:
>
> > This is not about the name that makes sense. I think using ethX names
> > for wireless devices is utterly stupid, but it's what all current upstream
> > drivers do, a
Hi Johannes,
> On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote:
>
>> This is not about the name that makes sense. I think using ethX names
>> for wireless devices is utterly stupid, but it's what all current upstream
>> drivers do, and at least for WE compat we'll have to stick to it.
On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote:
> This is not about the name that makes sense. I think using ethX names
> for wireless devices is utterly stupid, but it's what all current upstream
> drivers do, and at least for WE compat we'll have to stick to it.
No, that's not true
On Thu, 2006-11-02 at 15:05 +0100, Jiri Benc wrote:
> - Single device is not as easy as it sounds. It would require rather
> invasive changes in the networking core or ugly hacks in d80211. I'm
> afraid this is something not achievable in a near future with current
> number of people working
On 11/02/06 16:18, YOSHIFUJI Hideaki wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 15:16:23 +0200), Ville
> Nuorvala <[EMAIL PROTECTED]> says:
>
>> On 11/02/06 14:59, YOSHIFUJI Hideaki wrote:
>>> In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:39:19 +0200), Ville
>>> Nuorva
On Thu, Nov 02, 2006 at 03:05:50PM +0100, Jiri Benc wrote:
> On Thu, 2 Nov 2006 12:16:57 +
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > The most important merge requirement is to not break userspace. That means
> > proper support of WE (hopefully via cfg80211), and a single ethX network
On Thu, Nov 02, 2006 at 12:16:57PM +, Christoph Hellwig wrote:
> The most important merge requirement is to not break userspace. That means
> proper support of WE (hopefully via cfg80211), and a single ethX network
> device. The second most important is proper smp support, or good code
> qua
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 15:16:23 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> On 11/02/06 14:59, YOSHIFUJI Hideaki wrote:
> > In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:39:19 +0200), Ville
> > Nuorvala <[EMAIL PROTECTED]> says:
> >
> >>read_unlo
On Thu, 2 Nov 2006 12:16:57 +
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> The most important merge requirement is to not break userspace. That means
> proper support of WE (hopefully via cfg80211), and a single ethX network
> device.
Sounds reasonable. Though:
- I don't think ethX is the a
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 14:46:43 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> > http://testlab.linux-ipv6.org/tahi-autorun.2/net-2.6_20061018/
>
> The host testlab.linux-ipv6.org doesn't seem to be visible to the
> outside world so could you post the results som
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:37:29 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> >From 6b9b468f1cf3f2897fbcda389e8c2514a69c4943 Mon Sep 17 00:00:00 2001
> From: Ville Nuorvala <[EMAIL PROTECTED]>
> Date: Thu, 2 Nov 2006 12:49:47 +0200
> Subject: [PATCH 5/6] IPv6: Im
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:35:10 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> >From b278633af228bcc986856f6492b02422c25656c7 Mon Sep 17 00:00:00 2001
> From: Ville Nuorvala <[EMAIL PROTECTED]>
> Date: Thu, 2 Nov 2006 12:47:54 +0200
> Subject: [PATCH 4/6] IPv6: Do
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:33:48 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> >From de1ad3df949303a1454ae0cdee0a599c0fc95e45 Mon Sep 17 00:00:00 2001
> From: Ville Nuorvala <[EMAIL PROTECTED]>
> Date: Thu, 2 Nov 2006 12:45:08 +0200
> Subject: [PATCH 3/6] IPv6: Al
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:31:34 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> >From e60ed41fb11793d16ffcbfd56b889e0bbf04ea88 Mon Sep 17 00:00:00 2001
> From: Ville Nuorvala <[EMAIL PROTECTED]>
> Date: Thu, 2 Nov 2006 12:43:50 +0200
> Subject: [PATCH 2/6] IPv6: Do
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:29:31 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> >From f9812eb0349f44f6374910ce38524f0c6f7ce8f4 Mon Sep 17 00:00:00 2001
> From: Ville Nuorvala <[EMAIL PROTECTED]>
> Date: Thu, 2 Nov 2006 12:40:38 +0200
> Subject: [PATCH 1/6] IPv6: Fi
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:27:05 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> the following incremental patches contain several fixes to ip6_tunnel.c.
> They are in chronological order, so the most critical one is
> unfortunately last. Many thanks to Tero Kauppin
In article <[EMAIL PROTECTED]> (at Thu, 02 Nov 2006 13:39:19 +0200), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> read_unlock(&ip6ip6_lock);
> - return 1;
> -
> + icmpv6_send(skb, ICMPV6_DEST_UNREACH,
> + ICMPV6_ADDR_UNREACH, 0, skb->dev);
> discard:
I'd argue this.
On 10/19/06 05:27, Mitsuru Chinen wrote:
Hello again Mitsuru-san,
I haven't yet had time to follow up on this issue and I would in fact
need some help to proceed.
> http://testlab.linux-ipv6.org/tahi-autorun.2/net-2.6_20061018/
The host testlab.linux-ipv6.org doesn't seem to be visible to the
o
On 10/27/06 20:47, Sridhar Samudrala wrote:
> On Tue, 2006-10-17 at 03:19 +0300, Ville Nuorvala wrote:
>> As the IPv6 route lookup now also returns the selected source address
>> there is no need for a separate source address lookup. In fact, the
>> source address selection needs to be moved to get
On Wed, Nov 01, 2006 at 10:31:19AM -0800, James Ketrenos wrote:
> The only merge requirement should be that merging d80211 doesn't break
> existing in-tree wireless drivers. We have that today -- you can have
> both stacks in the tree and running in parallel. With that, we have the
> ability to m
On Thu, 2006-11-02 at 10:56 +, Christoph Hellwig wrote:
> Yes, that is exatly the right way to go forward. The userspace interface
> is however more than just the WE ioctls. It's also that for every wireless
> card one single ethX device appears and not multiple devices with other
> names.
>From d9ecea2b1d88bc8702f70fbbca7cde2afb8312ee Mon Sep 17 00:00:00 2001
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Thu, 2 Nov 2006 13:07:35 +0200
Subject: [PATCH 6/6] IPv6: Fix infinite loop if no matching IPv6 tunnel found
If no matching IPv6 tunnel was found ip6ip6_rcv() would cause
ip6_inpu
>From 6b9b468f1cf3f2897fbcda389e8c2514a69c4943 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Thu, 2 Nov 2006 12:49:47 +0200
Subject: [PATCH 5/6] IPv6: Improve IPv6 tunnel error reporting
Log an error if the remote tunnel endpoint is unable to handle
tunneled packets.
Si
>From b278633af228bcc986856f6492b02422c25656c7 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Thu, 2 Nov 2006 12:47:54 +0200
Subject: [PATCH 4/6] IPv6: Don't allocate memory for Tunnel Encapsulation Limit
Option
Signed-off-by: Ville Nuorvala <[EMAIL PROTECTED]>
---
net/i
>From de1ad3df949303a1454ae0cdee0a599c0fc95e45 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Thu, 2 Nov 2006 12:45:08 +0200
Subject: [PATCH 3/6] IPv6: Allow link-local tunnel endpoints
Allow link-local tunnel endpoints if the underlying link is defined.
Signed-off-by: Vi
>From e60ed41fb11793d16ffcbfd56b889e0bbf04ea88 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Thu, 2 Nov 2006 12:43:50 +0200
Subject: [PATCH 2/6] IPv6: Do mandatory IPv6 tunnel endpoint checks in realtime
Doing the mandatory tunnel endpoint checks when the tunnel is set up
Hello,
the following incremental patches contain several fixes to ip6_tunnel.c.
They are in chronological order, so the most critical one is
unfortunately last. Many thanks to Tero Kauppinen for reporting that one!
The patches are sent as attachments as my mailer has at least previously
messed up
>From f9812eb0349f44f6374910ce38524f0c6f7ce8f4 Mon Sep 17 00:00:00 2001
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Thu, 2 Nov 2006 12:40:38 +0200
Subject: [PATCH 1/6] IPv6: Fix SIOCCHGTUNNEL bug in IPv6 tunnels
A logic bug in tunnel lookup could result in duplicate tunnels
when changing an exi
On Thu, Nov 02, 2006 at 09:49:01AM +0100, Johannes Berg wrote:
> I'm pretty sure I've said this like a dozen times but apparently it
> hasn't sunk in yet:
>
> The latest cfg80211/nl80211 code comes with WE compatibility code that
> users can disable if they want to, which, however, gives them the
Actually, I'm backing this one out, it creates new warnings because
callers of this function pass in a "const" pointer.
Yes, it now seems it's not so simple. Marking it non-const there would
mark the it non-const in the whole family of sctp_state_fn_t and I'm not
sure that's the best thing to
Sure. Evenso, I did test full make after the single compile was fine (still
have it in my scrollback so here it is). So did I do anything wrong here or
do we have some dependencies broken somewhere or what?
Never mind - I discovered the warning on one box with SCTP enabled in
config and tried
Johannes Berg wrote:
My goal is to remove WE from *all* drivers, even from the ancient
pre-802.11 and early 802.11 fullmac drivers, and leave WE merely as
another userspace interface for cfg80211, albeit with limitations that
the netlink interface nl80211 doesn't have.
Sounds good to me...
On Wed, 2006-11-01 at 21:55 -0500, Jeff Garzik wrote:
> Speaking specifically, Linus noted recently d80211 should maintain
> backwards compatibility with the WE userspace ABI, so that existing
> wireless tools keep working, and I definitely agree. For additional
> functionality/flexibility, I
Actually, I'm backing this one out, it creates new warnings because
callers of this function pass in a "const" pointer.
OK, fair enough. Will have a look.
Please test the complete build when doing warning fixes like
this in the future, thanks.
Sure. Evenso, I did test full make after the sin
On Wed, 2006-11-01 at 23:46 -0600, Larry Finger wrote:
> Has anyone used this patch, particularly with WPA encryption? When I try it,
> wpa_supplicant
> immediately uses 90+% of the cpu and never actually authenticates with my AP.
> I wonder if it is
> something with my system.
Unless wpa sup
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 02 Nov 2006 00:16:43 -0800 (PST)
> From: Meelis Roos <[EMAIL PROTECTED]>
> Date: Thu, 2 Nov 2006 09:29:16 +0200 (EET)
>
> >CC [M] net/sctp/sm_make_chunk.o
> > net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie':
> > net/sctp/sm_make_ch
On 2006-11-02, Meelis Roos wrote:
>> There should only be one space before the "void" in the patch,
>> your email client (or something else) put another space there.
>>
>> Also, your email client likes to turn lines containing only
>> spaces into empty lines, which also corrupts the patch.
>
> cg-d
There should only be one space before the "void" in the patch,
your email client (or something else) put another space there.
Also, your email client likes to turn lines containing only
spaces into empty lines, which also corrupts the patch.
cg-diff > file
and in pine 4.61 ^R read a file. So I
1 - 100 of 101 matches
Mail list logo
