On Sun, Feb 24, 2008 at 04:10:29AM +0100, Jann Traschewski wrote:
Hello,
Hi!
I got a spinlock lockup using the latest Kernel 2.6.24.2 with recent
patches from Jarek Poplawski applied.
...
ppp_deflate nf_nat zlib_deflateBUG: unable to handle kernel NULL pointer
dereference zlib_inflate
On 24-02-2008 23:20, Denys Fedoryshchenko wrote:
2.6.24.2 with applied patches for printk,softlockup, and patch for htb (as i
understand, they are in 2.6.25 git and it is fixes).
I will send also to private mails QoS rules i am using.
[ 118.840072]
On Mon, Feb 25, 2008 at 12:48:38PM +0200, Denys Fedoryshchenko wrote:
What does it mean early?
I have custom boot scripts, it is also custom system based on busybox. There
is a chance that i forgot to bring ifb0 up, but thats it.
I think such warning must not appear on any actions in
On Mon, Feb 25, 2008 at 12:19:50PM +, James Chapman wrote:
Jarek Poplawski wrote:
Jarek Poplawski wrote, On 02/21/2008 01:08 PM:
...
Another, probably simpler way would be to move almost all pppol2tp_xmit
...
Actually, the simplest off all seems to be now this old idea to maybe make
On Mon, Feb 25, 2008 at 01:05:08PM +, Jarek Poplawski wrote:
...
On Mon, Feb 25, 2008 at 12:19:50PM +, James Chapman wrote:
Is this an acceptable solution? If so, I'll prepare and send official
patches.
IMHO this should be acceptable because I can't see any reason for
changing
On Mon, Feb 25, 2008 at 01:39:48PM +, Jarek Poplawski wrote:
...
Maybe, it's better to
analyze yet if it's really so hard to eliminate taking this lock
on the xmit path?
BTW, I'm not sure if it helps, but this matters only for the sockets
which could be used (and locked) outside
Jarek Poplawski wrote, On 02/25/2008 02:39 PM:
...
Hmm... Wait a minute! But on the other hand David has written about
his cons here, and it looks reasonable: this place would be fixed,
but some others can start reports like this. Maybe, it's better to
analyze yet if it's really so hard
On 26-02-2008 07:34, Li Yewang wrote:
Hi All
There is a bug about icmp netunreach.
If the kernel does not find a route for a packet,
it must send a icmp netunreach packet to the source host,
and discard the packet. But the kernel does not send
a icmp netunreach packet
On Tue, Feb 26, 2008 at 06:59:08PM +0900, Wei Yongjun wrote:
Jarek Poplawski wrote:
Maybe ip_error() does not handle the ESRCH error. In this place ESRCH eq
to ENETUNREACH?
It doesn't handle ESRCH for sure... Current solution seems to expect
it is changed earlier to ENETUNREACH. It looks
On Tue, Feb 26, 2008 at 12:14:26PM +, James Chapman wrote:
Jarek Poplawski wrote:
Jarek Poplawski wrote, On 02/25/2008 02:39 PM:
...
Hmm... Wait a minute! But on the other hand David has written about
his cons here, and it looks reasonable: this place would be fixed,
but some others can
On Tue, Feb 26, 2008 at 01:03:34PM +, Jarek Poplawski wrote:
On Tue, Feb 26, 2008 at 12:14:26PM +, James Chapman wrote:
...
there are hanging. Btw, they don't hang if I disable irqs around the
ppp_input() call.
...and disabling bh instead isn't enough, BTW?
I guess
James Chapman wrote, On 02/26/2008 01:14 PM:
...
Luckily, I'm in the lab where my two borrowed servers are today so I
have access to their consoles. Hopefully I'll be able to find out why
there are hanging. Btw, they don't hang if I disable irqs around the
ppp_input() call.
Maybe you've
601 - 612 of 612 matches
Mail list logo
