2.6.32-rc1-git2: Reported regressions 2.6.30 -> 2.6.31

Nix · External Since: May 21, 2006 Posts: 26

On 1 Oct 2009, Rafael J. Wysocki stated:

> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31. Please verify if it still should
> be listed and let me know (either way).

The patch fixes it.

> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14261
> Subject : e1000e jumbo frames no longer work: 'Unsupported MTU setting'
> Submitter : Nix <nix.DeleteThis@esperi.org.uk>
> Date : 2009-09-26 11:16 (6 days old)
> References : http://marc.info/?l=linux-kernel&m=125396433321342&w=4
> Handled-By : Alexander Duyck <alexander.duyck.DeleteThis@gmail.com>
> Patch : http://patchwork.kernel.org/patch/50277/

(Possibly a stable candidate? It's not in 2.6.31.2-to-be, perhaps the
only patch that isn't. Wink

)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki · External Since: May 20, 2006 Posts: 1721

On Friday 02 October 2009, Bruno PrÃ©mont wrote:
> On Thu, 01 October 2009 "Rafael J. Wysocki" <rjw RemoveThis @sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.30 and 2.6.31.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.30 and 2.6.31. Please verify if it still
> > should be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13942
> > Subject : Troubles with AoE and uninitialized object
> > Submitter : Bruno PrÃ©mont <bonbons RemoveThis @linux-vserver.org>
> > Date : 2009-08-04 10:12 (59 days old)
> > References : http://marc.info/?l=linux-kernel&m=124938117104811&w=4
>
> This should have been fixed with commits:
>
> 18d8217bc441630c3c5ec7416c5a65c69e8a0979
> aoe: end barrier bios with EOPNOTSUPP
>
> This addresses the trace on unmounting XFS
>
>
> 7135a71b19be1faf48b7148d77844d03bc0717d6
> aoe: allocate unused request_queue for sysfs
>
> This addresses the NULL kobject part
>
>
> I think the second one made it into 2.6.31 but first one didn't,

Yes, it idid.

> please double-check! I've not seen them on stable though (which might
> be worth especially for the first one)

Thanks, closed.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki · External Since: May 20, 2006 Posts: 1721

On Friday 02 October 2009, Bruno PrÃ©mont wrote:
> On Thu, 01 October 2009 "Rafael J. Wysocki" <rjw.DeleteThis@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.30 and 2.6.31.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.30 and 2.6.31. Please verify if it still
> > should be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13950
> > Subject : Oops when USB Serial disconnected while in
> > use Submitter : Bruno PrÃ©mont <bonbons.DeleteThis@linux-vserver.org>
> > Date : 2009-08-08 17:47 (55 days old)
> > References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
> > Handled-By : Alan Stern <stern.DeleteThis@rowland.harvard.edu>
>
> This has been adressed with following commits:
> 41bd34ddd7aa46dbc03b5bb33896e0fa8100fe7b
> usb-serial: change referencing of port and serial structures
>
> f5b0953a89fa3407fb293cc54ead7d8feec489e4
> usb-serial: put subroutines in logical order
>
> 8bc2c1b2daf95029658868cb1427baea2da87139
> usb-serial: change logic of serial lookups
>
> cc56cd0157753c04a987888a2f793803df661a40
> usb-serial: acquire references when a new tty is installed
>
> 7e29bb4b779f4f35385e6f21994758845bf14d23
> usb-serial: fix termios initialization logic
>
> 74556123e034c8337b69a3ebac2f3a5fc0a97032
> usb-serial: rename subroutines
>
> ff8324df1187b7280e507c976777df76c73a1ef1
> usb-serial: add missing tests and debug lines
>
> 320348c8d5c9b591282633ddb8959b42f7fc7a1c
> usb-serial: straighten out serial_open
>
> They went into 2.6.32-rc1 and are probably queued for 2.6.31.2 stable.

Thanks a lot for the detailed info, bug closed.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Fabio Comolli · External Since: May 04, 2009 Posts: 7

Hi.

On Fri, Oct 2, 2009 at 7:17 PM, Rafael J. Wysocki <rjw DeleteThis @sisk.pl> wrote:
> On Friday 02 October 2009, Fabio Comolli wrote:
>> Hi.
>> I suppose this is still valid. I had to work around it by rfkill-ing
>> the device during the suspend process and reenabling at resume time.
>
> Thanks for the update.
>
>> I can try to reproduce it with 2.6.31.1 if you want it.
>
> In fact I'm more interested in whether or not it's still present in the Linus'
> tree.
>

Well, I just tried 2.6.32-rc1-git3 and I have to say that it's mostly
useless with my eeepc. The warning didn't show up after resume but it
was impossible to reassociate with my AP and after some tentative the
screen went blank.

I was able to poweroff the netbook using the power button but I'm a
little scared to try again.

Maybe I'll try with -rc3 or something.

> Thanks,
> Rafael
>

Regards,
Fabio
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki · External Since: May 20, 2006 Posts: 1721

On Friday 02 October 2009, Nix wrote:
> On 1 Oct 2009, Rafael J. Wysocki stated:
>
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.30 and 2.6.31. Please verify if it still should
> > be listed and let me know (either way).
>
> The patch fixes it.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14261
> > Subject : e1000e jumbo frames no longer work: 'Unsupported MTU setting'
> > Submitter : Nix <nix.DeleteThis@esperi.org.uk>
> > Date : 2009-09-26 11:16 (6 days old)
> > References : http://marc.info/?l=linux-kernel&m=125396433321342&w=4
> > Handled-By : Alexander Duyck <alexander.duyck.DeleteThis@gmail.com>
> > Patch : http://patchwork.kernel.org/patch/50277/
>
> (Possibly a stable candidate? It's not in 2.6.31.2-to-be, perhaps the
> only patch that isn't. Wink

)

Most likely because it's not in the Linus' tree yet.

[e1000e maintainers, we have a regression fix to merge, please.]

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki · External Since: May 20, 2006 Posts: 1721

