Incorporated Auke's comments
ioremap must be balanced by an iounmap and failing to do so can result
in a memory leak.
Tested (compilation only) with:
- allmodconfig
- Modifying drivers/net/Kconfig to make sure that the changed file is
compiling without warning
Signed-off-by: Amol Lad <[EMAIL PRO
Amol Lad wrote:
ioremap must be balanced by an iounmap and failing to do so can result
in a memory leak.
Tested (compilation only) with:
- allmodconfig
- Modifying drivers/net/Kconfig to make sure that the changed file is
compiling without warning
Signed-off-by: Amol Lad <[EMAIL PROTECTED]>
--
Begin forwarded message:
Date: Sun, 24 Sep 2006 19:58:03 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 7198] New: balance-alb bonding oops when
disconnecting primary slave interface
http://bugzilla.kernel.org/show_bug.cgi?id=7198
Summary: balance-al
ioremap must be balanced by an iounmap and failing to do so can result
in a memory leak.
Tested (compilation only) with:
- allmodconfig
- Modifying drivers/net/Kconfig to make sure that the changed file is
compiling without warning
Signed-off-by: Amol Lad <[EMAIL PROTECTED]>
---
I'm not subsrib
David> I was waiting for a resolution in the fact that the copy
David> Chas posted only had one of the transformations whereas as
David> you pointed out all of the ones in your original patch were
David> necessary.
Actually I think there was some confusion because akpm forwarded a
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 20 Sep 2006 13:32:58 -0700
> Change default congestion control used from BIC to the newer CUBIC
> which it the successor to BIC but has better properties over long delay links.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Also ap
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 20 Sep 2006 13:28:06 -0700
> Change how default TCP congestion control is chosen. Don't just use
> last installed module, instead allow selection during configuration,
> and make sure and use the default regardless of load order.
>
> Signed-o
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Sat, 23 Sep 2006 17:17:54 -0700
> Dave, this was acked by Chas (and he even requested it go into 2.6.18)
> but it seems to have gotten dropped somewhere -- it's not in Linus's
> tree even after he pulled your net tree.
>
> Please apply.
Applied.
I w
From: Yasuyuki KOZAKAI <[EMAIL PROTECTED]>
Date: Mon, 25 Sep 2006 09:56:01 +0900 (JST)
> Thanks for notice. I'll do that from next time.
>
> David, please apply the attached patch.
I've applied this and will push to Linus later tonight.
Thanks.
-
To unsubscribe from this list: send the line "un
From: Michal Ostrowski <[EMAIL PROTECTED]>
Date: Sun, 24 Sep 2006 07:29:25 -0500
> I think the call path via dev->hard_start_xmit, if it fails, may result
> in an skb not being freed. This appears to be the case with the e100.c
> driver. The qdisc_restart path to dev->hard_start_xmit also appear
Ok, I will generate new patch according to this.
Thanks.
- Original Message -
From: "Andrew Morton" <[EMAIL PROTECTED]>
To: "Jesse Huang" <[EMAIL PROTECTED]>
Sent: Saturday, September 23, 2006 4:51 PM
Subject: Re: [PATCH] Restore the original TX FIFO overflow process.
On Sat, 23 Sep 200
On Sat, 23 Sep 2006 15:27:36 +0200, Joerg Roedel said:
> (I assume you are speaking of the position of the 3 in the header). The
> RFC is not clear at this point. It defines that the first 4 bits in the
> 16 bit Ethernet header MUST be 0011. But it don't defines the
> byteorder of that 16 bit word
Hello,
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Sun, 24 Sep 2006 21:02:38 +0100
> On Sun, 2006-09-24 at 00:02 +, Linux Kernel Mailing List wrote:
> > --- a/include/linux/netfilter_ipv4/ipt_dscp.h
> > +++ b/include/linux/netfilter_ipv4/ipt_dscp.h
> > @@ -10,14 +10,12 @@
> > #ifndef _I
James Morris <[EMAIL PROTECTED]> wrote:
>
> Evgeniy: if you update to the latest racoon (and kernel), and still see
> it, please send complete logs of 'racoon -' from each side, and also
> 'setkey -x', so we can see if the policy entries are being being modified.
Please also do 'ip -s x s' o
This patch adds a host_strip_iv_icv flag to ieee80211 which indicates that
ieee80211_rx should strip the IV/ICV/other security features from the payload.
This saves on some memmove() calls in the driver and seems like something that
belongs in the stack as it can be used by bcm43xx, ipw2200, and zd
Evgeniy Polyakov wrote:
On Fri, Sep 22, 2006 at 10:33:48PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
The NET_IP_ALIGN existed not just for fun :) There are ramifications
for removing it.
It's still there, isn't it?
For the 9k MTU case, for example, we end up allocating 16384 byte skbs
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-R} -> {in-softirq-W} usage.
swapper/0 [HC0[0]:SC1[2]:HE1:SE0] takes:
(police_lock){-+--}, at: [] tcf_police_destroy+0x24/0x8f [act_police]
{softirq-on-R} state was regist
On Sun, 2006-09-24 at 00:05 +, Linux Kernel Mailing List wrote:
> [NETFILTER]: remove unused include file
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
>
> include/linux/netfilter_logging.h | 33 -
On Sun, 2006-09-24 at 00:02 +, Linux Kernel Mailing List wrote:
> --- a/include/linux/netfilter_ipv4/ipt_dscp.h
> +++ b/include/linux/netfilter_ipv4/ipt_dscp.h
> @@ -10,14 +10,12 @@
> #ifndef _IPT_DSCP_H
> #define _IPT_DSCP_H
>
> -#define IPT_DSCP_MASK 0xfc/* 1100 */
> -#define IPT
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> You have tcp_v6 lockdep warnings. They're in
> http://xml.cweiske.de/dojo%20kernelpanic%20+%20debug.tar.bz2 is anyone is
> keen. (I've largely lost interest in lockdep warnings - many of them are
> false positives and require make-lockdep-shut-up pat
An official email from digi.com to Andres Salomon <[EMAIL PROTECTED]>
explained:
Dear Andres:
After further research, we found that this product was killed in place
and never reached the market. We would like to request that this not be
included.
Copy at http://wiki.debian.org/KernelFirmwar
Hi John,
Is there any particular reason this patch has been held back?
It has been send to the kernel mailinglist several times as well,
and there didn't seem to be any objections against it, except
for some coding style errors which had been fixed.
The second objection, which wasn't said so expli
On Sunday 24 September 2006 17:34, Daniel Drake wrote:
> Michael Buesch wrote:
> > Well. Works For Me (tm).
> > If there is some bug for you in current mainline, it needs to
> > be fixed. But I can't fix something I am not able to reproduce and
> > don't know what happens.
>
> Take a look at the l
[just sent upstream to Andrew & Linus; patch available in git, it's too
large to post]
Nothing major of interest. A couple new drivers (ehea, qla3xxx,
ep93xx_eth), a lot of trailing whitespace killed, a deleted MIPS driver,
e1000 update, ...
Please pull from 'upstream-linus' branch of
master.ker
On Sun, 2006-09-24 at 16:13 +1000, Benjamin Herrenschmidt wrote:
> > prism54 fullmac, right?
>
> Yes.
>
> > Try using -Dwext; the prism54 wpa_supplicant driver is a dead-end and I
> > added WE-19 commands to it a bit ago anyway. Oddly enough, I couldn't
> > seem to get the driver to work reliabl
Michael Buesch wrote:
Well. Works For Me (tm).
If there is some bug for you in current mainline, it needs to
be fixed. But I can't fix something I am not able to reproduce and
don't know what happens.
Take a look at the logs in Ben's original mail. I've seen this a lot
myself and am fairly sur
On Fri, Sep 22, 2006 at 10:33:48PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> > The NET_IP_ALIGN existed not just for fun :) There are ramifications
> > for removing it.
>
> It's still there, isn't it?
>
> For the 9k MTU case, for example, we end up allocating 16384 byte skbs
> instead o
On Sun, 24 Sep 2006, Patrick McHardy wrote:
> James Morris wrote:
> > On Sat, 23 Sep 2006, Evgeniy Polyakov wrote:
> >
> >
> >>I never saw unencrypted packets before.
> >
> >
> > It's normal and expected, perhaps you didn't notice or had tcpdump
> > filtering them.
>
> He's talking about tra
Hi,
This patch has removed gt64240eth.h .
Nothing is using gt64240eth.h .
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -pruN -X generic/Documentation/dontdiff
generic-orig/drivers/net/gt64240eth.h generic/drivers/net/gt64240eth.h
--- generic-orig/drivers/net/gt64240eth.h 2
On Sat, 2006-09-23 at 14:56 -0700, David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Sat, 23 Sep 2006 12:30:23 -0500
>
> > __pppoe_xmit must free any skb it allocates if there is an error
> > submitting the skb downstream.
>
> This isn't right, dev_queue_xmit() can return -ENETDOWN and still
On Thu, Sep 21, 2006 at 04:59:37PM -0700, Jesse Brandeburg wrote:
> Herbert can you help describe why we need this patch on this thread on
> netdev? We reproduced the race without it and it appears to go away
> with it.
Of course you can resolve it by adding a lock to the txclean path.
However, t
Hi all,
I am running
zd1211rw 4-1:1.0: firmware version 4605
zd1211rw 4-1:1.0: zd1211 chip 6891:a727 v4330 high 00-14-7c RF2959_RF pa0 g---
IEEE 802.11b/g ESSID:"BLO" Nickname:"zd1211"
Mode:Managed Frequency:2.462 GHz Access Point: XX:XX:BB:LL:KK:00
Bit Rate:54 Mb/s
Link Quality=98/100 Sign
On Sun, 24 Sep 2006 11:11:02 +0200
Christian Weiske <[EMAIL PROTECTED]> wrote:
> Andrew,
>
You keep on losing Cc:s. Please preserve them all with care when replying.
>
> >> I have a reproducible BUG on my server that occurs whenever disk usage
> >> gets too high / too much swapping occurs (at
James Morris wrote:
> On Sat, 23 Sep 2006, Evgeniy Polyakov wrote:
>
>
>>I never saw unencrypted packets before.
>
>
> It's normal and expected, perhaps you didn't notice or had tcpdump
> filtering them.
He's talking about transport mode, unencrypted packet should
only be visible in tunnel mo
On Sun, 2006-09-24 at 10:43 +0200, Michael Buesch wrote:
> On Sunday 24 September 2006 10:12, Benjamin Herrenschmidt wrote:
> > > > So what are the chances of getting this dscape stack merged, let's
> > > > say... for 2.6.19 ? Or we'll get yet another full release with barely
> > > > working wirele
On Sunday 24 September 2006 10:12, Benjamin Herrenschmidt wrote:
> > > So what are the chances of getting this dscape stack merged, let's
> > > say... for 2.6.19 ? Or we'll get yet another full release with barely
> > > working wireless ?
> >
> > I don't think it's possible to happen for 2.6.19.
>
> > So what are the chances of getting this dscape stack merged, let's
> > say... for 2.6.19 ? Or we'll get yet another full release with barely
> > working wireless ?
>
> I don't think it's possible to happen for 2.6.19.
> Ealiest 2.6.20 but likely one or two releases later (me thinks).
Which me
On Sunday 24 September 2006 08:18, Benjamin Herrenschmidt wrote:
> On Sat, 2006-09-23 at 23:45 -0400, Daniel Drake wrote:
> > Benjamin Herrenschmidt wrote:
> > > Oh and I don't care about "it works in dscape stack" sort of crap I
> > > regulary get. I want something that
> > > works with upstream
38 matches
Mail list logo
