[EMAIL PROTECTED] wrote:
On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
git-net.patch (I'm guessing one of Daniel's commits, but not sure which one)
causes some complaints:
LD vmlinux.o
MO
> Sorry. GMail doesn't support sending unwrapped text, as far as I can
> tell. I will send the log segment to you as an attachment. Also,
> when I sent my .config inline to Andrew recently, it tripped his spam
> filter. I'll attach it as well.
Thanks. This is a bug in iwlwifi.
The problem is
On Tue, 2007-12-18 at 09:03 -0500, Miles Lane wrote:
> I have only seen this happen once, and cannot reproduce it. I'll keep
> trying, though.
>
> Dec 16 22:10:48 syntropy kernel: [ 231.718023]
> ===
Do you have a version that isn't line-wrap
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Fri, 14 Dec 2007 15:36:33 -0800
> The networking bug looks to be around sock_i_ino()'s taking of
> sk_callback_lock with softirq's enabled. Perhaps this will fix it.
One should be suspicious of any case where write_lock is performed
on sk->sk_callbac
On Sat, 15 Dec 2007 15:55:09 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 15, 2007 3:13 PM, Miles Lane <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 15, 2007 6:13 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrot
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> My suspicion is that you've hit bad breakage in networking and lockdep just
> isn't sufficiently robust to handle what it's being given.
>
> Can you suggest a way in which others can reproduce this?
I can reproduce this now. I suspect it's to do with
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
>
> git-ubi.patch
> GOOD
> #
> git-net.patch
> BAD
> ipsec-fix-reversed-icmp6-policy-check.patch
>
> but this seems to be far from precise :)
I suspect namespace borkage. But just because you pin-pointed
my patch I'll try to track it down :)
Cheers,
Hello,
As one of usual tests I run the following script:
for i in `find /proc -type f`; do
echo -n "cat $i > /dev/null ... ";
cat $i > /dev/null;
echo "done";
done
This time the culprit is /proc/net/packet. cat process gets killed
$ cat /proc/net/packet
Segment
Andrew Morton wrote, On 12/15/2007 12:13 PM:
> On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
...
>> I applied the patch and then tried my test again. This time my system
>> locked up.
>> Perhaps I should open a new thread for this, since the problem looks
>> prett
Andrew Morton wrote, On 12/15/2007 12:13 PM:
> On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
>> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>>> On Fri, 14 Dec 2007 17:13:21 -0500
>>> "Miles Lane" <[EMAIL PROTECTED]> wrote:
...
Pid: 6944, c
On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 14 Dec 2007 17:13:21 -0500
> > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Sorry Andrew, I don't know who to forward this problem to.
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> I'd say you hit a networking locking bug and then when trying to report
> that bug, lockdep crashed.
>
> The networking bug looks to be around sock_i_ino()'s taking of
> sk_callback_lock with softirq's enabled. Perhaps this will fix it.
>
> diff -puN
On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Fri, 14 Dec 2007 17:13:21 -0500
> > "Miles Lane" <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Sorry Andrew, I don't know who to forward this problem to.
On Fri, 14 Dec 2007 17:13:21 -0500
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> Sorry Andrew, I don't know who to forward this problem to.
>
> I tried running: find /proc | xargs cat
> and got this:
>
> =
> [ INFO: inconsistent lock state ]
> 2.6.24-rc5-mm1 #26
> --
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 14 Dec 2007 10:08:07 +0800
> [UDP]: Move udp_stats_in6 into net/ipv4/udp.c
>
> Now that external users may increment the counters directly, we need to
> ensure that udp_stats_in6 is always available. Otherwise we'd either
> have to requrie the exte
Hi Andrew,
I hit this just now. Not sure if I can reproduce it though.
WARNING: at net/ipv4/tcp_input.c:2533 tcp_fastretrans_alert()
Pid: 4624, comm: yield Not tainted 2.6.24-rc5-mm1 #5
[] show_trace_log_lvl+0x12/0x22
[] show_trace+0xd/0xf
[] dump_stack+0x57/0x5e
[] tcp_fastretrans_alert+0xde
On Thu, Dec 13, 2007 at 09:45:54AM -0800, David Miller wrote:
> From: Benjamin Thery <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 16:01:34 +0100
>
> > The problem comes from the new macro UDPX_INC_STATS_BH introduced
> > by Herbert, which was a nice addition to increment the correct
> > UDP MIB d
On Thu, 13 Dec 2007 20:26:21 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
Hi. Please do try to cc netdev@vger.kernel.org on net-related problems.
Doing so will often save multiple hours latency and will optimise away one
entire email (ie: this one).
> Following call trace is
On Thu, Dec 13, 2007 at 05:07:44PM +0100, Borislav Petkov wrote:
> On Thu, Dec 13, 2007 at 04:01:34PM +0100, Benjamin Thery wrote:
> > The problem comes from the new macro UDPX_INC_STATS_BH introduced
> > by Herbert, which was a nice addition to increment the correct
> > UDP MIB depending on the s
From: Benjamin Thery <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 16:01:34 +0100
> The problem comes from the new macro UDPX_INC_STATS_BH introduced
> by Herbert, which was a nice addition to increment the correct
> UDP MIB depending on the socket family, but unfortunately
> the use of this macro
On Thu, Dec 13, 2007 at 04:01:34PM +0100, Benjamin Thery wrote:
> The problem comes from the new macro UDPX_INC_STATS_BH introduced
> by Herbert, which was a nice addition to increment the correct
> UDP MIB depending on the socket family, but unfortunately
> the use of this macro from kernel code
The problem comes from the new macro UDPX_INC_STATS_BH introduced
by Herbert, which was a nice addition to increment the correct
UDP MIB depending on the socket family, but unfortunately
the use of this macro from kernel code (I mean code not compiled
as module) requires that IPv6 is also compil
Hi,
My config does not link any more:
...
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
net/built-in.o: In function `xs_udp_data_ready':
/home/peifferp/containers/kernel/linux-2.6.24-rc5-mm1/n
23 matches
Mail list logo