On Friday 02 October 2009, Fabio Comolli wrote:
> Hi.
>
> On Fri, Oct 2, 2009 at 7:17 PM, Rafael J. Wysocki <rjw.DeleteThis@sisk.pl> wrote:
> > On Friday 02 October 2009, Fabio Comolli wrote:
> >> Hi.
> >> I suppose this is still valid. I had to work around it by rfkill-ing
> >> the device during the suspend process and reenabling at resume time.
> >
> > Thanks for the update.
> >
> >> I can try to reproduce it with 2.6.31.1 if you want it.
> >
> > In fact I'm more interested in whether or not it's still present in the Linus'
> > tree.
> >
>
> Well, I just tried 2.6.32-rc1-git3 and I have to say that it's mostly
> useless with my eeepc. The warning didn't show up after resume but it
> was impossible to reassociate with my AP and after some tentative the
> screen went blank.
>
> I was able to poweroff the netbook using the power button but I'm a
> little scared to try again.

It shouldn't kill the system cold dead, so as long as you have your data
backed up, you can do some debugging IMHO.

> Maybe I'll try with -rc3 or something.

I guess you should report the issues you have at the moment. Then, it's
actually more likely that someone will take care of fixing them.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Kirsher · External Since: Aug 21, 2009 Posts: 4

On Fri, Oct 2, 2009 at 14:31, Rafael J. Wysocki <rjw.DeleteThis@sisk.pl> wrote:
> On Friday 02 October 2009, Nix wrote:
>> On 1 Oct 2009, Rafael J. Wysocki stated:
>>
>> > The following bug entry is on the current list of known regressions
>> > introduced between 2.6.30 and 2.6.31. Please verify if it still should
>> > be listed and let me know (either way).
>>
>> The patch fixes it.
>>
>> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14261
>> > Subject : e1000e jumbo frames no longer work: 'Unsupported MTU setting'
>> > Submitter : Nix <nix.DeleteThis@esperi.org.uk>
>> > Date : 2009-09-26 11:16 (6 days old)
>> > References : http://marc.info/?l=linux-kernel&m=125396433321342&w=4
>> > Handled-By : Alexander Duyck <alexander.duyck.DeleteThis@gmail.com>
>> > Patch : http://patchwork.kernel.org/patch/50277/
>>
>> (Possibly a stable candidate? It's not in 2.6.31.2-to-be, perhaps the
>> only patch that isn't. Wink

)
>
> Most likely because it's not in the Linus' tree yet.
>
> [e1000e maintainers, we have a regression fix to merge, please.]
>
> Thanks,
> Rafael

Sorry, I forgot to send this patch out last night. I will send it now.

--
Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric Dumazet · External Since: Jul 02, 2009 Posts: 26

Rafael J. Wysocki a écrit :
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.30 and 2.6.31.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14301
> Subject : WARNING: at net/ipv4/af_inet.c:154
> Submitter : Ralf Hildebrandt <Ralf.Hildebrandt.TakeThisOut@charite.de>
> Date : 2009-09-30 12:24 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=125431350218137&w=4
>
>

If commit d99927f4d93f36553699573b279e0ff98ad7dea6
(net: Fix sock_wfree() race) doesnt fix this problem, then
maybe we should take a look at an old patch.

< data mining... running... output results to lkml/netdev >

Random guesses

1) : commit d55d87fdff8252d0e2f7c28c2d443aee17e9d70f
(net: Move rx skb_orphan call to where needed)

A similar problem on SCTP was fixed by commit
1bc4ee4088c9a502db0e9c87f675e61e57fa1734
(sctp: fix warning at inet_sock_destruct() while release sctp socket)

2) CORK and UDP sockets
It seems we can leave an UDP socket with a frame in sk_write_queue
Purge of this queue is done by udp_flush_pending_frames()
This calls ip_flush_pending_frames()
But this function only calls kfree_skb(), not sk_wmem_free_skb()...

Could you try following patch ?

Thanks

[PATCH] net: UDP should not use ip_flush_pending_frames()

Now xmit UDP messages are charged, we must take care of calling right
skb freeing function.

In case a close() is performed on a socket where CORKED frame
is still queued in sk_write_queue, calling ip_flush_pending_frames()
leads to sk_forward_alloc leak.

Reported-by: Ralf Hildebrandt <Ralf.Hildebrandt.TakeThisOut@charite.de>
Signed-off-by: Eric Dumazet <eric.dumazet.TakeThisOut@gmail.com>
---
include/net/sock.h | 10 ++++++++++
include/net/tcp.h | 10 ----------
net/ipv4/tcp.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/udp.c | 2 +-
5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index 1621935..7c80fec 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -882,6 +882,16 @@ static inline void sk_wmem_free_skb(struct sock *sk, struct sk_buff *skb)
__kfree_skb(skb);
}

