On Tue, Oct 31, 2006 at 08:08:12AM +0100, Alexander Wirt ([EMAIL PROTECTED])
wrote:
> > > Run 2.6.19-rc3 or 2.6.18.2 or dig out the patch from last week.
> >
> > Thanks.
> > I hope debian maintainers will rebase it's tree eventually.
> Then please take sure that there is a bug report describing
Evgeniy Polyakov schrieb am Dienstag, den 31. Oktober 2006:
> On Mon, Oct 30, 2006 at 10:24:18PM -0800, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
> > Run 2.6.19-rc3 or 2.6.18.2 or dig out the patch from last week.
>
> Thanks.
> I hope debian maintainers will rebase it's tree eventually.
The
On Mon, Oct 30, 2006 at 10:24:18PM -0800, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> Run 2.6.19-rc3 or 2.6.18.2 or dig out the patch from last week.
Thanks.
I hope debian maintainers will rebase it's tree eventually.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line
Evgeniy Polyakov wrote:
sky2 from debian etch kernel (2.6.17-2) has stopped today after quite
big amount of traffic transferred (30MB/sec for about 3-4 hours).
rmmod/insmod does not help, reboot required.
Here is dmesg output:
Oct 31 06:40:07 kano kernel: NETDEV WATCHDOG: eth0: transmit timed o
There's a bug in the seqfile show operation for flowlabel objects, where
each hash chain is traversed cumulatively for each element. The following
function is called for each element of each chain:
static void ip6fl_fl_seq_show(struct seq_file *seq, struct ip6_flowlabel *fl)
{
while(fl)
sky2 from debian etch kernel (2.6.17-2) has stopped today after quite
big amount of traffic transferred (30MB/sec for about 3-4 hours).
rmmod/insmod does not help, reboot required.
Here is dmesg output:
Oct 31 06:40:07 kano kernel: NETDEV WATCHDOG: eth0: transmit timed out
Oct 31 06:40:07 kano ke
Dear All:
How about current IP100A, sundance.c status? Should it be put into kernel or
not?
Is there any sentence should I need to modify?
Thanks for your help!
Jesse Huang
- Original Message -
From: "Jesse Huang" <[EMAIL PROTECTED]>
To: ; ;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[
On Mon, Oct 30, 2006 at 09:30:24AM -0800, Auke Kok wrote:
> >Even if the total lock time can be reduced, it's possible that interrupt
> >handler is executed while the interrupted code is still holding the
> >semaphore.
> >I think your method only decrease the frequency of this problem.
> >Why does
Hi Sridhar:
On Mon, Oct 30, 2006 at 05:31:24PM -0800, Sridhar Samudrala wrote:
>
> I think we currently assume atleast the SCTP header and the data
> chunk header to be in the skb head.
> But we do handle skbs with data in the frag_list.
> Not sure about skb's with paged fragments.
You can't ass
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 19:31:31 -0500 (EST)
> Currently, when an application requests a lease for a flowlabel via the
> IPV6_FLOWLABEL_MGR socket option, no error is returned if an invalid type
> of destination address is supplied as part of the request, le
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 17:38:41 -0800
> [SCTP]: Remove temporary associations from backlog and hash.
>
> Every time SCTP creates a temporary association, the stack hashes it,
> puts it on a list of endpoint associations and increments the backlog.
> How
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 17:38:37 -0800
> [SCTP]: Correctly set IP id for SCTP traffic
>
> Make SCTP 1-1 style and peeled-off associations behave like TCP when
> setting IP id. In both cases, we set the inet_sk(sk)->daddr and initialize
> inet_sk(sk)->id
On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
> Can this be used to make the driver work without the daemon?
Yup. And we have already successfully put the daemon's work into the
firmware/ucode. The new firmware will be released soon. Stay tuned.
Thanks,
-yi
-
To unsubscribe from this list: s
[SCTP]: Remove temporary associations from backlog and hash.
Every time SCTP creates a temporary association, the stack hashes it,
puts it on a list of endpoint associations and increments the backlog.
However, the lifetime of a temporary association is the processing time
of a current packet and
[SCTP]: Correctly set IP id for SCTP traffic
Make SCTP 1-1 style and peeled-off associations behave like TCP when
setting IP id. In both cases, we set the inet_sk(sk)->daddr and initialize
inet_sk(sk)->id to a random value.
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Signed-off-by: Sridhar S
On Sun, 2006-10-29 at 23:46 -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 30 Oct 2006 18:11:28 +1100
>
> > [SCTP]: Always linearise packet on input
> ...
> > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> I'll apply this, thanks a lot.
>
> > Sridhar, could yo
On Mon, Oct 30, 2006 at 10:08:58AM -0800, David Kimdon wrote:
>
> Updated patch, now aes, tkip and wep are all tested.
>
> Changes from take0:
>
> Use IS_ERR() to evaluate return value of crypto_alloc_cipher(). Use
> ciper interface rather than blkcipher for aes encryption since we only
> encry
Currently, when an application requests a lease for a flowlabel via the
IPV6_FLOWLABEL_MGR socket option, no error is returned if an invalid type
of destination address is supplied as part of the request, leading to a
silent failure. This patch ensures that EINVAL is returned to the
applicatio
I've completed the first pass of my changes to pktgen in 2.6.18.
Many of these features are probably DOA based on previous conversations,
but perhaps this will help someone
Changes:
* use a nano-second timer based on the scheduler timer (TSC) for relative
times, instead of get_time_of_day.
*
From: Heiko Carstens <[EMAIL PROTECTED]>
Date: Thu, 26 Oct 2006 15:03:17 +0200
> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
> ---
> net/ipv4/raw.c | 17 +++--
> net/ipv6/raw.c | 17 +++--
> net/netlink/af_netlink.c |5 +++--
> 3 files cha
Johannes Berg wrote:
I'm not so sure about this. This patching might be US-specific and we
cannot simply apply the setting for top channel of another domain
instead of channel 11. One option would be to set the value only under
the US regulatory domain.
??
What the patch does is replace the t
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 30 Oct 2006 22:30:39 +0100
> In sock_attach_fd(), we are currently using
>
> d_add(file->f_dentry, SOCK_INODE(sock));
>
> This has the effect to insert the dentry into the dentry_hashtable.
>
> I was wondering if it is really necessary : On a ma
In sock_attach_fd(), we are currently using
d_add(file->f_dentry, SOCK_INODE(sock));
This has the effect to insert the dentry into the dentry_hashtable.
I was wondering if it is really necessary : On a machine with many sockets,
the dentry_hashtable lookups may be slowed down for no good reaso
Eric Paris wrote:
> On Mon, 2006-10-30 at 13:03 -0500, [EMAIL PROTECTED] wrote:
>
>>plain text document attachment (netlabel-sockopts)
>>From: Paul Moore <[EMAIL PROTECTED]>
>>
>>This patch makes two changes to protect applications from either removing or
>>tampering with the CIPSOv4 IP option on
On Mon, 2006-10-30 at 13:03 -0500, [EMAIL PROTECTED] wrote:
> plain text document attachment (netlabel-sockopts)
> From: Paul Moore <[EMAIL PROTECTED]>
>
> This patch makes two changes to protect applications from either removing or
> tampering with the CIPSOv4 IP option on a socket. The first is
On Sun, 2006-10-29 at 14:35 +0200, [EMAIL PROTECTED] wrote:
> This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
> I removed all parts which are not relevant for wpa_supplicant (managed mode).
>
> you can connect to your WLAN with:
> wpa_supplicant -Dwext -c{WPA_CONF} -
On Mon, 30 Oct 2006 15:55:57 +0100, Benjamin Thery wrote:
> When I switch my Mobile Node between 2 Wi-Fi Access Points, there is a
> period of time where all the packets I send are lost, although I got
> the netlink event SIOCGIWAP 'up' for the new AP. The device is
> supposed to be ready, but t
On 10/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
This patch completes WPA/RSN with TKIP support for all fullmac prism54 cards.
I removed all parts which are not relevant for wpa_supplicant (managed mode).
This is great effort and thanks for it! My only concern with the patch
is breakin
Arjan van de Ven wrote:
> On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
>> The ipw3945 driver has been out for a while and is not yet upstream.
>> It requires a binary only daemon to work, but I still see no reason not
>> to merge it.
>> Many wlan drivers require binary firmware anyway, so I d
Mgmt unit set was created first. However, it should not matter.
Ayaz
Jeff Garzik wrote:
You sent two pairs of patches, both labelled "1/2" and "2/2".
Which pair should go first, the pci ids or mgmt unit?
Or does it matter?
Jeff
---
Auke Kok wrote:
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
You sent two pairs of patches, both labelled "1/2" and "2/2".
Which pair should go first, the pci ids or mgmt unit?
Or does it matter?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://
Ray Lehtiniemi reported that an incoming UDP packet flood can lock up
the ep93xx ethernet driver. Herbert Valerio Riedel noted that due to
the way ep93xx_eth manages the RX/TXstatus rings, it cannot distinguish
a full ring from an empty one, and correctly suggested that this was
likely to be causi
This patchset fixes three issues in ep93xx_eth. The first fix is for
an RX/TX lockup bug due to mishandling of the RX/TXstatus rings in the
driver, and is a showstopper. The second and third aren't really
showstopper bugs, but real issues nevertheless, and easy enough to fix.
In this new queue,
Flooding the console with error messages for every RX FIFO overrun,
checksum error and framing error isn't very sensible. Each of these
errors can occur during normal operation, so stop printk'ing error
messages for RX errors at all.
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>
Index: li
The ipw3945 driver has been out for a while and is not yet upstream.
It requires a binary only daemon to work, but I still see no reason not
to merge it.
Many wlan drivers require binary firmware anyway, so I don't see a
reason not to merge it.
I also have read this: http://lwn.net/Articles/205988
On Mon, 30 Oct 2006, [EMAIL PROTECTED] wrote:
> From: Paul Moore <[EMAIL PROTECTED]>
>
> This patch makes two changes to protect applications from either removing or
> tampering with the CIPSOv4 IP option on a socket.
Thanks. Applied to:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/s
Fix unlikely(x) > y test in ep93xx_eth.
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>
Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers
This patch adds pci device ids for the NVIDIA MCP67 chip.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- a/include/linux/pci_ids.h 2006-10-30 17:22:09.0 -0500
+++ b/include/linux/pci_ids.h 2006-10-30 17:22:17.0 -0500
@@ -1213,6 +1213,10 @@
#define PCI_DEVICE_ID_NVIDIA_N
The ipw3945 driver has been out for a while and is not yet upstream.
It requires a binary only daemon to work, but I still see no reason not
to merge it.
Many wlan drivers require binary firmware anyway, so I don't see a
reason not to merge it.
I also have read this: http://lwn.net/Articles/2059
On Mon, 2006-10-30 at 19:54 +0100, dragoran wrote:
> The ipw3945 driver has been out for a while and is not yet upstream.
> It requires a binary only daemon to work, but I still see no reason not
> to merge it.
> Many wlan drivers require binary firmware anyway, so I don't see a
> reason not to mer
This patch adds support for the new mcp67 device into forcedeth.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig-2.6/drivers/net/forcedeth.c2006-10-30 16:26:57.0 -0500
+++ new-2.6/drivers/net/forcedeth.c 2006-10-30 17:08:46.0 -0500
@@ -4927,6 +4927,22 @@
This patch adds support for the mgmt unit in certain chipsets. The MAC
and the mgmt unit share the PHY and therefore proper intialization
procedures are needed for them to maintain coexistense.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig-2.6/drivers/net/forcedeth.c2006-10-30 1
This patch adds support to recover from a previously fatal MAC error. In
the past the MAC would be hung on an internal fatal error. On new
chipsets, the MAC has the ability to enter a non-fatal state and allow
the driver to re-init it.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig-
Sorry, but another bugfix patch for NetLabel which I think should be included
2.6.19.
The problem is that the SELinux reference policy is a bit more free in allowing
applications to call setsockopt() than I had originally thought, which means
that normal applications could add or tamper with the N
From: Paul Moore <[EMAIL PROTECTED]>
This patch makes two changes to protect applications from either removing or
tampering with the CIPSOv4 IP option on a socket. The first is the requirement
that applications have the CAP_NET_RAW capability to set an IPOPT_CIPSO option
on a socket; this prevent
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/wirless/airo.c for an example of that.
Thanks Herbert.
Updated patch, n
Hi Ulrich,
I'm fairly certain the patch is safe, even for non-US regulatory domains.
Looking at the zd1211rw code the highest channel in the geo object
would appear to be set in zd_geo_init as determined by
zd_channel_range which just does a simple look up in channel_ranges[],
so if this code be
Kenzo Iwami wrote:
Hi,
Thank you for your comment.
Anyway as I said in the same e-mail, we're working on reducing the lock timeout to a
reasonable time. This will unfortunately take some time, as we need to change some major
components in the driver to make sure this doesn't happen.
How abou
On Mon, 30 Oct 2006 15:27:14 +0300
Dmitry Mishin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Could somebody explain, why bridge uses minimal MAC of the attached devices?
> It makes this address instable, variable during bridge life-cycle, which is
> not good for DHCP. For example, I want to attach mult
Hello,
I work on an extension of the mobility protocol for IPv6
(FMIPv6-RFC4068) and I've noticed the following problem:
When I switch my Mobile Node between 2 Wi-Fi Access Points, there is a
period of time where all the packets I send are lost, although I got
the netlink event SIOCGIWAP 'up
I should have noticed by now that netdev isn't at oss.sgi.com anymore..
- Forwarded message from Christoph Hellwig -
Date: Mon, 30 Oct 2006 15:14:54 +0100
From: Christoph Hellwig
Subject: [PATCH 1/3]: leak tracking for kmalloc node
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
If we want to
Davem suggested to get the node-affinity information directly from
struct device instead of having the caller extreact it from the
pci_dev. This patch adds dev_to_node() to the topology API for that.
The implementation is rather ugly as we need to compare the bus
operations which we can't do inlin
This patch finnally switches netdev_alloc_skb to be node-locale.
It uses dev_to_node and kmalloc_node_track_caller from the previous two
patches.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/include/linux/skbuff.h
=
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/spider_net.c
===
--- linux-2.6.orig/drivers/net/spider_net.c 2006-10-23 17:20:14.0
+0200
+++ linux-2.6/drivers/net/spider_net.c 2006-10-3
Hi,
Could somebody explain, why bridge uses minimal MAC of the attached devices?
It makes this address instable, variable during bridge life-cycle, which is
not good for DHCP. For example, I want to attach multiple virtual devices to
one physical. Then, I need to make sure that after each virtua
Hi,
Thank you for your comment.
> Anyway as I said in the same e-mail, we're working on reducing the lock
> timeout to a
> reasonable time. This will unfortunately take some time, as we need to
> change some major
> components in the driver to make sure this doesn't happen
On Sun, 2006-10-29 at 14:35 +0200, [EMAIL PROTECTED] wrote:
> +#define MAC2STR(a) (a)[0], (a)[1], (a)[2], (a)[3], (a)[4], (a)[5]:
> +#define MACSTR "%02x: %02x:%02x:%02x:%02x:%02x"
such defines should exist already in ieee80211 headers.
> - /* Update our wireless stats, but do not schedul
> I'm not so sure about this. This patching might be US-specific and we
> cannot simply apply the setting for top channel of another domain
> instead of channel 11. One option would be to set the value only under
> the US regulatory domain.
??
What the patch does is replace the top channel whi
59 matches
Mail list logo
