On Fri, Aug 31, 2007 at 06:51:24PM +0400, Badalian Vyacheslav wrote:
I found that bug in this place
(gdb) l *0xc01c8973
0xc01c8973 is in rb_insert_color (lib/rbtree.c:80).
...
if i not wrong understand message unable to handle kernel NULL pointer
dereference at virtual address 0008 its
Your errors trigger in rbtree, which does indexing for HTB, but since
it's something quite rare I think there is a very small probability
that it's caused by HTB class/level handling (but it's possible, too),
but more probable (to me) these indexes are corrupted by something e.g.
like accessing
May you also see that i need change to fix this:
qdisc handle can = 10 000
i have more then 10 000 qdiscs =(
-
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
On Mon, 3 Sep 2007 00:29:48 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8971
Summary: htb class delete causes kernelpanic and other htb bugs.
Product: Networking
Version: 2.5
KernelVersion: 2.6.18.* - 2.6.23-rc4
profuse, grovelling apologies in advance:
normally, i would have waited until after the updates in the merge
window after 2.6.23 since i know cleanups for some of what follows are
in the queue, but there are at least a couple odd-looking variables
here that i thought i'd post the results of my
On Mon, Sep 03, 2007 at 12:31:39PM +0400, Badalian Vyacheslav wrote:
May you also see that i need change to fix this:
qdisc handle can = 10 000
i have more then 10 000 qdiscs =(
As far as I know qdisc handle is hex, so you can have e.g.:
handle 999a (or a999 too). But, does it mean your
Hi Dave,
David Miller [EMAIL PROTECTED] wrote on 08/29/2007 10:21:50 AM:
From: Krishna Kumar2 [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 08:53:30 +0530
I am scp'ng from 192.168.1.1 to 192.168.1.2 and captured at the send
side.
Bad choice of test, this is cpu limited since the scp
has to
Am Freitag, 31. August 2007 schrieb Herbert Xu:
On Thu, Aug 30, 2007 at 09:51:31AM +, James Chapman wrote:
The captured PPPoE stream seems to show incorrect data lengths in the
PPPoE header for some captured PPPoE packets. The kernel's PPPoE
datapath uses this length to extract the
* David Miller [EMAIL PROTECTED] 2007-08-30 22:39
Every so often some piece of userland dies, and often it's
bad enough that my desktop session logs out.
I've been trying to find some clues and it seems to happen
about as often as openswan rekeys my VPN, so one suspect
area is the netlink
Hi all,
Here is a list of some known regressions in 2.6.23-rc5.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Linus Torvalds
Hi all,
Here is a list of some known regressions in 2.6.23-rc5
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
(Please ignore previous message, it was sent from the wrong account.)
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if
Hello,
On Sun, 2 Sep 2007 13:25:57 +0200
Adrian Bunk [EMAIL PROTECTED] wrote:
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
...
Changes since 2.6.23-rc3-mm1:
...
git-net.patch
...
git trees
...
This patch fixes the following compile error:
-- snip --
...
黃建興-Jesse wrote:
+++ a/drivers/net/sundance.c
@@ -559,7 +559,11 @@ static int __devinit sundance_probe1 (st
* It seems some phys doesn't deal well with address 0 being
accessed
* first, so leave address zero to the end of the loop (32 31).
*/
- for (phy = 1;
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if their
hardware buffer is full OR if some given time (say 1 ms) has
Officially deprecate the boot-time ether= option in favour of
netdev=, update the documentation accordingly in various places, and
schedule removal for September of 2008.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
i realize that some people have strong feelings about removing
Am Samstag 01 September 2007 schrieb Daniel Drake:
Would also be nice to have a bug on the kernel bugzilla to track this.
#8972 on bugzilla.kernel.org
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
John Sigler wrote:
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if their
hardware buffer is full OR if some given time (say 1 ms) has
John Sigler wrote:
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
82558/9 hardware does, sort of. But the e100 driver doesn't use it
because it uses NAPI to minimize rx tx
In [VLAN]: Move device registation to seperate function (commit
e89fe42cd03c8fd3686df82d8390a235717a66de), a pile of code got moved
to register_vlan_dev(), including grabbing a reference to underlying
device. However, original dev_hold() had been left behind, so we
leak a reference to net_device
On Sun, 2007-09-02 at 23:16 +0200, Patrick McHardy wrote:
Jesper Dangaard Brouer wrote:
On Sun, 2 Sep 2007, Patrick McHardy wrote:
Lets focus on the general case, where the functionality actually is
needed right away.
In the general case:
- The rate table needs to be aligned
Al Viro wrote:
In [VLAN]: Move device registation to seperate function (commit
e89fe42cd03c8fd3686df82d8390a235717a66de), a pile of code got moved
to register_vlan_dev(), including grabbing a reference to underlying
device. However, original dev_hold() had been left behind, so we
leak a
Hi!
new in this version:
- fixed stuff that was commented on.
- added 7-wire support (compile at least, if someone has the hardware,
please test!)
- ethtool support
(this obsoletes Sylvain's patch that's floating around:
0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch)
On 9/2/07, Domen Puncer [EMAIL PROTECTED] wrote:
Hi!
new in this version:
- fixed stuff that was commented on.
- added 7-wire support (compile at least, if someone has the hardware,
please test!)
- ethtool support
Thanks for this work Domen, comments below...
This is a large
On 9/3/07, Grant Likely [EMAIL PROTECTED] wrote:
On 9/2/07, Domen Puncer [EMAIL PROTECTED] wrote:
Hi!
new in this version:
- fixed stuff that was commented on.
- added 7-wire support (compile at least, if someone has the hardware,
please test!)
- ethtool support
Thanks for
On 9/3/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 9/3/07, Grant Likely [EMAIL PROTECTED] wrote:
On 9/2/07, Domen Puncer [EMAIL PROTECTED] wrote:
Hi!
new in this version:
- fixed stuff that was commented on.
- added 7-wire support (compile at least, if someone has the hardware,
This looks like another manifestation of the Linux arp differences
from end user expectation.
Begin forwarded message:
Date: Mon, 3 Sep 2007 08:19:26 -0700 (PDT)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 8975] New: Broadcasting fails when default gateway can't be
reached.
Ath5k panics on ath_open() because sc-pdev is never set, fixed.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
--- a/drivers/net/wireless/ath5k_base.c
+++ b/drivers/net/wireless/ath5k_base.c
@@ -2295,6 +2295,7 @@ static int __devinit ath_pci_probe(struct pci_dev *pdev,
hw-max_rssi =
?
- which fix exactly (Message-Id or URL) ? The one I sent the
29 of 08/2007 or something else ?
- which chipset (lspci -vvx) ?
Fwiw, I have rediffed the patchkit against 2.6.23-rc5. See:
http://www.fr.zoreil.com/people/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
or:
http
/francois/misc/20070903-2.6.23-rc5-r8169-test.patch
or just patches #0001 + #0002 at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.23-rc5/r8169-20070903/
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
drivers/net/3c59x.c: In function 'vortex_up':
drivers/net/3c59x.c:1495: warning: 'err' may be used uninitialized in this
function
is a genuine bug. The function returns an uninitialized value of 'err'
back to the caller, which expects it to be 0 for success cases. Let's
fix this by explicitly
Remove duplicate entry for the same driver.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
MAINTAINERS |6 --
1 file changed, 6 deletions(-)
--- linux-2.6.23-rc4-mm1/MAINTAINERS~fix2007-09-04 03:49:16.0
+0530
+++ linux-2.6.23-rc4-mm1/MAINTAINERS2007-09-04
Thomas Graf [EMAIL PROTECTED] wrote:
I've been trying to reproduce this, what happens on my system
is that when the ISAKMP SA lifetime is exceeded the rekeying
fails and my connection dies. I can reproduce this back to
2.6.22 and it doesn't seem related to my recent xfrm_user work.
It looks
Hello,
in 2.6.22.6, net/sunrpc/svcsock.c
random characters are printed by svc_tcp_accept:
lockd: last TCP connect from some random chars
because buf is used unitialized:
printk(KERN_NOTICE
%s: last TCP connect from %s\n,
serv-sv_name, buf);
Probably it should be
Hi Daniele,
Attached is a patch for converting the sis900 driver to NAPI. Please take a
look at let me know what you think. I'm not 100% sure if I'm handling the
rotting packet issue correctly or that I have the locking right in tx_timeout.
These might be areas to look at closely.
I didn't see
On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:
On Sat, 1 Sep 2007, Patrick McHardy wrote:
Jesper Dangaard Brouer wrote:
commit 6fdc0f061be94f5e297650961360fb7a9d1cc85d
Author: Jesper Dangaard Brouer [EMAIL PROTECTED]
Date: Thu Aug 30 17:53:42 2007 +0200
[NET_SCHED]: Make all
Andi mentioned he did something like this already, but never
submitted it.
The dhcp client application uses AF_PACKET with a packet filter to
receive data. The application doesn't even use timestamps, but because
the AF_PACKET API has timestamps, they get turned on globally which
causes an
37 matches
Mail list logo