+/* write queue abstraction */
+static inline void sk_write_queue_purge(struct sock *sk)
+{
+ struct sk_buff *skb;
+
+ while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
+ sk_wmem_free_skb(sk, skb);
+ sk_mem_reclaim(sk);
+}
+
/* Used by processes to "lock" a socket state, so that
* interrupts and bottom half handlers won't change it
* from under us. It essentially blocks any incoming
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 03a49c7..4c7036a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1220,16 +1220,6 @@ static inline void tcp_put_md5sig_pool(void)
put_cpu();
}

-/* write queue abstraction */
-static inline void tcp_write_queue_purge(struct sock *sk)
-{
- struct sk_buff *skb;
-
- while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
- sk_wmem_free_skb(sk, skb);
- sk_mem_reclaim(sk);
-}
-
static inline struct sk_buff *tcp_write_queue_head(struct sock *sk)
{
return skb_peek(&sk->sk_write_queue);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 64d0af6..0124f5b 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1992,7 +1992,7 @@ int tcp_disconnect(struct sock *sk, int flags)

tcp_clear_xmit_timers(sk);
__skb_queue_purge(&sk->sk_receive_queue);
- tcp_write_queue_purge(sk);
+ sk_write_queue_purge(sk);
__skb_queue_purge(&tp->out_of_order_queue);
#ifdef CONFIG_NET_DMA
__skb_queue_purge(&sk->sk_async_wait_queue);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 7cda24b..76e59df 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1845,7 +1845,7 @@ void tcp_v4_destroy_sock(struct sock *sk)
tcp_cleanup_congestion_control(sk);

/* Cleanup up the write buffer. */
- tcp_write_queue_purge(sk);
+ sk_write_queue_purge(sk);

/* Cleans up our, hopefully empty, out_of_order_queue. */
__skb_queue_purge(&tp->out_of_order_queue);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 6ec6a8a..58007d1 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -464,7 +464,7 @@ void udp_flush_pending_frames(struct sock *sk)
if (up->pending) {
up->len = 0;
up->pending = 0;
- ip_flush_pending_frames(sk);
+ sk_write_queue_purge(sk);
}
}
EXPORT_SYMBOL(udp_flush_pending_frames);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric Dumazet · External Since: Jul 02, 2009 Posts: 26

Eric Dumazet a écrit :
> Rafael J. Wysocki a écrit :
>> This message has been generated automatically as a part of a report
>> of regressions introduced between 2.6.30 and 2.6.31.
>>
>> The following bug entry is on the current list of known regressions
>> introduced between 2.6.30 and 2.6.31. Please verify if it still should
>> be listed and let me know (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14301
>> Subject : WARNING: at net/ipv4/af_inet.c:154
>> Submitter : Ralf Hildebrandt <Ralf.Hildebrandt.RemoveThis@charite.de>
>> Date : 2009-09-30 12:24 (2 days old)
>> References : http://marc.info/?l=linux-kernel&m=125431350218137&w=4
>>
>>
>
> If commit d99927f4d93f36553699573b279e0ff98ad7dea6
> (net: Fix sock_wfree() race) doesnt fix this problem, then
> maybe we should take a look at an old patch.
>
> < data mining... running... output results to lkml/netdev >
>
> Random guesses
>
> 1) : commit d55d87fdff8252d0e2f7c28c2d443aee17e9d70f
> (net: Move rx skb_orphan call to where needed)
>
> A similar problem on SCTP was fixed by commit
> 1bc4ee4088c9a502db0e9c87f675e61e57fa1734
> (sctp: fix warning at inet_sock_destruct() while release sctp socket)
>
> 2) CORK and UDP sockets
> It seems we can leave an UDP socket with a frame in sk_write_queue
> Purge of this queue is done by udp_flush_pending_frames()
> This calls ip_flush_pending_frames()
> But this function only calls kfree_skb(), not sk_wmem_free_skb()...
>
>
> Could you try following patch ?
>

Hmm, I missed the ip_cork_release(), here is an updated version.

[PATCH] net: UDP should not use ip_flush_pending_frames()

Now xmit UDP messages are charged, we must take care of calling right
skb freeing function.

In case a close() is performed on a socket where CORKED frame
is still queued in sk_write_queue, calling ip_flush_pending_frames()
leads to sk_forward_alloc leak.

Fix this by calling sk_write_queue_purge() and ip_cork_release()
instead.

Reported-by: Ralf Hildebrandt <Ralf.Hildebrandt.RemoveThis@charite.de>
Signed-off-by: Eric Dumazet <eric.dumazet.RemoveThis@gmail.com>
---
include/net/ip.h | 1 +
include/net/sock.h | 10 ++++++++++
include/net/tcp.h | 10 ----------
net/ipv4/tcp.c | 2 +-
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/udp.c | 3 ++-
6 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/include/net/ip.h b/include/net/ip.h
index 2f47e54..c8d8828 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -117,6 +117,7 @@ extern int ip_generic_getfrag(void *from, char *to, int offset, int len, int od
extern ssize_t ip_append_page(struct sock *sk, struct page *page,
int offset, size_t size, int flags);
extern int ip_push_pending_frames(struct sock *sk);
+extern void ip_cork_release(struct inet_sock *);
extern void ip_flush_pending_frames(struct sock *sk);

/* datagram.c */
diff --git a/include/net/sock.h b/include/net/sock.h
index 1621935..7c80fec 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -882,6 +882,16 @@ static inline void sk_wmem_free_skb(struct sock *sk, struct sk_buff *skb)
__kfree_skb(skb);
}

+/* write queue abstraction */
+static inline void sk_write_queue_purge(struct sock *sk)
+{
+ struct sk_buff *skb;
+
+ while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
+ sk_wmem_free_skb(sk, skb);
+ sk_mem_reclaim(sk);
+}
+
/* Used by processes to "lock" a socket state, so that
* interrupts and bottom half handlers won't change it
* from under us. It essentially blocks any incoming
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 03a49c7..4c7036a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1220,16 +1220,6 @@ static inline void tcp_put_md5sig_pool(void)
put_cpu();
}

-/* write queue abstraction */
-static inline void tcp_write_queue_purge(struct sock *sk)
-{
- struct sk_buff *skb;
-
- while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
- sk_wmem_free_skb(sk, skb);
- sk_mem_reclaim(sk);
-}
-
static inline struct sk_buff *tcp_write_queue_head(struct sock *sk)
{
return skb_peek(&sk->sk_write_queue);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 64d0af6..0124f5b 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1992,7 +1992,7 @@ int tcp_disconnect(struct sock *sk, int flags)

tcp_clear_xmit_timers(sk);
__skb_queue_purge(&sk->sk_receive_queue);
- tcp_write_queue_purge(sk);
+ sk_write_queue_purge(sk);
__skb_queue_purge(&tp->out_of_order_queue);
#ifdef CONFIG_NET_DMA
__skb_queue_purge(&sk->sk_async_wait_queue);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 7cda24b..76e59df 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1845,7 +1845,7 @@ void tcp_v4_destroy_sock(struct sock *sk)
tcp_cleanup_congestion_control(sk);

/* Cleanup up the write buffer. */
- tcp_write_queue_purge(sk);
+ sk_write_queue_purge(sk);

/* Cleans up our, hopefully empty, out_of_order_queue. */
__skb_queue_purge(&tp->out_of_order_queue);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 6ec6a8a..b6370d0 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -464,7 +464,8 @@ void udp_flush_pending_frames(struct sock *sk)
if (up->pending) {
up->len = 0;
up->pending = 0;
- ip_flush_pending_frames(sk);
+ sk_write_queue_purge(sk);
+ ip_cork_release(inet_sk(sk));
}
}
EXPORT_SYMBOL(udp_flush_pending_frames);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Fabio Comolli · External Since: May 04, 2009 Posts: 7

Hi Rafael.

On Fri, Oct 2, 2009 at 11:42 PM, Rafael J. Wysocki <rjw.RemoveThis@sisk.pl> wrote:
> On Friday 02 October 2009, Fabio Comolli wrote:
>> Hi.
>>
>> On Fri, Oct 2, 2009 at 7:17 PM, Rafael J. Wysocki <rjw.RemoveThis@sisk.pl> wrote:
>> > On Friday 02 October 2009, Fabio Comolli wrote:
>> >> Hi.
>> >> I suppose this is still valid. I had to work around it by rfkill-ing
>> >> the device during the suspend process and reenabling at resume time.
>> >
>> > Thanks for the update.
>> >
>> >> I can try to reproduce it with 2.6.31.1 if you want it.
>> >
>> > In fact I'm more interested in whether or not it's still present in the Linus'
>> > tree.
>> >
>>
>> Well, I just tried 2.6.32-rc1-git3 and I have to say that it's mostly
>> useless with my eeepc. The warning didn't show up after resume but it
>> was impossible to reassociate with my AP and after some tentative the
>> screen went blank.
>>
>> I was able to poweroff the netbook using the power button but I'm a
>> little scared to try again.
>
> It shouldn't kill the system cold dead, so as long as you have your data
> backed up, you can do some debugging IMHO.
>
>> Maybe I'll try with -rc3 or something.
>
> I guess you should report the issues you have at the moment. Then, it's
> actually more likely that someone will take care of fixing them.
>

OK. This is what I've been able to come up with so far:

* with 2.6.31.x the warning shows up more or less every suspend-to-ram cycle;
* with 2.6.32-rc the warning never shows up;
* with 2.6.31.x when the warning shows up wifi is unusable until rfkill cycle;
* whith 2.6.32-rc after suspend-to-ram cycle wifi is unusable and
rfkill does not cure it unless I rfkill it off - suspend-to-ram -
resume - rfkill it on. This seems to work.

When wifi does not work in 2.6.32-rc the messages show:

---------------------------------------------
[ 49.647233] wlan0: direct probe to AP xx:xx:xx:xx:xx:xx (try 1)
[ 49.649234] wlan0: direct probe responded
[ 49.649244] wlan0: authenticate with AP xx:xx:xx:xx:xx:xx (try 1)
[ 49.650546] wlan0: authenticated
[ 49.650581] wlan0: associate with AP xx:xx:xx:xx:xx:xx (try 1)
[ 49.652183] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x451
status=12 aid=1)
[ 49.652190] wlan0: AP denied association (code=12)
---------------------------------------------

The script I feed to pm-utils to have wifi work across the
suspend-to-ram cycle is just:

---------------------------------------------
#!/bin/sh
RFKILL=`basename /sys/devices/platform/eeepc/rfkill/*`

case "$1" in
hibernate|suspend)
cat /sys/devices/platform/eeepc/rfkill/$RFKILL/state > /tmp/suspend
echo 0 > /sys/devices/platform/eeepc/rfkill/$RFKILL/state
;;
thaw|resume)
cat /tmp/suspend > /sys/devices/platform/eeepc/rfkill/$RFKILL/state
;;
*) exit $NA
;;
esac
---------------------------------------------

I can confirm that with 32-rc sometimes the screen flickers badly
after resume, for example running a simple dmesg command. However,
nothing is written in the logs, neither messages nor Xorg.0.log.
Chipset is i915.

Hope this helps. Please note that git is not an option for me on this machine.

> Thanks,
> Rafael

Regards,
Fabio

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo.RemoveThis@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric Dumazet · External Since: Jul 02, 2009 Posts: 26

Eric Dumazet a écrit :
> Eric Dumazet a écrit :
>> Rafael J. Wysocki a écrit :
>>> This message has been generated automatically as a part of a report
>>> of regressions introduced between 2.6.30 and 2.6.31.
>>>
>>> The following bug entry is on the current list of known regressions
>>> introduced between 2.6.30 and 2.6.31. Please verify if it still should
>>> be listed and let me know (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14301
>>> Subject : WARNING: at net/ipv4/af_inet.c:154
>>> Submitter : Ralf Hildebrandt <Ralf.Hildebrandt RemoveThis @charite.de>
>>> Date : 2009-09-30 12:24 (2 days old)
>>> References : http://marc.info/?l=linux-kernel&m=125431350218137&w=4
>>>
>>>
>> If commit d99927f4d93f36553699573b279e0ff98ad7dea6
>> (net: Fix sock_wfree() race) doesnt fix this problem, then
>> maybe we should take a look at an old patch.
>>
>> < data mining... running... output results to lkml/netdev >
>>
>> Random guesses
>>
>> 1) : commit d55d87fdff8252d0e2f7c28c2d443aee17e9d70f
>> (net: Move rx skb_orphan call to where needed)
>>
>> A similar problem on SCTP was fixed by commit
>> 1bc4ee4088c9a502db0e9c87f675e61e57fa1734
>> (sctp: fix warning at inet_sock_destruct() while release sctp socket)
>>
>> 2) CORK and UDP sockets
>> It seems we can leave an UDP socket with a frame in sk_write_queue
>> Purge of this queue is done by udp_flush_pending_frames()
>> This calls ip_flush_pending_frames()
>> But this function only calls kfree_skb(), not sk_wmem_free_skb()...
>>
>>
>> Could you try following patch ?
>>
>
> Hmm, I missed the ip_cork_release(), here is an updated version.
>

Please ignore this patch, I was wrong, sk_forward_alloc is not used
on xmit side for udp, only receive side. CORK/UDP should be fine

Investigation still needed...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Tokarev · External Since: Nov 12, 2004 Posts: 140

Michael Tokarev wrote:
> Cyrill Gorcunov wrote:
>> On 10/2/09, Michael Tokarev <mjt DeleteThis @tls.msk.ru> wrote:
>>> Michael Tokarev wrote:
>>>> Cyrill Gorcunov wrote:
>>>>> On 10/1/09, Rafael J. Wysocki <rjw DeleteThis @sisk.pl> wrote:
>>>>>> This message has been generated automatically as a part of a report
>>>>>> of regressions introduced between 2.6.30 and 2.6.31.
>>>>>>
>>>>>> The following bug entry is on the current list of known regressions
>>>>>> introduced between 2.6.30 and 2.6.31. Please verify if it still
>>>>>> should
>>>>>> be listed and let me know (either way).
>>>>> Michael has been asked to bisect it (if possible). I cant reproduce it
>>>>> in kvm unfortunately.
>>>> Yes, and that's what I'll be trying to do shortly.
>>>> I had other issues to sort out and wasn't able to
>>>> get to it in few last days.
>>>>
>>>> Also I've a few other suspects. For example, in this .31
>>>> config I changed from bzip to lzma compression - and that's
>>>> where (or near) kernel is rebooting.
>>> And that was the problem. After switching from LZMA
>>> to BZIP2 kernel boots again.
>>>
>>> Dunno if it can be treated as a regression, but it's
>>> definitely a bug.
>>
>> thanks for tracking it down Michael!
>> Rafael, who is responsible for LZMA now?
>> Cc him please.
>
> Please hold on for a while.
>
> I switched to BZIP2, it booted fine. I switched back to LZMA -
> and that one now boots too. Original bzImage, which were built
> by the same compiler from the same source using the same
> options reboots.
>
> So um... I'm now trying to reproduce it Wink

I performed about 20 kernel recompiles, and finally have some "statistics".
The problem is almost reproduceable, in a sense that I was able to get 6
more cases behaving the same way (rebooting right at early boot on a cel).
And all 3 "non-working" cases were with ccache. Ie, about half out of ~25
compiles done with ccache, and 7 of the resulting kernels are buggy. No
single failure without ccache so far.

Maybe it's some stale .o file cached by ccache (and it indeed looks like
that) -- I didn't try to remove the cache yet (but my guess is that I
wont be able to reproduce the issue with clean cache anymore).

What puzzles me most is the "failure mode". The difference between the
two processors is minimal. Having a corrupt .o file and almost-working
kernel is almost impossible by its own. And hitting this difference with
a corrupt .o file is.. unbelievable.

So I'm declaring it's a false alarm for now, and closing the bug.

/mjt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Cyrill Gorcunov · External Since: Feb 18, 2007 Posts: 128

[Michael Tokarev - Sun, Oct 04, 2009 at 04:14:44PM +0400]
....
>>
>> I switched to BZIP2, it booted fine. I switched back to LZMA -
>> and that one now boots too. Original bzImage, which were built
>> by the same compiler from the same source using the same
>> options reboots.
>>
>> So um... I'm now trying to reproduce it Wink

>
> I performed about 20 kernel recompiles, and finally have some "statistics".
> The problem is almost reproduceable, in a sense that I was able to get 6
> more cases behaving the same way (rebooting right at early boot on a cel).
> And all 3 "non-working" cases were with ccache. Ie, about half out of ~25
> compiles done with ccache, and 7 of the resulting kernels are buggy. No
> single failure without ccache so far.
>
> Maybe it's some stale .o file cached by ccache (and it indeed looks like
> that) -- I didn't try to remove the cache yet (but my guess is that I
> wont be able to reproduce the issue with clean cache anymore).
>
> What puzzles me most is the "failure mode". The difference between the
> two processors is minimal. Having a corrupt .o file and almost-working
> kernel is almost impossible by its own. And hitting this difference with
> a corrupt .o file is.. unbelievable.
>
> So I'm declaring it's a false alarm for now, and closing the bug.

ok, thanks for hard work on this Michael!

>
> /mjt
>
-- Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Mikael Pettersson · External Since: Jun 10, 2006 Posts: 79

Rafael J. Wysocki wrote:
> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D14256
> Subject : kernel BUG at fs/ext3/super.c:435
> Submitter : Mikael Pettersson <mikpe.DeleteThis@it.uu.se>
> Date : 2009-09-21 7:29 (11 days old)
> References : http://marc.info/?l=3Dlinux-kernel&m=3D125351816109264&w=3D4

The exact same bug (same cause, same symptom) just hit me again in 2.6.32-rc1.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Karol Lewandowski · External Since: Oct 02, 2009 Posts: 8

On Fri, Oct 02, 2009 at 10:01:43PM +0200, Karol Lewandowski wrote:
> On Fri, Oct 02, 2009 at 10:32:26AM +0100, Mel Gorman wrote:
> > Apparently, Karol Lewandowski (cc added) has a reliable
> > reproduction case for when the firmware loading problem occurs
> > (http://lkml.org/lkml/2009/9/30/242). While it's not the same problem exactly,
> > it's probable they're related. I'm hoping the problem commit can be identified
> > by his bisection whenever he gets around to it.
>
> Unfortunately, I've had little success with bisecting this problem.
> I've spend fair amount of time today trying to reproduce this problem,
> but I'm unable to do so even on kernels that failed "easily" before.

I've been able to reproduce this problem on 2.6.32-rc1. No "luck"
with bisecting, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki · External Since: May 20, 2006 Posts: 1721

On Sunday 04 October 2009, Mikael Pettersson wrote:
> Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.30 and 2.6.31. Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D14256
> > Subject : kernel BUG at fs/ext3/super.c:435
> > Submitter : Mikael Pettersson <mikpe.RemoveThis@it.uu.se>
> > Date : 2009-09-21 7:29 (11 days old)
> > References : http://marc.info/?l=3Dlinux-kernel&m=3D125351816109264&w=3D4
>
> The exact same bug (same cause, same symptom) just hit me again in 2.6.32-rc1.

Thanks for the update.

Could you check the current Linus' tree, please? There are some known
regression fixes in there.

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Mikael Pettersson · External Since: Jun 10, 2006 Posts: 79

Rafael J. Wysocki writes:
> On Sunday 04 October 2009, Mikael Pettersson wrote:
> > Rafael J. Wysocki wrote:
> > > The following bug entry is on the current list of known regressions
> > > introduced between 2.6.30 and 2.6.31. Please verify if it still should
> > > be listed and let me know (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D14256
> > > Subject : kernel BUG at fs/ext3/super.c:435
> > > Submitter : Mikael Pettersson <mikpe DeleteThis @it.uu.se>
> > > Date : 2009-09-21 7:29 (11 days old)
> > > References : http://marc.info/?l=3Dlinux-kernel&m=3D125351816109264&w=3D4
> >
> > The exact same bug (same cause, same symptom) just hit me again in 2.6.32-rc1.
>
> Thanks for the update.
>
> Could you check the current Linus' tree, please? There are some known
> regression fixes in there.

I tried simplified versions of the bug trigger on two machines
running 2.6.32-rc1-git6, and neither triggered the kernel bug.

The original recipe involved doing a glibc rebuild, run its test
suite, install it, and reboot. Today however machine 1 was already
doing a rebuild so after the rebuild it did a reboot into the new
kernel before the install. The second machine booted the new kernel
directly to install the binary packages from the first machine.

I'll re-run the full bug trigger recipe on a third machine later next
week (it must rebuild glibc itself anyway due to arch differences).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Justin Mattock · External Since: Apr 14, 2009 Posts: 12

On Thu, Oct 1, 2009 at 12:56 PM, Rafael J. Wysocki <rjw.TakeThisOut@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.30 and 2.6.31.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14267
> Subject : Disassociating atheros wlan
> Submitter : Kristoffer Ericson <kristoffer.ericson.TakeThisOut@gmail.com>
> Date : 2009-09-24 10:16 (8 days old)
> References : http://marc.info/?l=linux-kernel&m=125378723723384&w=4
>
>
>

Sorry for the delay
(spent some time in bodie).
yes it should be still open.

--
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Frans Pop · External Since: May 04, 2006 Posts: 460

On Friday 02 October 2009, Frans Pop wrote:
> On Thursday 01 October 2009, Rafael J. Wysocki wrote:
> > Bug-EntryÂ Â Â Â Â : http://bugzilla.kernel.org/show_bug.cgi?id=14141
> > SubjectÂ Â Â Â Â Â Â : order 2 page allocation failures in iwlagn
> > SubmitterÂ Â Â Â Â : Frans Pop <elendil.RemoveThis@planet.nl>
> > DateÂ Â Â Â Â Â Â Â Â Â : 2009-09-06 7:40 (26 days old)
> > ReferencesÂ Â Â Â : http://marc.info/?l=linux-kernel&m=125222287419691&w=4
> > Handled-ByÂ Â Â Â : Pekka Enberg <penberg.RemoveThis@cs.helsinki.fi>
>
> I'm not sure about this.
>
> The error messages from failed allocations should now be a lot less as a
> result of this commit:
> commit f82a924cc88a5541df1d4b9d38a0968cd077a051
> Author: Reinette Chatre <reinette.chatre.RemoveThis@intel.com>
> Date: Â Thu Sep 17 10:43:56 2009 -0700
> Â Â iwlwifi: reduce noise when skb allocation fails
>
> That commit is in mainline, and I'm not sure if it is important enough
> for a stable update (AFAICT it's not listed for 2.6.31.2).
>
> That commit is mostly cosmetic, but possibly the real regression is not
> in iwlagn but in the way memory is freed/defragmented. That aspect was
> also reported by Bartlomiej (#14016) and was extensively discussed
> (without a clear conclusion) here: http://lkml.org/lkml/2009/8/26/140.

I may be getting somewhere with this. I just got the allocation failures
included below on .32-rc3. Note that these are not the "fixable" failures
that got suppressed with the commit referenced above, but the "this could
affect networking" failures that are still reported.

What I was doing when I got them is also interesting:
- a kernel build
- a gitk for the kernel tree (with full history this uses ~40% of memory)
- by mistake I then started a _second_ gitk

The second gitk (which shows as 'wish8.5' in top) caused a massive swap
out which brought the system to a standstill for a while (with huge
latencies as well, including a completely stuck mouse cursor, which
happens rarely).
The system has 2GB RAM + 2GB swap, so IIUC there is no danger of getting
into an OOM as the first gitk can be swapped out completely.

I'll dig into this a bit more as it looks like this should be reproducible,
probably even without the kernel build. Next step is to see how .30 behaves
in the same situation.

Even if it is reproducible with .30, I wonder if the kernel shouldn't be
more robust in this situation. Currently it seems to allow one single
process to claim so much memory before swapping out that "normal" operation
of other processes is affected. I can understand that such a situation may
be hard to avoid on a very busy system where multiple processes start
claiming (a lot of) memory at roughly the same time, but I'd say it should
be avoidable if a single process is the culprit.

BTW, the system recovered completely, although that took some time (the
first gitk remained visible in top long after I closed its window; I think
because the system was busy swapping it back in before terminating it).

Cheers,
FJP

kcryptd: page allocation failure. order:2, mode:0x4020
Pid: 1483, comm: kcryptd Not tainted 2.6.32-rc3 #22
Call Trace:
<IRQ> [<ffffffff8107c3d5>] __alloc_pages_nodemask+0x5a2/0x5ec
[<ffffffff81264892>] ? _spin_unlock+0x9/0xb
[<ffffffff811e73cd>] ? __alloc_skb+0x3c/0x15b
[<ffffffffa03202cb>] ? iwl_rx_allocate+0x8f/0x305 [iwlcore]
[<ffffffff8107c431>] __get_free_pages+0x12/0x41
[<ffffffff8109cb1a>] __kmalloc_track_caller+0x3b/0xed
[<ffffffff811e73f7>] __alloc_skb+0x66/0x15b
[<ffffffffa03202cb>] iwl_rx_allocate+0x8f/0x305 [iwlcore]
[<ffffffffa0320557>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
[<ffffffffa035c0c8>] iwl_rx_handle+0x3a8/0x3c1 [iwlagn]
[<ffffffff81051add>] ? sched_clock_local+0x1c/0x80
[<ffffffffa035c60d>] iwl_irq_tasklet_legacy+0x52c/0x7a4 [iwlagn]
[<ffffffffa0317aaf>] ? __iwl_read32+0xa5/0xb4 [iwlcore]
[<ffffffff8103efb8>] tasklet_action+0x71/0xbc
[<ffffffff8103f837>] __do_softirq+0x96/0x11b
[<ffffffff8100cabc>] call_softirq+0x1c/0x28
[<ffffffff8100e5ef>] do_softirq+0x33/0x6b
[<ffffffff8103f5c5>] irq_exit+0x36/0x75
[<ffffffff8100dcf1>] do_IRQ+0xa3/0xba
[<ffffffff8100c353>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff811199dd>] ? scatterwalk_start+0x11/0x19
[<ffffffff8111bbca>] ? blkcipher_walk_first+0x173/0x196
[<ffffffff8111b67b>] ? blkcipher_walk_done+0xe6/0x1b8
[<ffffffff8111bc35>] ? blkcipher_walk_virt+0x1a/0x1d
[<ffffffffa02001cf>] ? crypto_cbc_encrypt+0x43/0x18e [cbc]
[<ffffffff81127efd>] ? blk_recount_segments+0x1b/0x2c
[<ffffffffa021371e>] ? aes_encrypt+0x0/0xf [aes_x86_64]
[<ffffffff8111af64>] ? async_encrypt+0x38/0x3a
[<ffffffffa01f7b54>] ? crypt_convert+0x1f9/0x28b [dm_crypt]
[<ffffffffa01f8009>] ? kcryptd_crypt+0x423/0x449 [dm_crypt]
[<ffffffffa01f7be6>] ? kcryptd_crypt+0x0/0x449 [dm_crypt]
[<ffffffff81049bfd>] ? worker_thread+0x146/0x1d8
[<ffffffff8104d706>] ? autoremove_wake_function+0x0/0x38
[<ffffffff81049ab7>] ? worker_thread+0x0/0x1d8
[<ffffffff8104d3f4>] ? kthread+0x7d/0x85
[<ffffffff8100c9ba>] ? child_rip+0xa/0x20
[<ffffffff8104d377>] ? kthread+0x0/0x85
[<ffffffff8100c9b0>] ? child_rip+0x0/0x20
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 171
CPU 1: hi: 186, btch: 31 usd: 177
active_anon:298532 inactive_anon:100163 isolated_anon:52
active_file:3993 inactive_file:4001 isolated_file:12
unevictable:399 dirty:0 writeback:76102 unstable:0 buffer:125
free:14107 slab_reclaimable:4510 slab_unreclaimable:20421
mapped:7949 shmem:0 pagetables:4437 bounce:0
DMA free:7928kB min:40kB low:48kB high:60kB active_anon:3340kB inactive_anon:3608kB active_file:384kB
inactive_file:472kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15336kB mlocked:0kB
dirty:0kB writeback:80kB mapped:256kB shmem:0kB slab_reclaimable:12kB slab_unreclaimable:104kB kernel_stack:0kB
pagetables:16kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 1976 1976 1976
DMA32 free:48500kB min:5664kB low:7080kB high:8496kB active_anon:1190788kB inactive_anon:397044kB active_file:15588kB
inactive_file:15532kB unevictable:1596kB isolated(anon):208kB isolated(file):48kB present:2023748kB mlocked:1596kB
dirty:0kB writeback:304328kB mapped:31540kB shmem:0kB slab_reclaimable:18028kB slab_unreclaimable:81496kB kernel_stack:1672kB
pagetables:17732kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 19*4kB 13*8kB 3*16kB 7*32kB 11*64kB 11*128kB 5*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7940kB
DMA32: 9299*4kB 1341*8kB 4*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 48500kB
98572 total pagecache pages
90213 pages in swap cache
Swap cache stats: add 175874, delete 85661, find 7850/8731
Free swap = 1425944kB
Total swap = 2097144kB
518064 pages RAM
10350 pages reserved
82388 pages shared
437481 pages non-shared
iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 free buffers remaining.
swapper: page allocation failure. order:2, mode:0x4020
Pid: 0, comm: swapper Not tainted 2.6.32-rc3 #22
Call Trace:
<IRQ> [<ffffffff8107c3d5>] __alloc_pages_nodemask+0x5a2/0x5ec
[<ffffffff81264892>] ? _spin_unlock+0x9/0xb
[<ffffffff811e73cd>] ? __alloc_skb+0x3c/0x15b
[<ffffffffa03202cb>] ? iwl_rx_allocate+0x8f/0x305 [iwlcore]
[<ffffffff8107c431>] __get_free_pages+0x12/0x41
[<ffffffff8109cb1a>] __kmalloc_track_caller+0x3b/0xed
[<ffffffff811e73f7>] __alloc_skb+0x66/0x15b
[<ffffffffa03202cb>] iwl_rx_allocate+0x8f/0x305 [iwlcore]
[<ffffffffa0320557>] iwl_rx_replenish_now+0x16/0x23 [iwlcore]
[<ffffffffa035c0c8>] iwl_rx_handle+0x3a8/0x3c1 [iwlagn]
[<ffffffffa035c60d>] iwl_irq_tasklet_legacy+0x52c/0x7a4 [iwlagn]
[<ffffffffa0317aaf>] ? __iwl_read32+0xa5/0xb4 [iwlcore]
[<ffffffff8103efb8>] tasklet_action+0x71/0xbc
[<ffffffff8103f837>] __do_softirq+0x96/0x11b
[<ffffffff8100cabc>] call_softirq+0x1c/0x28
[<ffffffff8100e5ef>] do_softirq+0x33/0x6b
[<ffffffff8103f5c5>] irq_exit+0x36/0x75
[<ffffffff8100dcf1>] do_IRQ+0xa3/0xba
[<ffffffff8100c353>] ret_from_intr+0x0/0xa
<EOI> [<ffffffffa0278ec7>] ? acpi_idle_enter_simple+0xf9/0x127 [processor]
[<ffffffffa0278ebd>] ? acpi_idle_enter_simple+0xef/0x127 [processor]
[<ffffffff811da545>] ? cpuidle_idle_call+0x8c/0xc7
[<ffffffff8100ae2e>] ? cpu_idle+0x55/0x8d
[<ffffffff8125432d>] ? rest_init+0x61/0x63
[<ffffffff81436c3e>] ? start_kernel+0x348/0x353
[<ffffffff8143629a>] ? x86_64_start_reservations+0xaa/0xae
[<ffffffff8143637f>] ? x86_64_start_kernel+0xe1/0xe8
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 171
CPU 1: hi: 186, btch: 31 usd: 155
active_anon:297901 inactive_anon:99948 isolated_anon:52
active_file:3920 inactive_file:3948 isolated_file:12
unevictable:399 dirty:0 writeback:34634 unstable:0 buffer:125
free:23390 slab_reclaimable:4510 slab_unreclaimable:11714
mapped:7819 shmem:0 pagetables:4437 bounce:0
DMA free:7908kB min:40kB low:48kB high:60kB active_anon:3340kB inactive_anon:3608kB active_file:384kB
inactive_file:472kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15336kB mlocked:0kB
dirty:0kB writeback:36kB mapped:256kB shmem:0kB slab_reclaimable:12kB slab_unreclaimable:12kB kernel_stack:0kB
pagetables:16kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 1976 1976 1976
DMA32 free:85652kB min:5664kB low:7080kB high:8496kB active_anon:1188264kB inactive_anon:396184kB active_file:15296kB
inactive_file:15320kB unevictable:1596kB isolated(anon):208kB isolated(file):48kB present:2023748kB mlocked:1596kB
dirty:0kB writeback:138500kB mapped:31020kB shmem:0kB slab_reclaimable:18028kB slab_unreclaimable:46844kB
kernel_stack:1672kB pagetables:17732kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 17*4kB 12*8kB 4*16kB 6*32kB 11*64kB 11*128kB 5*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 7908kB
DMA32: 12419*4kB 4439*8kB 1*16kB 0*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 85652kB
97616 total pagecache pages
89394 pages in swap cache
Swap cache stats: add 175906, delete 86512, find 7850/8733
Free swap = 1425864kB
Total swap = 2097144kB
518064 pages RAM
10350 pages reserved
82282 pages shared
428383 pages non-shared
iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 free buffers remaining.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Frans Pop · External Since: May 04, 2006 Posts: 460

On Monday 05 October 2009, Frans Pop wrote:
> I'll dig into this a bit more as it looks like this should be
> reproducible, probably even without the kernel build. Next step is to
> see how .30 behaves in the same situation.

This looks conclusive. I tested .30 and .32-rc3 from clean reboots and
only starting gitk. I only started music playing in the background
(amarok) from an NFS share to ensure network activity.

With .32-rc3 I got 4 SKB allocation errors while starting the *second* gitk
instance. And the system was completely frozen with music stopped until gitk
finished loading.

With .30 I was able to start *three* gitk's (which meant 2 of them got
(partially) swapped out) without any allocation errors. And with the system
remaining relatively responsive. There was a short break in the music while
I started the 2nd instance, but it just continued playing afterwards. There
was also some mild latency in the mouse cursor, but nothing like the full
desktop freeze I get with .32-rc3.

With .30 I looked at /proc/buddyinfo while the 3rd gitk was being started,
and that looked fairly healthy all the time:
Node 0, zone DMA 5 9 22 20 21 11 0 0 0 0 1
Node 0, zone DMA32 579 67 25 8 5 1 1 0 1 1 0
Node 0, zone DMA 5 9 22 20 21 11 0 0 0 0 1
Node 0, zone DMA32 276 54 13 15 8 10 3 1 1 1 0
Node 0, zone DMA 4 9 22 20 21 11 0 0 0 0 1
Node 0, zone DMA32 119 45 24 18 12 4 5 2 1 1 0
Node 0, zone DMA 4 9 22 20 21 11 0 0 0 0 1
Node 0, zone DMA32 527 13 9 5 5 3 2 1 1 1 0
Node 0, zone DMA 5 9 22 20 21 11 0 0 0 0 1
Node 0, zone DMA32 1375 24 7 7 8 5 1 1 0 1 0
Node 0, zone DMA 5 9 22 20 21 11 0 0 0 0 1
Node 0, zone DMA32 329 21 3 3 17 8 5 1 0 1 0

With .32 it was obviously impossible to get that info due to the total
freeze of the desktop. Not sure if the scheduler changes in .32 contribute
to this. Guess I could find out by doing the same test with .31.

One thing I should mention: my swap is an LVM volume that's in a VG that's
on a LUKS encrypted partition.

Does this give you enough info to go on, or should I try a bisection?

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/