2.6.36-rc3: Reported regressions from 2.6.35

2.6.36-rc3: Reported regressions from 2.6.35

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.35,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.35, please let us
know either and we'll add them to the list.  Also, please let us know
if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2010-08-30       21       16          15


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
Subject		: kdump regression compared to v2.6.35
Submitter	: CAI Qian <caiqian@redhat.com>
Date		: 2010-08-27 12:35 (3 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj@kernel.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17331
Subject		: BUG: scheduling while atomic
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-27 7:59 (3 days old)
Message-ID	: <20100827075911.GA5966@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128289602925505&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17321
Subject		: i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e
Submitter	: Arno Schuring <aelschuring@hotmail.com>
Date		: 2010-08-27 20:04 (3 days old)
Message-ID	: <4C781A3A.4010707@hotmail.com>
References	: http://marc.info/?l=linux-kernel&m=128294076822387&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17311
Subject		: 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2010-08-27 1:56 (3 days old)
First-Bad-Commit: http://git.kernel.org/linus/5a652052fedbd7869572c757dd2ffc2ed420c69d
Message-ID	: <AANLkTinHbEW36D5R9NSrGgfbOC0Hri3Tg-fA0iR92Udi@mail.gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128287422106267&w=2
Handled-By	: Johannes Berg <johannes@sipsolutions.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17301
Subject		: i915: 2.6.36-rc2 wrong resolution on gdm start
Submitter	: Ivan Bulatovic <combuster@gmx.com>
Date		: 2010-08-24 1:00 (6 days old)
First-Bad-Commit: http://git.kernel.org/linus/9d0498a2bf7455159b317f19531a3e5db2ecc9c4
Message-ID	: <1282611655.2177.19.camel@localhost.localdomain>
References	: http://marc.info/?l=linux-kernel&m=128261168202306&w=2
Handled-By	: Chris Wilson <chris@chris-wilson.co.uk>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17151
Subject		: i915: 2.6.36-rc2 hoses my Intel display
Submitter	: Jonathan Corbet <corbet@lwn.net>
Date		: 2010-08-23 17:01 (7 days old)
First-Bad-Commit: http://git.kernel.org/linus/32aad86fe88e7323d4fc5e9e423abcee0d55a03d
Message-ID	: <20100823110145.08eb72fd@bike.lwn.net>
References	: http://marc.info/?l=linux-kernel&m=128258293327326&w=2
Handled-By	: Chris Wilson <chris@chris-wilson.co.uk>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17131
Subject		: WARN with 3c905 boomerang NIC
Submitter	: Doug Nazar <nazard.lkml@gmail.com>
Date		: 2010-08-22 6:35 (8 days old)
Message-ID	: <4C70C516.5020404@gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128245894300623&w=2
Handled-By	: David Miller <davem@davemloft.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject		: 2.6.36-rc1 on zaurus: bluetooth regression
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2010-08-21 15:24 (9 days old)
Message-ID	: <20100821152445.GA1536@ucw.cz>
References	: http://marc.info/?l=linux-kernel&m=128240433828087&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17041
Subject		: 2.6.36-rc1 hangs during XFS barrier test for /
Submitter	: Torsten Kaiser <just.for.lkml@googlemail.com>
Date		: 2010-08-20 (10 days old)
Message-ID	: <AANLkTim1PXibiY98GUdMj-UZLTav+n7GAnJ0Mjn6_5a3@mail.gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128231691708710&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17021
Subject		: [REGRESSION] [2.6.36-rc1] [DRM INTEL] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28.
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2010-08-18 18:46 (12 days old)
Message-ID	: <201008182046.37732.maciej.rutecki@gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128215721507666&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject		: qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter	: Meelis Roos <mroos@linux.ee>
Date		: 2010-08-19 21:03 (11 days old)
Message-ID	: <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
References	: http://marc.info/?l=linux-kernel&m=128225184900892&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16961
Subject		: kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-19 9:54 (11 days old)
Message-ID	: <20100819095429.GA5201@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
Handled-By	: Avi Kivity <avi@redhat.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject		: hackbench regression with 2.6.36-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2010-08-18 6:18 (12 days old)
Message-ID	: <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References	: http://marc.info/?l=linux-kernel&m=128211235904910&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16881
Subject		: [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.
Submitter	:  <trapdoor6@gmail.com>
Date		: 2010-08-24 12:20 (6 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16626
Subject		: Machine hangs with EIP at skb_copy_and_csum_dev
Submitter	: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Date		: 2010-08-19 09:57 (11 days old)
Handled-By	:  Eric Dumazet <eric.dumazet@gmail.com>


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16629
Subject		: fix BUG: using smp_processor_id() in preemptible code (resend)
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-18 9:11 (12 days old)
Message-ID	: <20100818091157.GA5238@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128212276618793&w=2
Handled-By	: H. Peter Anvin <hpa@zytor.com>
Patch		: http://marc.info/?l=linux-kernel&m=128212276618793&w=2


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.35,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=16444

Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.

Thanks!

[Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16626
Subject		: Machine hangs with EIP at skb_copy_and_csum_dev
Submitter	: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Date		: 2010-08-19 09:57 (11 days old)
Handled-By	:  Eric Dumazet <eric.dumazet@gmail.com>

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Jarek Poplawski]

On Tue, Aug 31, 2010 at 08:58:10AM +0300, Plamen Petrov wrote:
> Rafael J. Wysocki ????????????:
> 
> >This message has been generated automatically as a part of a summary report
> >of recent regressions.
> >
> >The following bug entry is on the current list of known regressions
> >from 2.6.35.  Please verify if it still should be listed and let the tracking team
> >know (either way).
> >
> >
> >Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16626
> >Subject		: Machine hangs with EIP at skb_copy_and_csum_dev
> >Submitter	: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> >Date		: 2010-08-19 09:57 (11 days old)
> >Handled-By	:  Eric Dumazet <eric.dumazet@gmail.com>
> >
> >
> 
> Should "generic receive offload" work on a forwarding setup?
> If yes - then the bug should remain open.
> If not - then it's my mistake.

If/since it's on by default it should work and it definitely can't be
your mistake. (Unless we can't find the real reason... ;-)

Jarek P.

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Eric Dumazet]

Plamen, could you test following patch ?

I reproduced problem on a dev machine and following patch cured it.

Thanks

[PATCH] gro: fix different skb headrooms

packets entering GRO might have different headrooms, even for a given
flow (because of implementation details in drivers, like copybreak).
We cant force drivers to deliver packets with a fixed headroom.

1) fix skb_segment()

skb_segment() makes the false assumption headrooms of fragments are same
than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
errors, and crash later in skb_copy_and_csum_dev()

2) allocate a minimal skb for head of frag_list

skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
allocate a fresh skb. This adds NET_SKB_PAD to a padding already
provided by netdevice, depending on various things, like copybreak.

Use alloc_skb() to allocate an exact padding, to reduce cache line
needs:
NET_SKB_PAD + NET_IP_ALIGN

bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626

Many thanks to Plamen Petrov, testing many debugging patches !
With help of Jarek Poplawski.

Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jarek Poplawski <jarkao2@gmail.com>
---
patch against linux-2.6 current tree

 net/core/skbuff.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3a2513f..26396ff 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2573,6 +2573,10 @@ struct sk_buff *skb_segment(struct sk_buff *skb, int features)
 		__copy_skb_header(nskb, skb);
 		nskb->mac_len = skb->mac_len;
 
+		/* nskb and skb might have different headroom */
+		if (nskb->ip_summed == CHECKSUM_PARTIAL)
+			nskb->csum_start += skb_headroom(nskb) - headroom;
+
 		skb_reset_mac_header(nskb);
 		skb_set_network_header(nskb, skb->mac_len);
 		nskb->transport_header = (nskb->network_header +
@@ -2702,8 +2706,8 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
 	} else if (skb_gro_len(p) != pinfo->gso_size)
 		return -E2BIG;
 
-	headroom = skb_headroom(p);
-	nskb = netdev_alloc_skb(p->dev, headroom + skb_gro_offset(p));
+	headroom = NET_SKB_PAD + NET_IP_ALIGN;
+	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
 	if (unlikely(!nskb))
 		return -ENOMEM;
 

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Jarek Poplawski]

On Wed, Sep 01, 2010 at 12:50:51PM +0200, Eric Dumazet wrote:
> Plamen, could you test following patch ?
> 
> I reproduced problem on a dev machine and following patch cured it.
> 
> Thanks
> 
> [PATCH] gro: fix different skb headrooms
> 
> packets entering GRO might have different headrooms, even for a given
> flow (because of implementation details in drivers, like copybreak).
> We cant force drivers to deliver packets with a fixed headroom.
> 
> 1) fix skb_segment()
> 
> skb_segment() makes the false assumption headrooms of fragments are same
> than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> errors, and crash later in skb_copy_and_csum_dev()

Eric, probably I missed something, but since the same test as in
skb_copy_and_csum_dev() gave different result a bit earlier on exactly
the same skb, I've suspected some sharing (or use after free)
problems, so I'm not sure your current diagnose can explain this.
(Unless this old test was dismissed later.)

Thanks,
Jarek P.

> 
> 2) allocate a minimal skb for head of frag_list
> 
> skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
> allocate a fresh skb. This adds NET_SKB_PAD to a padding already
> provided by netdevice, depending on various things, like copybreak.
> 
> Use alloc_skb() to allocate an exact padding, to reduce cache line
> needs:
> NET_SKB_PAD + NET_IP_ALIGN
> 
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
> 
> Many thanks to Plamen Petrov, testing many debugging patches !
> With help of Jarek Poplawski.
> 
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jarek Poplawski <jarkao2@gmail.com>
> ---
> patch against linux-2.6 current tree
> 
>  net/core/skbuff.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 3a2513f..26396ff 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2573,6 +2573,10 @@ struct sk_buff *skb_segment(struct sk_buff *skb, int features)
>  		__copy_skb_header(nskb, skb);
>  		nskb->mac_len = skb->mac_len;
>  
> +		/* nskb and skb might have different headroom */
> +		if (nskb->ip_summed == CHECKSUM_PARTIAL)
> +			nskb->csum_start += skb_headroom(nskb) - headroom;
> +
>  		skb_reset_mac_header(nskb);
>  		skb_set_network_header(nskb, skb->mac_len);
>  		nskb->transport_header = (nskb->network_header +
> @@ -2702,8 +2706,8 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>  	} else if (skb_gro_len(p) != pinfo->gso_size)
>  		return -E2BIG;
>  
> -	headroom = skb_headroom(p);
> -	nskb = netdev_alloc_skb(p->dev, headroom + skb_gro_offset(p));
> +	headroom = NET_SKB_PAD + NET_IP_ALIGN;
> +	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
>  	if (unlikely(!nskb))
>  		return -ENOMEM;
>  
> 
> 

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Eric Dumazet]

Le mercredi 01 septembre 2010 à 11:20 +0000, Jarek Poplawski a écrit :
> On Wed, Sep 01, 2010 at 12:50:51PM +0200, Eric Dumazet wrote:
> > Plamen, could you test following patch ?
> > 
> > I reproduced problem on a dev machine and following patch cured it.
> > 
> > Thanks
> > 
> > [PATCH] gro: fix different skb headrooms
> > 
> > packets entering GRO might have different headrooms, even for a given
> > flow (because of implementation details in drivers, like copybreak).
> > We cant force drivers to deliver packets with a fixed headroom.
> > 
> > 1) fix skb_segment()
> > 
> > skb_segment() makes the false assumption headrooms of fragments are same
> > than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> > errors, and crash later in skb_copy_and_csum_dev()
> 
> Eric, probably I missed something, but since the same test as in
> skb_copy_and_csum_dev() gave different result a bit earlier on exactly
> the same skb, I've suspected some sharing (or use after free)
> problems, so I'm not sure your current diagnose can explain this.
> (Unless this old test was dismissed later.)

Oh, this is because your patch had an error for the gso part that read :

-               rc = ops->ndo_start_xmit(nskb, dev);
+               if (skb_csum_start_bug(skb, 50)) {
+                       kfree_skb(skb);
+                       rc = NETDEV_TX_OK;
+               } else
+                       rc = ops->ndo_start_xmit(nskb, dev);
+
                if (unlikely(rc != NETDEV_TX_OK)) {
                        if (rc & ~NETDEV_TX_MASK)
                                goto out_kfree_gso_skb;

You called skb_csum_start_bug(skb, 50) instead of
skb_csum_start_bug(nskb, 50)

Hope this clarify a bit ;)

Thanks

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Jarek Poplawski]

On Wed, Sep 01, 2010 at 03:57:41PM +0200, Eric Dumazet wrote:
> Le mercredi 01 septembre 2010 ?? 11:20 +0000, Jarek Poplawski a écrit :
> > On Wed, Sep 01, 2010 at 12:50:51PM +0200, Eric Dumazet wrote:
> > > Plamen, could you test following patch ?
> > > 
> > > I reproduced problem on a dev machine and following patch cured it.
> > > 
> > > Thanks
> > > 
> > > [PATCH] gro: fix different skb headrooms
> > > 
> > > packets entering GRO might have different headrooms, even for a given
> > > flow (because of implementation details in drivers, like copybreak).
> > > We cant force drivers to deliver packets with a fixed headroom.
> > > 
> > > 1) fix skb_segment()
> > > 
> > > skb_segment() makes the false assumption headrooms of fragments are same
> > > than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> > > errors, and crash later in skb_copy_and_csum_dev()
> > 
> > Eric, probably I missed something, but since the same test as in
> > skb_copy_and_csum_dev() gave different result a bit earlier on exactly
> > the same skb, I've suspected some sharing (or use after free)
> > problems, so I'm not sure your current diagnose can explain this.
> > (Unless this old test was dismissed later.)
> 
> Oh, this is because your patch had an error for the gso part that read :
> 
> -               rc = ops->ndo_start_xmit(nskb, dev);
> +               if (skb_csum_start_bug(skb, 50)) {
> +                       kfree_skb(skb);
> +                       rc = NETDEV_TX_OK;
> +               } else
> +                       rc = ops->ndo_start_xmit(nskb, dev);
> +
>                 if (unlikely(rc != NETDEV_TX_OK)) {
>                         if (rc & ~NETDEV_TX_MASK)
>                                 goto out_kfree_gso_skb;
> 
> You called skb_csum_start_bug(skb, 50) instead of
> skb_csum_start_bug(nskb, 50)
> 
> Hope this clarify a bit ;)

All clear! Sorry for the false alarm!

Thanks,
Jarek P.

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 01 Sep 2010 12:50:51 +0200

> [PATCH] gro: fix different skb headrooms
> 
> packets entering GRO might have different headrooms, even for a given
> flow (because of implementation details in drivers, like copybreak).
> We cant force drivers to deliver packets with a fixed headroom.
> 
> 1) fix skb_segment()
> 
> skb_segment() makes the false assumption headrooms of fragments are same
> than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> errors, and crash later in skb_copy_and_csum_dev()
> 
> 2) allocate a minimal skb for head of frag_list
> 
> skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
> allocate a fresh skb. This adds NET_SKB_PAD to a padding already
> provided by netdevice, depending on various things, like copybreak.
> 
> Use alloc_skb() to allocate an exact padding, to reduce cache line
> needs:
> NET_SKB_PAD + NET_IP_ALIGN
> 
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
> 
> Many thanks to Plamen Petrov, testing many debugging patches !
> With help of Jarek Poplawski.
> 
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jarek Poplawski <jarkao2@gmail.com>

Good spotting, applied, thanks!

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Plamen Petrov]

На 01.9.2010 г. 13:50, Eric Dumazet написа:
> Plamen, could you test following patch ?
>
> I reproduced problem on a dev machine and following patch cured it.
>
> Thanks
>
> [PATCH] gro: fix different skb headrooms
>
> packets entering GRO might have different headrooms, even for a given
> flow (because of implementation details in drivers, like copybreak).
> We cant force drivers to deliver packets with a fixed headroom.
>
> 1) fix skb_segment()
>
> skb_segment() makes the false assumption headrooms of fragments are same
> than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> errors, and crash later in skb_copy_and_csum_dev()
>
> 2) allocate a minimal skb for head of frag_list
>
> skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
> allocate a fresh skb. This adds NET_SKB_PAD to a padding already
> provided by netdevice, depending on various things, like copybreak.
>
> Use alloc_skb() to allocate an exact padding, to reduce cache line
> needs:
> NET_SKB_PAD + NET_IP_ALIGN
>
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
>
> Many thanks to Plamen Petrov, testing many debugging patches !
> With help of Jarek Poplawski.
>
> Reported-by: Plamen Petrov<pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> CC: Jarek Poplawski<jarkao2@gmail.com>
> ---
> patch against linux-2.6 current tree
>
>   net/core/skbuff.c |    8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 3a2513f..26396ff 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2573,6 +2573,10 @@ struct sk_buff *skb_segment(struct sk_buff *skb, int features)
>   		__copy_skb_header(nskb, skb);
>   		nskb->mac_len = skb->mac_len;
>
> +		/* nskb and skb might have different headroom */
> +		if (nskb->ip_summed == CHECKSUM_PARTIAL)
> +			nskb->csum_start += skb_headroom(nskb) - headroom;
> +
>   		skb_reset_mac_header(nskb);
>   		skb_set_network_header(nskb, skb->mac_len);
>   		nskb->transport_header = (nskb->network_header +
> @@ -2702,8 +2706,8 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>   	} else if (skb_gro_len(p) != pinfo->gso_size)
>   		return -E2BIG;
>
> -	headroom = skb_headroom(p);
> -	nskb = netdev_alloc_skb(p->dev, headroom + skb_gro_offset(p));
> +	headroom = NET_SKB_PAD + NET_IP_ALIGN;
> +	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
>   	if (unlikely(!nskb))
>   		return -ENOMEM;
>
>
>

I confirm that the above patch applied on top of v2.6.36-rc3 does not
show the problems that all the kernels since v2.6.35 (both stable
and Linus' tree) had.

My problematic machine has been running the patched 36-rc3 for 36 hours, 
and couning, with "generic receive offload" enabled only my tg3 nic.

Thank you very much for the wonderful job, Eric!
Thanks to you, too, Jarek!

Plamen Petrov

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Jarek Poplawski]

On Fri, Sep 03, 2010 at 11:00:52AM +0300, Plamen Petrov wrote:
> ???? 01.9.2010 ??. 13:50, Eric Dumazet ????????????:
>
> I confirm that the above patch applied on top of v2.6.36-rc3 does not
> show the problems that all the kernels since v2.6.35 (both stable
> and Linus' tree) had.
>
> My problematic machine has been running the patched 36-rc3 for 36 hours,  
> and couning, with "generic receive offload" enabled only my tg3 nic.
>
> Thank you very much for the wonderful job, Eric!
> Thanks to you, too, Jarek!

Not at all! I only messed up a bit :-(

All credits to Eric and Plamen!

Thanks again,
Jarek P.

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Herbert Xu]

On Wed, Sep 01, 2010 at 12:50:51PM +0200, Eric Dumazet wrote:
> Plamen, could you test following patch ?
> 
> I reproduced problem on a dev machine and following patch cured it.
> 
> Thanks
> 
> [PATCH] gro: fix different skb headrooms
> 
> packets entering GRO might have different headrooms, even for a given
> flow (because of implementation details in drivers, like copybreak).
> We cant force drivers to deliver packets with a fixed headroom.
> 
> 1) fix skb_segment()
> 
> skb_segment() makes the false assumption headrooms of fragments are same
> than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> errors, and crash later in skb_copy_and_csum_dev()
> 
> 2) allocate a minimal skb for head of frag_list
> 
> skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
> allocate a fresh skb. This adds NET_SKB_PAD to a padding already
> provided by netdevice, depending on various things, like copybreak.
> 
> Use alloc_skb() to allocate an exact padding, to reduce cache line
> needs:
> NET_SKB_PAD + NET_IP_ALIGN
> 
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
> 
> Many thanks to Plamen Petrov, testing many debugging patches !
> With help of Jarek Poplawski.
> 
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jarek Poplawski <jarkao2@gmail.com>

Thanks for diagnosing and fixing this!

> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 3a2513f..26396ff 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2573,6 +2573,10 @@ struct sk_buff *skb_segment(struct sk_buff *skb, int features)
>  		__copy_skb_header(nskb, skb);
>  		nskb->mac_len = skb->mac_len;
>  
> +		/* nskb and skb might have different headroom */
> +		if (nskb->ip_summed == CHECKSUM_PARTIAL)
> +			nskb->csum_start += skb_headroom(nskb) - headroom;

This test is redundant since we require CHECKSUM_PARTIAL for
GSO packets.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Jarek Poplawski]

Eric Dumazet wrote, On 09/01/2010 12:50 PM:

> [PATCH] gro: fix different skb headrooms
> 
> packets entering GRO might have different headrooms, even for a given
> flow (because of implementation details in drivers, like copybreak).
> We cant force drivers to deliver packets with a fixed headroom.
> 
> 1) fix skb_segment()
> 
> skb_segment() makes the false assumption headrooms of fragments are same
> than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> errors, and crash later in skb_copy_and_csum_dev()
> 
> 2) allocate a minimal skb for head of frag_list
> 
> skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
> allocate a fresh skb. This adds NET_SKB_PAD to a padding already
> provided by netdevice, depending on various things, like copybreak.
> 
> Use alloc_skb() to allocate an exact padding, to reduce cache line
> needs:
> NET_SKB_PAD + NET_IP_ALIGN
> 
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
> 
> Many thanks to Plamen Petrov, testing many debugging patches !
> With help of Jarek Poplawski.
> 
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jarek Poplawski <jarkao2@gmail.com>
> ---
> patch against linux-2.6 current tree
> 
>  net/core/skbuff.c |    8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
...
> @@ -2702,8 +2706,8 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>  	} else if (skb_gro_len(p) != pinfo->gso_size)
>  		return -E2BIG;
>  
> -	headroom = skb_headroom(p);
> -	nskb = netdev_alloc_skb(p->dev, headroom + skb_gro_offset(p));
> +	headroom = NET_SKB_PAD + NET_IP_ALIGN;
> +	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
>  	if (unlikely(!nskb))
>  		return -ENOMEM;

Hi again,

Just had a second look, and unless I miss something...

Plamen, could you test this patch, too? (Without removing the previous
one.)

Thanks,
Jarek P.

------------------->

[PATCH] gro: Re-fix different skb headrooms

The patch: "gro: fix different skb headrooms" in its part:
"2) allocate a minimal skb for head of frag_list" is buggy. The copied
skb has p->data set at the ip header at the moment, and skb_gro_offset
is the length of ip + tcp headers. So, after the change the length of
mac header is skipped. Later skb_set_mac_header() sets it into the
NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
original skb was wrongly allocated, so let's copy it as it was.

bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57

Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
---

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 26396ff..c83b421 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2706,7 +2706,7 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
 	} else if (skb_gro_len(p) != pinfo->gso_size)
 		return -E2BIG;
 
-	headroom = NET_SKB_PAD + NET_IP_ALIGN;
+	headroom = skb_headroom(p);
 	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
 	if (unlikely(!nskb))
 		return -ENOMEM;

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Eric Dumazet]

Le samedi 04 septembre 2010 à 22:34 +0200, Jarek Poplawski a écrit :

> Hi again,
> 
> Just had a second look, and unless I miss something...
> 
> Plamen, could you test this patch, too? (Without removing the previous
> one.)
> 
> Thanks,
> Jarek P.
> 
> ------------------->
> 
> [PATCH] gro: Re-fix different skb headrooms
> 
> The patch: "gro: fix different skb headrooms" in its part:
> "2) allocate a minimal skb for head of frag_list" is buggy. The copied
> skb has p->data set at the ip header at the moment, and skb_gro_offset
> is the length of ip + tcp headers. So, after the change the length of
> mac header is skipped. Later skb_set_mac_header() sets it into the
> NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
> NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
> original skb was wrongly allocated, so let's copy it as it was.
> 
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
> fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57
> 
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 26396ff..c83b421 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2706,7 +2706,7 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>  	} else if (skb_gro_len(p) != pinfo->gso_size)
>  		return -E2BIG;
>  
> -	headroom = NET_SKB_PAD + NET_IP_ALIGN;
> +	headroom = skb_headroom(p);
>  	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
>  	if (unlikely(!nskb))
>  		return -ENOMEM;

You are right, thanks for reviewing this patch again :)

By the way, NET_IP_ALIGN is now 0 on x86, so technically speaking, your
patch un-aligns IP header on x86, but thats OK, since other arches might
want it being aligned, while x86 doesnt care.

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Plamen Petrov]

На 05.9.2010 г. 10:49, Eric Dumazet написа:
> Le samedi 04 septembre 2010 à 22:34 +0200, Jarek Poplawski a écrit :
>
>> Hi again,
>>
>> Just had a second look, and unless I miss something...
>>
>> Plamen, could you test this patch, too? (Without removing the previous
>> one.)
>>
>> Thanks,
>> Jarek P.
>>
>> ------------------->
>>
>> [PATCH] gro: Re-fix different skb headrooms
>>
>> The patch: "gro: fix different skb headrooms" in its part:
>> "2) allocate a minimal skb for head of frag_list" is buggy. The copied
>> skb has p->data set at the ip header at the moment, and skb_gro_offset
>> is the length of ip + tcp headers. So, after the change the length of
>> mac header is skipped. Later skb_set_mac_header() sets it into the
>> NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
>> NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
>> original skb was wrongly allocated, so let's copy it as it was.
>>
>> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
>> fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57
>>
>> Reported-by: Plamen Petrov<pvp-lsts@fs.uni-ruse.bg>
>> Signed-off-by: Jarek Poplawski<jarkao2@gmail.com>
>> CC: Eric Dumazet<eric.dumazet@gmail.com>
>> ---
>>
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index 26396ff..c83b421 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -2706,7 +2706,7 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>>   	} else if (skb_gro_len(p) != pinfo->gso_size)
>>   		return -E2BIG;
>>
>> -	headroom = NET_SKB_PAD + NET_IP_ALIGN;
>> +	headroom = skb_headroom(p);
>>   	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
>>   	if (unlikely(!nskb))
>>   		return -ENOMEM;
>
> You are right, thanks for reviewing this patch again :)
>
> By the way, NET_IP_ALIGN is now 0 on x86, so technically speaking, your
> patch un-aligns IP header on x86, but thats OK, since other arches might
> want it being aligned, while x86 doesnt care.
>
> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>
>
>

Well, now that I'm back at work, I'm glad to report
that I tested both variants of the patch, and as Eric
points out - it works both ways.

So, which ever fits you guys better.

Thanks a lot!

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Jarek Poplawski]

On Wed, Sep 08, 2010 at 07:57:31AM +0300, Plamen Petrov wrote:
> ???? 05.9.2010 ??. 10:49, Eric Dumazet ????????????:
>> Le samedi 04 septembre 2010 ?? 22:34 +0200, Jarek Poplawski a écrit :
>>
>>> Hi again,
>>>
>>> Just had a second look, and unless I miss something...
>>>
>>> Plamen, could you test this patch, too? (Without removing the previous
>>> one.)
>>>
>>> Thanks,
>>> Jarek P.
>>>
>>> ------------------->
>>>
>>> [PATCH] gro: Re-fix different skb headrooms
>>>
>>> The patch: "gro: fix different skb headrooms" in its part:
>>> "2) allocate a minimal skb for head of frag_list" is buggy. The copied
>>> skb has p->data set at the ip header at the moment, and skb_gro_offset
>>> is the length of ip + tcp headers. So, after the change the length of
>>> mac header is skipped. Later skb_set_mac_header() sets it into the
>>> NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
>>> NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
>>> original skb was wrongly allocated, so let's copy it as it was.
>>>
>>> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
>>> fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57
>>>
>>> Reported-by: Plamen Petrov<pvp-lsts@fs.uni-ruse.bg>
>>> Signed-off-by: Jarek Poplawski<jarkao2@gmail.com>
>>> CC: Eric Dumazet<eric.dumazet@gmail.com>
>>> ---
>>>
>>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>>> index 26396ff..c83b421 100644
>>> --- a/net/core/skbuff.c
>>> +++ b/net/core/skbuff.c
>>> @@ -2706,7 +2706,7 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>>>   	} else if (skb_gro_len(p) != pinfo->gso_size)
>>>   		return -E2BIG;
>>>
>>> -	headroom = NET_SKB_PAD + NET_IP_ALIGN;
>>> +	headroom = skb_headroom(p);
>>>   	nskb = alloc_skb(headroom + skb_gro_offset(p), GFP_ATOMIC);
>>>   	if (unlikely(!nskb))
>>>   		return -ENOMEM;
>>
>> You are right, thanks for reviewing this patch again :)
>>
>> By the way, NET_IP_ALIGN is now 0 on x86, so technically speaking, your
>> patch un-aligns IP header on x86, but thats OK, since other arches might
>> want it being aligned, while x86 doesnt care.
>>
>> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>>
>>
>>
>
> Well, now that I'm back at work, I'm glad to report
> that I tested both variants of the patch, and as Eric
> points out - it works both ways.
>
> So, which ever fits you guys better.

We need both of them. I hope David could add this too:

Tested-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>

Thanks a lot everybody!
Jarek P.

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[David Miller]

From: Jarek Poplawski <jarkao2@gmail.com>
Date: Wed, 8 Sep 2010 06:20:04 +0000

> We need both of them. I hope David could add this too:
> 
> Tested-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>

Done, and applied, thanks :-)

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Rafael J. Wysocki]

On Wednesday, September 08, 2010, David Miller wrote:
> From: Jarek Poplawski <jarkao2@gmail.com>
> Date: Wed, 8 Sep 2010 06:20:04 +0000
> 
> > We need both of them. I hope David could add this too:
> > 
> > Tested-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> 
> Done, and applied, thanks :-)

Please kindly let me know when Linus gets them, so that I can close the bug.

Rafael

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Plamen Petrov]

На 08.9.2010 г. 23:21, Rafael J. Wysocki написа:
> On Wednesday, September 08, 2010, David Miller wrote:
>> From: Jarek Poplawski<jarkao2@gmail.com>
>> Date: Wed, 8 Sep 2010 06:20:04 +0000
>>
>>> We need both of them. I hope David could add this too:
>>>
>>> Tested-by: Plamen Petrov<pvp-lsts@fs.uni-ruse.bg>
>>
>> Done, and applied, thanks :-)
>
> Please kindly let me know when Linus gets them, so that I can close the bug.
>
> Rafael

Now that both commits that fix my problems are in Linus' tree, the
bug can be closed, but these fixes should go in 2.6.35.y, too.
So, CCing -stable.

Fix 1:
> commit	3d3be4333fdf6faa080947b331a6a19bce1a4f57
>
> gro: fix different skb headrooms
>
> Packets entering GRO might have different headrooms, even for a given
> flow (because of implementation details in drivers, like copybreak).
> We cant force drivers to deliver packets with a fixed headroom.
>
> 1) fix skb_segment()
>
> skb_segment() makes the false assumption headrooms of fragments are same
> than the head. When CHECKSUM_PARTIAL is used, this can give csum_start
> errors, and crash later in skb_copy_and_csum_dev()
>
> 2) allocate a minimal skb for head of frag_list
>
> skb_gro_receive() uses netdev_alloc_skb(headroom + skb_gro_offset(p)) to
> allocate a fresh skb. This adds NET_SKB_PAD to a padding already
> provided by netdevice, depending on various things, like copybreak.
>
> Use alloc_skb() to allocate an exact padding, to reduce cache line
> needs:
> NET_SKB_PAD + NET_IP_ALIGN
>
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
>
> Many thanks to Plamen Petrov, testing many debugging patches !
> With help of Jarek Poplawski.
>
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jarek Poplawski <jarkao2@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Fix 2:
> commit	64289c8e6851bca0e589e064c9a5c9fbd6ae5dd4
>
> gro: Re-fix different skb headrooms
>
> The patch: "gro: fix different skb headrooms" in its part:
> "2) allocate a minimal skb for head of frag_list" is buggy. The copied
> skb has p->data set at the ip header at the moment, and skb_gro_offset
> is the length of ip + tcp headers. So, after the change the length of
> mac header is skipped. Later skb_set_mac_header() sets it into the
> NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
> NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
> original skb was wrongly allocated, so let's copy it as it was.
>
> bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
> fixes commit: 3d3be4333fdf6faa080947b331a6a19bce1a4f57
>
> Reported-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> CC: Eric Dumazet <eric.dumazet@gmail.com>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
> Signed-off-by: David S. Miller <davem@davemloft.net>

Thanks,
Plamen

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[David Miller]

From: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
Date: Sun, 12 Sep 2010 09:55:19 +0300

> Now that both commits that fix my problems are in Linus' tree, the
> bug can be closed, but these fixes should go in 2.6.35.y, too.
> So, CCing -stable.

You don't need to do this, I will submit whatever is appropriate for
networking to -stable as needed.

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Plamen Petrov]

На 12.9.2010 г. 18:55, David Miller написа:
> From: Plamen Petrov<pvp-lsts@fs.uni-ruse.bg>
> Date: Sun, 12 Sep 2010 09:55:19 +0300
>
>> Now that both commits that fix my problems are in Linus' tree, the
>> bug can be closed, but these fixes should go in 2.6.35.y, too.
>> So, CCing -stable.
>
> You don't need to do this, I will submit whatever is appropriate for
> networking to -stable as needed.

Sorry! I didn't know it will be taken care of.

Thanks!
Plamen

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Rafael J. Wysocki]

On Sunday, September 12, 2010, Plamen Petrov wrote:
> На 08.9.2010 г. 23:21, Rafael J. Wysocki написа:
> > On Wednesday, September 08, 2010, David Miller wrote:
> >> From: Jarek Poplawski<jarkao2@gmail.com>
> >> Date: Wed, 8 Sep 2010 06:20:04 +0000
> >>
> >>> We need both of them. I hope David could add this too:
> >>>
> >>> Tested-by: Plamen Petrov<pvp-lsts@fs.uni-ruse.bg>
> >>
> >> Done, and applied, thanks :-)
> >
> > Please kindly let me know when Linus gets them, so that I can close the bug.
> >
> > Rafael
> 
> Now that both commits that fix my problems are in Linus' tree, the
> bug can be closed, but these fixes should go in 2.6.35.y, too.
> So, CCing -stable.

Thanks, bug closed.

Rafael

Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev

[Mitchell Erblich]

						OLD REPLY … and Correcting . Suggesting of Corrections of LONG TERM embedded problems 

Summary:

		Due to watermark awareness differences that is problematic in embedded systems, the GFP_ATOMIC which is not memory watermark aware is used in interrupt / atomic context.

		To properly monitor WATERMARK levels at suggested kernel locations, the “PROPER” GFP_FLAG SHOULD be GFP_NOWAIT. This is atomic/interupt friendly and is aware of memory watermarks, thus if memory is below the specified watermark level, it will then return a ENOMEM from that location.

					GFP_ATOMIC will not return ENOMEM and by the time the watermarks drop, ALL GFP_KERNEL callers are now SLEEPING.

					Please be embedded friendly with code patches…

		FYI: Embedded system due to no 2ndary drive can not clean PTEs (page frames), thus callers need to be aware of low memory issues and be able to reduce their memory consumption based on receiving ENOMEMs. GFP_KERNEL callers will just sleep until memory is back above the watermarks.

Mitchell Erblich
erblichs@earthlink.net



> On Aug 31, 2010, at 12:26 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:
> 
> On Tue, Aug 31, 2010 at 08:58:10AM +0300, Plamen Petrov wrote:
>> Rafael J. Wysocki ????????????:
>> 
>>> This message has been generated automatically as a part of a summary report
>>> of recent regressions.
>>> 
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.35.  Please verify if it still should be listed and let the tracking team
>>> know (either way).
>>> 
>>> 
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16626
>>> Subject		: Machine hangs with EIP at skb_copy_and_csum_dev
>>> Submitter	: Plamen Petrov <pvp-lsts@fs.uni-ruse.bg>
>>> Date		: 2010-08-19 09:57 (11 days old)
>>> Handled-By	:  Eric Dumazet <eric.dumazet@gmail.com>
>>> 
>>> 
>> 
>> Should "generic receive offload" work on a forwarding setup?
>> If yes - then the bug should remain open.
>> If not - then it's my mistake.
> 
> If/since it's on by default it should work and it definitely can't be
> your mistake. (Unless we can't find the real reason... ;-)
> 
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug #16629] fix BUG: using smp_processor_id() in preemptible code (resend)

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16629
Subject		: fix BUG: using smp_processor_id() in preemptible code (resend)
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-18 9:11 (12 days old)
Message-ID	: <20100818091157.GA5238@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128212276618793&w=2
Handled-By	: H. Peter Anvin <hpa@zytor.com>
Patch		: http://marc.info/?l=linux-kernel&m=128212276618793&w=2

[Bug #16951] hackbench regression with 2.6.36-rc1

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject		: hackbench regression with 2.6.36-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2010-08-18 6:18 (12 days old)
Message-ID	: <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References	: http://marc.info/?l=linux-kernel&m=128211235904910&w=2

[Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16881
Subject		: [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.
Submitter	:  <trapdoor6@gmail.com>
Date		: 2010-08-24 12:20 (6 days old)

Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.

[trapDoor]

On Sun, Aug 29, 2010 at 11:36 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a summary report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.35.  Please verify if it still should be listed and let the tracking team
> know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16881
> Subject         : [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.
> Submitter       :  <trapdoor6@gmail.com>
> Date            : 2010-08-24 12:20 (6 days old)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

There was at least one drm pull between 2.6.36-rc2 and -rc3. So I
tested on -rc3 and I confirm that the issue is still present.

I was going to update the bugzilla entry but it won't let me log in at
this moment.

-- 
Regards
Tomasz

Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.

[Florian Mickler]

On Mon, 30 Aug 2010 10:54:41 +0100
trapDoor <trapdoor6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Sun, Aug 29, 2010 at 11:36 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.35.  Please verify if it still should be listed and let the tracking team
> > know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16881
> > Subject         : [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.
> > Submitter       :  <trapdoor6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date            : 2010-08-24 12:20 (6 days old)
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> 
> There was at least one drm pull between 2.6.36-rc2 and -rc3. So I
> tested on -rc3 and I confirm that the issue is still present.
> 
> I was going to update the bugzilla entry but it won't let me log in at
> this moment.
> 

It seems to work now again. I've updated the entry for you. 

Thx,
Flo

Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.

[trapDoor]

On Mon, Aug 30, 2010 at 2:39 PM, Florian Mickler <florian@mickler.org> wrote:
>
>
> On Mon, 30 Aug 2010 10:54:41 +0100
> trapDoor <trapdoor6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Sun, Aug 29, 2010 at 11:36 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> > This message has been generated automatically as a part of a summary report
>> > of recent regressions.
>> >
>> > The following bug entry is on the current list of known regressions
>> > from 2.6.35.  Please verify if it still should be listed and let the tracking team
>> > know (either way).
>> >
>> >
>> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16881
>> > Subject         : [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D.
>> > Submitter       :  <trapdoor6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> > Date            : 2010-08-24 12:20 (6 days old)
>> >
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at  http://www.tux.org/lkml/
>> >
>>
>> There was at least one drm pull between 2.6.36-rc2 and -rc3. So I
>> tested on -rc3 and I confirm that the issue is still present.
>>
>> I was going to update the bugzilla entry but it won't let me log in at
>> this moment.
>>
>
> It seems to work now again. I've updated the entry for you.
>
> Thx,
> Flo
>
>

Thanks Florian.

--
Tomasz

[Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject		: qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter	: Meelis Roos <mroos@linux.ee>
Date		: 2010-08-19 21:03 (11 days old)
Message-ID	: <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
References	: http://marc.info/?l=linux-kernel&m=128225184900892&w=2

Re: [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq

[Meelis Roos]

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16971
> Subject		: qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
> Submitter	: Meelis Roos <mroos@linux.ee>
> Date		: 2010-08-19 21:03 (11 days old)
> Message-ID	: <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
> References	: http://marc.info/?l=linux-kernel&m=128225184900892&w=2

Still present in 2.6.36-rc3.

-- 
Meelis Roos (mroos@linux.ee)

Re: [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq

[Florian Mickler]

On Mon, 30 Aug 2010 11:45:56 +0300 (EEST)
Meelis Roos <mroos@linux.ee> wrote:

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16971
> > Subject		: qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
> > Submitter	: Meelis Roos <mroos@linux.ee>
> > Date		: 2010-08-19 21:03 (11 days old)
> > Message-ID	: <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
> > References	: http://marc.info/?l=linux-kernel&m=128225184900892&w=2
> 
> Still present in 2.6.36-rc3.
> 

Thx for the update. 

I've updated the bugzilla entry accordingly.

Cheers,
Flo

[Bug #17021] [REGRESSION] [2.6.36-rc1] [DRM INTEL] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28.

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17021
Subject		: [REGRESSION] [2.6.36-rc1] [DRM INTEL] [drm:intel_calculate_wm] *ERROR* Insufficient FIFO for plane, expect flickering: entries required = 36, available = 28.
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2010-08-18 18:46 (12 days old)
Message-ID	: <201008182046.37732.maciej.rutecki@gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128215721507666&w=2

[Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16961
Subject		: kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-19 9:54 (11 days old)
Message-ID	: <20100819095429.GA5201@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
Handled-By	: Avi Kivity <avi@redhat.com>

Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978

[Sergey Senozhatsky]

[-- Attachment #1: Type: text/plain, Size: 16503 bytes --]

On (08/30/10 00:36), Rafael J. Wysocki wrote:
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16961
> Subject		: kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978
> Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Date		: 2010-08-19 9:54 (11 days old)
> Message-ID	: <20100819095429.GA5201@swordfish.minsk.epam.com>
> References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
> Handled-By	: Avi Kivity <avi@redhat.com>
> 

Hello,
.36-rc3

[ 2913.218767] kvm: disabling virtualization on CPU1
[ 2913.219078] CPU 1 is now offline
[ 2913.221758] lockdep: fixing up alternatives.
[ 2913.221814] Booting Node 0 Processor 1 APIC 0x1
[ 2913.363980] ------------[ cut here ]------------
[ 2913.364042] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978!
[ 2913.364107] invalid opcode: 0000 [#1] PREEMPT SMP 
[ 2913.364173] last sysfs file: /sys/devices/system/cpu/cpu1/online
[ 2913.364262] CPU 1 
[ 2913.364285] Modules linked in: kvm_intel kvm ipv6 ac battery snd_seq_dummy snd_seq_oss snd_seq_midi_event wmi snd_seq snd_seq_device snd_hda_codec_atihdmi button snd_hda_codec_realtek psmouse serio_raw snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm_oss snd_pcm broadcom snd_timer usbhid hid tg3 libphy snd_page_alloc evdev snd_mixer_oss snd soundcore ehci_hcd sr_mod usbcore cdrom sd_mod ahci libahci
[ 2913.364784] 
[ 2913.364805] Pid: 5912, comm: qemu-kvm Not tainted 2.6.36-rc3-dbg-00144-gb958348-dirty #144 Aspire 5741G    /Aspire 5741G    
[ 2913.364965] RIP: 0010:[<ffffffffa0223446>]  [<ffffffffa0223446>] kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.365073] RSP: 0000:ffff880150b87b18  EFLAGS: 00010246
[ 2913.365128] RAX: ffff880150b87b40 RBX: ffff8801534fc000 RCX: ffff880154e75000
[ 2913.365225] RDX: ffff880002640000 RSI: ffff880154e4e638 RDI: ffff880154e75000
[ 2913.365292] RBP: ffff880150b87b18 R08: 0000000000000001 R09: 000000000000039c
[ 2913.365357] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
[ 2913.365422] R13: ffff880154e75000 R14: ffff880154e4df10 R15: 0000000000000000
[ 2913.365489] FS:  00007f23062c6710(0000) GS:ffff880002640000(0000) knlGS:0000000000000000
[ 2913.365563] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
[ 2913.365617] CR2: 0000000000000000 CR3: 000000015544d000 CR4: 00000000000006e0
[ 2913.365682] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2913.365747] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2913.365813] Process qemu-kvm (pid: 5912, threadinfo ffff880150b86000, task ffff880154e4df10)
[ 2913.365929] Stack:
[ 2913.365953]  ffff880150b87b68 ffffffffa02660a2 ffff880150b87b58 ffffffff81063240
[ 2913.366034] <0> ffff880154e4df10 0000000154e75000 ffff880157d55f10 ffff8801534fc000
[ 2913.366132] <0> 0000000000000001 0000000000014200 ffff880150b87b98 ffffffffa022c4cc
[ 2913.366255] Call Trace:
[ 2913.366288]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
[ 2913.366355]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.366422]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.366490]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.366547]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.366604]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.366663]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.366715]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.366781]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
[ 2913.366876]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
[ 2913.366956]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
[ 2913.367029]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
[ 2913.367104]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
[ 2913.367210]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
[ 2913.367276]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
[ 2913.367341]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
[ 2913.367401]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
[ 2913.367458]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
[ 2913.367515]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
[ 2913.367568]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
[ 2913.369987]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
[ 2913.372394]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
[ 2913.374739] Code: 2f 02 00 85 c0 75 13 ba 01 00 00 00 31 f6 48 c7 c7 bb 37 22 a0 e8 76 ce e1 e0 c9 c3 55 80 3d 79 2f 02 00 00 48 89 e5 74 02 eb fe <0f> 0b 55 48 89 e5 53 48 89 f3 48 83 ec 08 48 8b 87 98 00 00 00 
[ 2913.380357] RIP  [<ffffffffa0223446>] kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.383084]  RSP <ffff880150b87b18>
[ 2913.397343] ---[ end trace 9564e615f538c7b1 ]---
[ 2913.399336] kvm: enabling virtualization on CPU1
[ 2913.402446] note: qemu-kvm[5912] exited with preempt_count 1
[ 2913.404860] NMI watchdog enabled, takes one hw-pmu counter.
[ 2913.404918] vmwrite error: reg 6c0a value ffff880002650dc0 (err 40177088)
[ 2913.404924] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
[ 2913.404928] Call Trace:
[ 2913.404937]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
[ 2913.404944]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
[ 2913.404951]  [<ffffffffa0266147>] vmx_vcpu_load+0x135/0x1a0 [kvm_intel]
[ 2913.404958]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.404974]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.404985]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.404990]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.404995]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.405002]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.405010]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
[ 2913.405016]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
[ 2913.405022]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
[ 2913.405028]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
[ 2913.405034]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
[ 2913.405039]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
[ 2913.405046]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
[ 2913.405053]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
[ 2913.405060]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
[ 2913.405066]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
[ 2913.405071]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
[ 2913.405079]  [<ffffffff810060b6>] oops_end+0x97/0x9c
[ 2913.405084]  [<ffffffff810061f8>] die+0x55/0x5e
[ 2913.405089]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
[ 2913.405094]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
[ 2913.405102]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
[ 2913.405119]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.405130]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 2913.405139]  [<ffffffff81404544>] ? irq_return+0x0/0xc
[ 2913.405149]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
[ 2913.405166]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.405181]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
[ 2913.405189]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.405204]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.405215]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.405221]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.405227]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.405234]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.405240]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.405255]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
[ 2913.405269]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
[ 2913.405276]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
[ 2913.405292]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
[ 2913.405306]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
[ 2913.405313]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
[ 2913.405321]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
[ 2913.405334]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
[ 2913.405341]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
[ 2913.405348]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
[ 2913.405354]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
[ 2913.405360]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
[ 2913.405366]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
[ 2913.405373]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
[ 2913.405378] vmwrite error: reg 6c0c value ffff880002644000 (err 40124416)
[ 2913.405384] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
[ 2913.405388] Call Trace:
[ 2913.405395]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
[ 2913.405402]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
[ 2913.405410]  [<ffffffffa0266159>] vmx_vcpu_load+0x147/0x1a0 [kvm_intel]
[ 2913.405417]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.405432]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.405444]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.405450]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.405455]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.405461]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.405469]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
[ 2913.405475]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
[ 2913.405482]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
[ 2913.405489]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
[ 2913.405495]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
[ 2913.405501]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
[ 2913.405508]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
[ 2913.405515]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
[ 2913.405522]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
[ 2913.405528]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
[ 2913.405534]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
[ 2913.405540]  [<ffffffff810060b6>] oops_end+0x97/0x9c
[ 2913.405545]  [<ffffffff810061f8>] die+0x55/0x5e
[ 2913.405550]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
[ 2913.405556]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
[ 2913.405561]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
[ 2913.405572]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.405580]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 2913.405586]  [<ffffffff81404544>] ? irq_return+0x0/0xc
[ 2913.405592]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
[ 2913.405603]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.405612]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
[ 2913.405618]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.405634]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.405645]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.405651]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.405657]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.405664]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.405670]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.405686]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
[ 2913.405699]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
[ 2913.405706]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
[ 2913.405721]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
[ 2913.405736]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
[ 2913.405743]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
[ 2913.405750]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
[ 2913.405764]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
[ 2913.405773]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
[ 2913.405784]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
[ 2913.405793]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
[ 2913.405802]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
[ 2913.405810]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
[ 2913.405819]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
[ 2913.405828] vmwrite error: reg 6c10 value 0 (err 0)
[ 2913.405834] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
[ 2913.405839] Call Trace:
[ 2913.405849]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
[ 2913.405861]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
[ 2913.405873]  [<ffffffffa0266176>] vmx_vcpu_load+0x164/0x1a0 [kvm_intel]
[ 2913.405895]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.405907]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.405915]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.405921]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.405927]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.405934]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
[ 2913.405941]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
[ 2913.405948]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
[ 2913.405955]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
[ 2913.405961]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
[ 2913.405967]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
[ 2913.405973]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
[ 2913.405980]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
[ 2913.405986]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
[ 2913.405992]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
[ 2913.405998]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
[ 2913.406004]  [<ffffffff810060b6>] oops_end+0x97/0x9c
[ 2913.406009]  [<ffffffff810061f8>] die+0x55/0x5e
[ 2913.406014]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
[ 2913.406019]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
[ 2913.406026]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
[ 2913.406036]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.406043]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 2913.406050]  [<ffffffff81404544>] ? irq_return+0x0/0xc
[ 2913.406058]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
[ 2913.406076]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
[ 2913.406089]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
[ 2913.406098]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.406121]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
[ 2913.406136]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
[ 2913.406142]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
[ 2913.406147]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
[ 2913.406153]  [<ffffffff81401149>] schedule+0x81d/0x8f2
[ 2913.406158]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
[ 2913.406173]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
[ 2913.406186]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
[ 2913.406191]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
[ 2913.406206]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
[ 2913.406220]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
[ 2913.406226]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
[ 2913.406233]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
[ 2913.406245]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
[ 2913.406250]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
[ 2913.406257]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
[ 2913.406262]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
[ 2913.406267]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
[ 2913.406273]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
[ 2913.406279]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
[ 2913.749804] kvm: disabling virtualization on CPU2
[ 2913.749831] CPU 2 is now offline
[ 2913.751880] lockdep: fixing up alternatives.
[ 2913.753457] Booting Node 0 Processor 2 APIC 0x4
[ 2913.918676] kvm: enabling virtualization on CPU2
[ 2913.920349] NMI watchdog enabled, takes one hw-pmu counter.
[ 2913.922404] coretemp coretemp.2: TjMax is 105 C.
[ 2913.952819] kvm: disabling virtualization on CPU1
[ 2913.953052] CPU 1 is now offline



	Sergey

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978

[Florian Mickler]

On Mon, 30 Aug 2010 11:55:39 +0300
Sergey Senozhatsky
<sergey.senozhatsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On (08/30/10 00:36), Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16961
> > Subject		: kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978
> > Submitter	: Sergey Senozhatsky <sergey.senozhatsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2010-08-19 9:54 (11 days old)
> > Message-ID	: <20100819095429.GA5201-dY8u8AhHFaWtd10JCjopabkcH5ONE+aC@public.gmane.org>
> > References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
> > Handled-By	: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > 
> 
> Hello,
> .36-rc3
> 
> [ 2913.218767] kvm: disabling virtualization on CPU1
> [ 2913.219078] CPU 1 is now offline
> [ 2913.221758] lockdep: fixing up alternatives.
> [ 2913.221814] Booting Node 0 Processor 1 APIC 0x1
> [ 2913.363980] ------------[ cut here ]------------
> [ 2913.364042] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978!
> [ 2913.364107] invalid opcode: 0000 [#1] PREEMPT SMP 
> [ 2913.364173] last sysfs file: /sys/devices/system/cpu/cpu1/online
> [ 2913.364262] CPU 1 
> [ 2913.364285] Modules linked in: kvm_intel kvm ipv6 ac battery snd_seq_dummy snd_seq_oss snd_seq_midi_event wmi snd_seq snd_seq_device snd_hda_codec_atihdmi button snd_hda_codec_realtek psmouse serio_raw snd_hda_intel snd_hda_codec
> snd_hwdep snd_pcm_oss snd_pcm broadcom snd_timer usbhid hid tg3 libphy snd_page_alloc evdev snd_mixer_oss snd soundcore ehci_hcd sr_mod usbcore cdrom sd_mod ahci libahci
> [ 2913.364784] 
> [ 2913.364805] Pid: 5912, comm: qemu-kvm Not tainted 2.6.36-rc3-dbg-00144-gb958348-dirty #144 Aspire 5741G    /Aspire 5741G    
> [ 2913.364965] RIP: 0010:[<ffffffffa0223446>]  [<ffffffffa0223446>] kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.365073] RSP: 0000:ffff880150b87b18  EFLAGS: 00010246
> [ 2913.365128] RAX: ffff880150b87b40 RBX: ffff8801534fc000 RCX: ffff880154e75000
> [ 2913.365225] RDX: ffff880002640000 RSI: ffff880154e4e638 RDI: ffff880154e75000
> [ 2913.365292] RBP: ffff880150b87b18 R08: 0000000000000001 R09: 000000000000039c
> [ 2913.365357] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
> [ 2913.365422] R13: ffff880154e75000 R14: ffff880154e4df10 R15: 0000000000000000
> [ 2913.365489] FS:  00007f23062c6710(0000) GS:ffff880002640000(0000) knlGS:0000000000000000
> [ 2913.365563] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> [ 2913.365617] CR2: 0000000000000000 CR3: 000000015544d000 CR4: 00000000000006e0
> [ 2913.365682] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 2913.365747] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 2913.365813] Process qemu-kvm (pid: 5912, threadinfo ffff880150b86000, task ffff880154e4df10)
> [ 2913.365929] Stack:
> [ 2913.365953]  ffff880150b87b68 ffffffffa02660a2 ffff880150b87b58 ffffffff81063240
> [ 2913.366034] <0> ffff880154e4df10 0000000154e75000 ffff880157d55f10 ffff8801534fc000
> [ 2913.366132] <0> 0000000000000001 0000000000014200 ffff880150b87b98 ffffffffa022c4cc
> [ 2913.366255] Call Trace:
> [ 2913.366288]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.366355]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.366422]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.366490]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.366547]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.366604]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.366663]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.366715]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.366781]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.366876]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.366956]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.367029]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.367104]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.367210]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.367276]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.367341]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.367401]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.367458]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.367515]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.367568]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.369987]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.372394]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.374739] Code: 2f 02 00 85 c0 75 13 ba 01 00 00 00 31 f6 48 c7 c7 bb 37 22 a0 e8 76 ce e1 e0 c9 c3 55 80 3d 79 2f 02 00 00 48 89 e5 74 02 eb fe <0f> 0b 55 48 89 e5 53 48 89 f3 48 83 ec 08 48 8b 87 98 00 00 00 
> [ 2913.380357] RIP  [<ffffffffa0223446>] kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.383084]  RSP <ffff880150b87b18>
> [ 2913.397343] ---[ end trace 9564e615f538c7b1 ]---
> [ 2913.399336] kvm: enabling virtualization on CPU1
> [ 2913.402446] note: qemu-kvm[5912] exited with preempt_count 1
> [ 2913.404860] NMI watchdog enabled, takes one hw-pmu counter.
> [ 2913.404918] vmwrite error: reg 6c0a value ffff880002650dc0 (err 40177088)
> [ 2913.404924] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
> [ 2913.404928] Call Trace:
> [ 2913.404937]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
> [ 2913.404944]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
> [ 2913.404951]  [<ffffffffa0266147>] vmx_vcpu_load+0x135/0x1a0 [kvm_intel]
> [ 2913.404958]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.404974]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.404985]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.404990]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.404995]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405002]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405010]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
> [ 2913.405016]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
> [ 2913.405022]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
> [ 2913.405028]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
> [ 2913.405034]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
> [ 2913.405039]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
> [ 2913.405046]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
> [ 2913.405053]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
> [ 2913.405060]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
> [ 2913.405066]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
> [ 2913.405071]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
> [ 2913.405079]  [<ffffffff810060b6>] oops_end+0x97/0x9c
> [ 2913.405084]  [<ffffffff810061f8>] die+0x55/0x5e
> [ 2913.405089]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
> [ 2913.405094]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
> [ 2913.405102]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
> [ 2913.405119]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405130]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 2913.405139]  [<ffffffff81404544>] ? irq_return+0x0/0xc
> [ 2913.405149]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
> [ 2913.405166]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405181]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.405189]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405204]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405215]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405221]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405227]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405234]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405240]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405255]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.405269]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.405276]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.405292]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.405306]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.405313]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.405321]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.405334]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.405341]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.405348]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.405354]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.405360]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.405366]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.405373]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.405378] vmwrite error: reg 6c0c value ffff880002644000 (err 40124416)
> [ 2913.405384] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
> [ 2913.405388] Call Trace:
> [ 2913.405395]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
> [ 2913.405402]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
> [ 2913.405410]  [<ffffffffa0266159>] vmx_vcpu_load+0x147/0x1a0 [kvm_intel]
> [ 2913.405417]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405432]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405444]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405450]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405455]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405461]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405469]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
> [ 2913.405475]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
> [ 2913.405482]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
> [ 2913.405489]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
> [ 2913.405495]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
> [ 2913.405501]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
> [ 2913.405508]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
> [ 2913.405515]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
> [ 2913.405522]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
> [ 2913.405528]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
> [ 2913.405534]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
> [ 2913.405540]  [<ffffffff810060b6>] oops_end+0x97/0x9c
> [ 2913.405545]  [<ffffffff810061f8>] die+0x55/0x5e
> [ 2913.405550]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
> [ 2913.405556]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
> [ 2913.405561]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
> [ 2913.405572]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405580]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 2913.405586]  [<ffffffff81404544>] ? irq_return+0x0/0xc
> [ 2913.405592]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
> [ 2913.405603]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405612]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.405618]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405634]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405645]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405651]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405657]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405664]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405670]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405686]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.405699]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.405706]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.405721]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.405736]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.405743]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.405750]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.405764]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.405773]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.405784]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.405793]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.405802]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.405810]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.405819]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.405828] vmwrite error: reg 6c10 value 0 (err 0)
> [ 2913.405834] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
> [ 2913.405839] Call Trace:
> [ 2913.405849]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
> [ 2913.405861]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
> [ 2913.405873]  [<ffffffffa0266176>] vmx_vcpu_load+0x164/0x1a0 [kvm_intel]
> [ 2913.405895]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405907]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405915]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405921]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405927]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405934]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
> [ 2913.405941]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
> [ 2913.405948]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
> [ 2913.405955]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
> [ 2913.405961]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
> [ 2913.405967]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
> [ 2913.405973]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
> [ 2913.405980]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
> [ 2913.405986]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
> [ 2913.405992]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
> [ 2913.405998]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
> [ 2913.406004]  [<ffffffff810060b6>] oops_end+0x97/0x9c
> [ 2913.406009]  [<ffffffff810061f8>] die+0x55/0x5e
> [ 2913.406014]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
> [ 2913.406019]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
> [ 2913.406026]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
> [ 2913.406036]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.406043]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 2913.406050]  [<ffffffff81404544>] ? irq_return+0x0/0xc
> [ 2913.406058]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
> [ 2913.406076]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.406089]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.406098]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.406121]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.406136]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.406142]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.406147]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.406153]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.406158]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.406173]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.406186]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.406191]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.406206]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.406220]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.406226]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.406233]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.406245]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.406250]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.406257]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.406262]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.406267]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.406273]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.406279]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.749804] kvm: disabling virtualization on CPU2
> [ 2913.749831] CPU 2 is now offline
> [ 2913.751880] lockdep: fixing up alternatives.
> [ 2913.753457] Booting Node 0 Processor 2 APIC 0x4
> [ 2913.918676] kvm: enabling virtualization on CPU2
> [ 2913.920349] NMI watchdog enabled, takes one hw-pmu counter.
> [ 2913.922404] coretemp coretemp.2: TjMax is 105 C.
> [ 2913.952819] kvm: disabling virtualization on CPU1
> [ 2913.953052] CPU 1 is now offline
> 
> 
> 
> 	Sergey

Thx,
I've updated the bugzilla entry accordingly.

Cheers,
Flo

Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978

[Rafael J. Wysocki]

On Monday, August 30, 2010, Sergey Senozhatsky wrote:
> On (08/30/10 00:36), Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16961
> > Subject		: kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978
> > Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Date		: 2010-08-19 9:54 (11 days old)
> > Message-ID	: <20100819095429.GA5201@swordfish.minsk.epam.com>
> > References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
> > Handled-By	: Avi Kivity <avi@redhat.com>
> > 
> 
> Hello,
> .36-rc3

I take this as "still present".

You've sent the stack traces once, there's no need to do that again and again
(unless something has changed substantially).

Thanks,
Rafael


> [ 2913.218767] kvm: disabling virtualization on CPU1
> [ 2913.219078] CPU 1 is now offline
> [ 2913.221758] lockdep: fixing up alternatives.
> [ 2913.221814] Booting Node 0 Processor 1 APIC 0x1
> [ 2913.363980] ------------[ cut here ]------------
> [ 2913.364042] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978!
> [ 2913.364107] invalid opcode: 0000 [#1] PREEMPT SMP 
> [ 2913.364173] last sysfs file: /sys/devices/system/cpu/cpu1/online
> [ 2913.364262] CPU 1 
> [ 2913.364285] Modules linked in: kvm_intel kvm ipv6 ac battery snd_seq_dummy snd_seq_oss snd_seq_midi_event wmi snd_seq snd_seq_device snd_hda_codec_atihdmi button snd_hda_codec_realtek psmouse serio_raw snd_hda_intel snd_hda_codec
> snd_hwdep snd_pcm_oss snd_pcm broadcom snd_timer usbhid hid tg3 libphy snd_page_alloc evdev snd_mixer_oss snd soundcore ehci_hcd sr_mod usbcore cdrom sd_mod ahci libahci
> [ 2913.364784] 
> [ 2913.364805] Pid: 5912, comm: qemu-kvm Not tainted 2.6.36-rc3-dbg-00144-gb958348-dirty #144 Aspire 5741G    /Aspire 5741G    
> [ 2913.364965] RIP: 0010:[<ffffffffa0223446>]  [<ffffffffa0223446>] kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.365073] RSP: 0000:ffff880150b87b18  EFLAGS: 00010246
> [ 2913.365128] RAX: ffff880150b87b40 RBX: ffff8801534fc000 RCX: ffff880154e75000
> [ 2913.365225] RDX: ffff880002640000 RSI: ffff880154e4e638 RDI: ffff880154e75000
> [ 2913.365292] RBP: ffff880150b87b18 R08: 0000000000000001 R09: 000000000000039c
> [ 2913.365357] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
> [ 2913.365422] R13: ffff880154e75000 R14: ffff880154e4df10 R15: 0000000000000000
> [ 2913.365489] FS:  00007f23062c6710(0000) GS:ffff880002640000(0000) knlGS:0000000000000000
> [ 2913.365563] CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
> [ 2913.365617] CR2: 0000000000000000 CR3: 000000015544d000 CR4: 00000000000006e0
> [ 2913.365682] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 2913.365747] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 2913.365813] Process qemu-kvm (pid: 5912, threadinfo ffff880150b86000, task ffff880154e4df10)
> [ 2913.365929] Stack:
> [ 2913.365953]  ffff880150b87b68 ffffffffa02660a2 ffff880150b87b58 ffffffff81063240
> [ 2913.366034] <0> ffff880154e4df10 0000000154e75000 ffff880157d55f10 ffff8801534fc000
> [ 2913.366132] <0> 0000000000000001 0000000000014200 ffff880150b87b98 ffffffffa022c4cc
> [ 2913.366255] Call Trace:
> [ 2913.366288]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.366355]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.366422]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.366490]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.366547]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.366604]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.366663]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.366715]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.366781]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.366876]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.366956]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.367029]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.367104]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.367210]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.367276]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.367341]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.367401]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.367458]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.367515]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.367568]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.369987]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.372394]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.374739] Code: 2f 02 00 85 c0 75 13 ba 01 00 00 00 31 f6 48 c7 c7 bb 37 22 a0 e8 76 ce e1 e0 c9 c3 55 80 3d 79 2f 02 00 00 48 89 e5 74 02 eb fe <0f> 0b 55 48 89 e5 53 48 89 f3 48 83 ec 08 48 8b 87 98 00 00 00 
> [ 2913.380357] RIP  [<ffffffffa0223446>] kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.383084]  RSP <ffff880150b87b18>
> [ 2913.397343] ---[ end trace 9564e615f538c7b1 ]---
> [ 2913.399336] kvm: enabling virtualization on CPU1
> [ 2913.402446] note: qemu-kvm[5912] exited with preempt_count 1
> [ 2913.404860] NMI watchdog enabled, takes one hw-pmu counter.
> [ 2913.404918] vmwrite error: reg 6c0a value ffff880002650dc0 (err 40177088)
> [ 2913.404924] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
> [ 2913.404928] Call Trace:
> [ 2913.404937]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
> [ 2913.404944]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
> [ 2913.404951]  [<ffffffffa0266147>] vmx_vcpu_load+0x135/0x1a0 [kvm_intel]
> [ 2913.404958]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.404974]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.404985]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.404990]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.404995]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405002]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405010]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
> [ 2913.405016]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
> [ 2913.405022]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
> [ 2913.405028]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
> [ 2913.405034]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
> [ 2913.405039]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
> [ 2913.405046]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
> [ 2913.405053]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
> [ 2913.405060]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
> [ 2913.405066]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
> [ 2913.405071]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
> [ 2913.405079]  [<ffffffff810060b6>] oops_end+0x97/0x9c
> [ 2913.405084]  [<ffffffff810061f8>] die+0x55/0x5e
> [ 2913.405089]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
> [ 2913.405094]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
> [ 2913.405102]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
> [ 2913.405119]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405130]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 2913.405139]  [<ffffffff81404544>] ? irq_return+0x0/0xc
> [ 2913.405149]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
> [ 2913.405166]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405181]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.405189]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405204]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405215]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405221]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405227]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405234]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405240]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405255]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.405269]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.405276]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.405292]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.405306]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.405313]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.405321]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.405334]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.405341]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.405348]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.405354]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.405360]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.405366]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.405373]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.405378] vmwrite error: reg 6c0c value ffff880002644000 (err 40124416)
> [ 2913.405384] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
> [ 2913.405388] Call Trace:
> [ 2913.405395]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
> [ 2913.405402]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
> [ 2913.405410]  [<ffffffffa0266159>] vmx_vcpu_load+0x147/0x1a0 [kvm_intel]
> [ 2913.405417]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405432]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405444]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405450]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405455]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405461]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405469]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
> [ 2913.405475]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
> [ 2913.405482]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
> [ 2913.405489]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
> [ 2913.405495]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
> [ 2913.405501]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
> [ 2913.405508]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
> [ 2913.405515]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
> [ 2913.405522]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
> [ 2913.405528]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
> [ 2913.405534]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
> [ 2913.405540]  [<ffffffff810060b6>] oops_end+0x97/0x9c
> [ 2913.405545]  [<ffffffff810061f8>] die+0x55/0x5e
> [ 2913.405550]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
> [ 2913.405556]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
> [ 2913.405561]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
> [ 2913.405572]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405580]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 2913.405586]  [<ffffffff81404544>] ? irq_return+0x0/0xc
> [ 2913.405592]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
> [ 2913.405603]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.405612]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.405618]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405634]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405645]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405651]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405657]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405664]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405670]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.405686]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.405699]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.405706]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.405721]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.405736]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.405743]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.405750]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.405764]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.405773]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.405784]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.405793]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.405802]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.405810]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.405819]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.405828] vmwrite error: reg 6c10 value 0 (err 0)
> [ 2913.405834] Pid: 5912, comm: qemu-kvm Tainted: G      D     2.6.36-rc3-dbg-00144-gb958348-dirty #144
> [ 2913.405839] Call Trace:
> [ 2913.405849]  [<ffffffffa0263ad5>] vmwrite_error+0x32/0x37 [kvm_intel]
> [ 2913.405861]  [<ffffffffa0263af3>] vmcs_writel+0x19/0x1b [kvm_intel]
> [ 2913.405873]  [<ffffffffa0266176>] vmx_vcpu_load+0x164/0x1a0 [kvm_intel]
> [ 2913.405895]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.405907]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.405915]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.405921]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.405927]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.405934]  [<ffffffff811f7c25>] ? do_raw_spin_unlock+0x8f/0x98
> [ 2913.405941]  [<ffffffff810363d7>] __cond_resched+0x13/0x1f
> [ 2913.405948]  [<ffffffff8103645f>] __cond_resched_lock+0x7c/0x96
> [ 2913.405955]  [<ffffffff810ebc4b>] ? __shrink_dcache_sb+0x253/0x2da
> [ 2913.405961]  [<ffffffff810eb9f0>] ? d_kill+0x64/0x6c
> [ 2913.405967]  [<ffffffff810ebc5c>] __shrink_dcache_sb+0x264/0x2da
> [ 2913.405973]  [<ffffffff810ec34b>] shrink_dcache_parent+0x37/0x136
> [ 2913.405980]  [<ffffffff811287de>] proc_flush_task+0xb2/0x2b2
> [ 2913.405986]  [<ffffffff8103d26d>] release_task+0x7f/0x3ec
> [ 2913.405992]  [<ffffffff8103d20e>] ? release_task+0x20/0x3ec
> [ 2913.405998]  [<ffffffff8103eb9e>] do_exit+0x659/0x6c4
> [ 2913.406004]  [<ffffffff810060b6>] oops_end+0x97/0x9c
> [ 2913.406009]  [<ffffffff810061f8>] die+0x55/0x5e
> [ 2913.406014]  [<ffffffff810030c4>] do_trap+0x11c/0x12b
> [ 2913.406019]  [<ffffffff810032c4>] ? do_invalid_op+0x72/0xa5
> [ 2913.406026]  [<ffffffff810032ee>] do_invalid_op+0x9c/0xa5
> [ 2913.406036]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.406043]  [<ffffffff81403601>] ? trace_hardirqs_off_thunk+0x3a/0x3c
> [ 2913.406050]  [<ffffffff81404544>] ? irq_return+0x0/0xc
> [ 2913.406058]  [<ffffffff81002d1b>] invalid_op+0x1b/0x20
> [ 2913.406076]  [<ffffffffa0223446>] ? kvm_handle_fault_on_reboot+0xf/0x11 [kvm]
> [ 2913.406089]  [<ffffffffa02660a2>] vmx_vcpu_load+0x90/0x1a0 [kvm_intel]
> [ 2913.406098]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.406121]  [<ffffffffa022c4cc>] kvm_arch_vcpu_load+0x73/0xbb [kvm]
> [ 2913.406136]  [<ffffffffa0223cd8>] kvm_sched_in+0xd/0xf [kvm]
> [ 2913.406142]  [<ffffffff8102e0d2>] finish_task_switch+0x90/0xd7
> [ 2913.406147]  [<ffffffff8102e042>] ? finish_task_switch+0x0/0xd7
> [ 2913.406153]  [<ffffffff81401149>] schedule+0x81d/0x8f2
> [ 2913.406158]  [<ffffffff81063240>] ? mark_held_locks+0x50/0x72
> [ 2913.406173]  [<ffffffffa023e838>] ? kvm_cpu_has_interrupt+0x3a/0x56 [kvm]
> [ 2913.406186]  [<ffffffffa0226057>] kvm_vcpu_block+0x8e/0xa9 [kvm]
> [ 2913.406191]  [<ffffffff810530d5>] ? autoremove_wake_function+0x0/0x34
> [ 2913.406206]  [<ffffffffa023125a>] kvm_arch_vcpu_ioctl_run+0x97d/0xc9f [kvm]
> [ 2913.406220]  [<ffffffffa0231177>] ? kvm_arch_vcpu_ioctl_run+0x89a/0xc9f [kvm]
> [ 2913.406226]  [<ffffffff814026a5>] ? __mutex_unlock_slowpath+0x111/0x13d
> [ 2913.406233]  [<ffffffff810346ec>] ? sub_preempt_count+0x92/0xa5
> [ 2913.406245]  [<ffffffffa0225164>] kvm_vcpu_ioctl+0x113/0x4e9 [kvm]
> [ 2913.406250]  [<ffffffff814011cf>] ? schedule+0x8a3/0x8f2
> [ 2913.406257]  [<ffffffff810e98c3>] do_vfs_ioctl+0x4c1/0x502
> [ 2913.406262]  [<ffffffff810dcffc>] ? fget_light+0xe0/0xf8
> [ 2913.406267]  [<ffffffff810dcf6e>] ? fget_light+0x52/0xf8
> [ 2913.406273]  [<ffffffff810e9955>] sys_ioctl+0x51/0x74
> [ 2913.406279]  [<ffffffff81002002>] system_call_fastpath+0x16/0x1b
> [ 2913.749804] kvm: disabling virtualization on CPU2
> [ 2913.749831] CPU 2 is now offline
> [ 2913.751880] lockdep: fixing up alternatives.
> [ 2913.753457] Booting Node 0 Processor 2 APIC 0x4
> [ 2913.918676] kvm: enabling virtualization on CPU2
> [ 2913.920349] NMI watchdog enabled, takes one hw-pmu counter.
> [ 2913.922404] coretemp coretemp.2: TjMax is 105 C.
> [ 2913.952819] kvm: disabling virtualization on CPU1
> [ 2913.953052] CPU 1 is now offline

[Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for /

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17041
Subject		: 2.6.36-rc1 hangs during XFS barrier test for /
Submitter	: Torsten Kaiser <just.for.lkml@googlemail.com>
Date		: 2010-08-20 (10 days old)
Message-ID	: <AANLkTim1PXibiY98GUdMj-UZLTav+n7GAnJ0Mjn6_5a3@mail.gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128231691708710&w=2

Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for /

[Torsten Kaiser]

On Mon, Aug 30, 2010 at 12:36 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a summary report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.35.  Please verify if it still should be listed and let the tracking team
> know (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=17041
> Subject         : 2.6.36-rc1 hangs during XFS barrier test for /
> Submitter       : Torsten Kaiser <just.for.lkml@googlemail.com>
> Date            : 2010-08-20 (10 days old)
> Message-ID      : <AANLkTim1PXibiY98GUdMj-UZLTav+n7GAnJ0Mjn6_5a3@mail.gmail.com>
> References      : http://marc.info/?l=linux-kernel&m=128231691708710&w=2

As noted in comment #1 in this Bug, this was the same Bug as
http://marc.info/?l=linux-kernel&m=128208298507451&w=2
It is fixed as of 2.6.36-rc2.

You can close this Bug as fixed.

Thanks, Torsten

Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for /

[Florian Mickler]

On Mon, 30 Aug 2010 06:36:47 +0200
Torsten Kaiser <just.for.lkml-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:

> On Mon, Aug 30, 2010 at 12:36 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.35.  Please verify if it still should be listed and let the tracking team
> > know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=17041
> > Subject         : 2.6.36-rc1 hangs during XFS barrier test for /
> > Submitter       : Torsten Kaiser <just.for.lkml-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > Date            : 2010-08-20 (10 days old)
> > Message-ID      : <AANLkTim1PXibiY98GUdMj-UZLTav+n7GAnJ0Mjn6_5a3@mail.gmail.com>
> > References      : http://marc.info/?l=linux-kernel&m=128231691708710&w=2
> 
> As noted in comment #1 in this Bug, this was the same Bug as
> http://marc.info/?l=linux-kernel&m=128208298507451&w=2
> It is fixed as of 2.6.36-rc2.
> 
> You can close this Bug as fixed.
> 
> Thanks, Torsten

Done. 

Thx,
Flo

Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for /

[Rafael J. Wysocki]

On Monday, August 30, 2010, Torsten Kaiser wrote:
> On Mon, Aug 30, 2010 at 12:36 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.35.  Please verify if it still should be listed and let the tracking team
> > know (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=17041
> > Subject         : 2.6.36-rc1 hangs during XFS barrier test for /
> > Submitter       : Torsten Kaiser <just.for.lkml@googlemail.com>
> > Date            : 2010-08-20 (10 days old)
> > Message-ID      : <AANLkTim1PXibiY98GUdMj-UZLTav+n7GAnJ0Mjn6_5a3@mail.gmail.com>
> > References      : http://marc.info/?l=linux-kernel&m=128231691708710&w=2
> 
> As noted in comment #1 in this Bug, this was the same Bug as
> http://marc.info/?l=linux-kernel&m=128208298507451&w=2
> It is fixed as of 2.6.36-rc2.
> 
> You can close this Bug as fixed.

Thanks, closed.

Rafael

[Bug #17061] 2.6.36-rc1 on zaurus: bluetooth regression

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject		: 2.6.36-rc1 on zaurus: bluetooth regression
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2010-08-21 15:24 (9 days old)
Message-ID	: <20100821152445.GA1536@ucw.cz>
References	: http://marc.info/?l=linux-kernel&m=128240433828087&w=2

[Bug #17131] WARN with 3c905 boomerang NIC

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17131
Subject		: WARN with 3c905 boomerang NIC
Submitter	: Doug Nazar <nazard.lkml@gmail.com>
Date		: 2010-08-22 6:35 (8 days old)
Message-ID	: <4C70C516.5020404@gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128245894300623&w=2
Handled-By	: David Miller <davem@davemloft.net>

Re: [Bug #17131] WARN with 3c905 boomerang NIC

[Florian Mickler]

On Mon, 30 Aug 2010 00:36:36 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a summary report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.35.  Please verify if it still should be listed and let the tracking team
> know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17131
> Subject		: WARN with 3c905 boomerang NIC
> Submitter	: Doug Nazar <nazard.lkml@gmail.com>
> Date		: 2010-08-22 6:35 (8 days old)
> Message-ID	: <4C70C516.5020404@gmail.com>
> References	: http://marc.info/?l=linux-kernel&m=128245894300623&w=2
> Handled-By	: David Miller <davem@davemloft.net>
> 
> 
Hi Doug!

Paul provided a patch at
https://bugzilla.kernel.org/attachment.cgi?id=28832 .

Has he pinged you already about it? You are not subscribed to the bug
and I didn't see anything on the netdev mailinglist or lkml. 

Cheers,
Flo

Re: [Bug #17131] WARN with 3c905 boomerang NIC

[Doug Nazar]

  On 2010-09-06 1:50 AM, Florian Mickler wrote:
>
> Paul provided a patch at
> https://bugzilla.kernel.org/attachment.cgi?id=28832 .
>
> Has he pinged you already about it? You are not subscribed to the bug
> and I didn't see anything on the netdev mailinglist or lkml.
>

Sorry, kinda ignored this one once David said it was being worked on. 
I've been busy trying to track down why my wireless isn't working.

For the record, neither Paul's patch (095d05: softirq: adjust error 
check) or Ben's (24cd80: 
3c59x: Remove incorrect locking; correct documented lock hierarchy) 
which is sitting in the net-2.6 fix the issue. Tested atop 2bfc96a 
(Linux 2.6.36-rc3)

It seems to be an init issue as it only happens once during boot and 
doesn't impact functionality.

Doug

Re: [Bug #17131] WARN with 3c905 boomerang NIC

[Florian Mickler]

On Mon, 06 Sep 2010 06:30:38 -0400
Doug Nazar <nazard.lkml@gmail.com> wrote:

>   On 2010-09-06 1:50 AM, Florian Mickler wrote:
> >
> > Paul provided a patch at
> > https://bugzilla.kernel.org/attachment.cgi?id=28832 .
> >
> > Has he pinged you already about it? You are not subscribed to the bug
> > and I didn't see anything on the netdev mailinglist or lkml.
> >
> 
> Sorry, kinda ignored this one once David said it was being worked on. 
> I've been busy trying to track down why my wireless isn't working.
> 
> For the record, neither Paul's patch (095d05: softirq: adjust error 
> check) or Ben's (24cd80: 
> 3c59x: Remove incorrect locking; correct documented lock hierarchy) 
> which is sitting in the net-2.6 fix the issue. Tested atop 2bfc96a 
> (Linux 2.6.36-rc3)
> 
> It seems to be an init issue as it only happens once during boot and 
> doesn't impact functionality.
> 
> Doug
> 

Thanks for the update. 

Cheers,
Flo

[Bug #17151] i915: 2.6.36-rc2 hoses my Intel display

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17151
Subject		: i915: 2.6.36-rc2 hoses my Intel display
Submitter	: Jonathan Corbet <corbet@lwn.net>
Date		: 2010-08-23 17:01 (7 days old)
First-Bad-Commit: http://git.kernel.org/linus/32aad86fe88e7323d4fc5e9e423abcee0d55a03d
Message-ID	: <20100823110145.08eb72fd@bike.lwn.net>
References	: http://marc.info/?l=linux-kernel&m=128258293327326&w=2
Handled-By	: Chris Wilson <chris@chris-wilson.co.uk>

Re: [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display

[Jonathan Corbet]

On Mon, 30 Aug 2010 00:36:36 +0200 (CEST)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> The following bug entry is on the current list of known regressions
> from 2.6.35.  Please verify if it still should be listed and let the tracking team
> know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17151

Yes, it was still definitely not working as of just a little prior to
-rc3. 

jon

Re: [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display

[Rafael J. Wysocki]

On Monday, August 30, 2010, Jonathan Corbet wrote:
> On Mon, 30 Aug 2010 00:36:36 +0200 (CEST)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > The following bug entry is on the current list of known regressions
> > from 2.6.35.  Please verify if it still should be listed and let the tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17151
> 
> Yes, it was still definitely not working as of just a little prior to
> -rc3. 

Thanks for the update, hopefully the CC list contains the right addresses.

Rafael

[Bug #17321] i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17321
Subject		: i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e
Submitter	: Arno Schuring <aelschuring@hotmail.com>
Date		: 2010-08-27 20:04 (3 days old)
Message-ID	: <4C781A3A.4010707@hotmail.com>
References	: http://marc.info/?l=linux-kernel&m=128294076822387&w=2

[Bug #17301] i915: 2.6.36-rc2 wrong resolution on gdm start

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17301
Subject		: i915: 2.6.36-rc2 wrong resolution on gdm start
Submitter	: Ivan Bulatovic <combuster@gmx.com>
Date		: 2010-08-24 1:00 (6 days old)
First-Bad-Commit: http://git.kernel.org/linus/9d0498a2bf7455159b317f19531a3e5db2ecc9c4
Message-ID	: <1282611655.2177.19.camel@localhost.localdomain>
References	: http://marc.info/?l=linux-kernel&m=128261168202306&w=2
Handled-By	: Chris Wilson <chris@chris-wilson.co.uk>

[Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17311
Subject		: 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2010-08-27 1:56 (3 days old)
First-Bad-Commit: http://git.kernel.org/linus/5a652052fedbd7869572c757dd2ffc2ed420c69d
Message-ID	: <AANLkTinHbEW36D5R9NSrGgfbOC0Hri3Tg-fA0iR92Udi@mail.gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128287422106267&w=2
Handled-By	: Johannes Berg <johannes@sipsolutions.net>

[Bug #17341] kdump regression compared to v2.6.35

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
Subject		: kdump regression compared to v2.6.35
Submitter	: CAI Qian <caiqian@redhat.com>
Date		: 2010-08-27 12:35 (3 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj@kernel.org>

[Bug #17331] BUG: scheduling while atomic

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17331
Subject		: BUG: scheduling while atomic
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-27 7:59 (3 days old)
Message-ID	: <20100827075911.GA5966@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128289602925505&w=2

2.6.36-rc3-git5: Reported regressions from 2.6.35

[Rafael J. Wysocki]

[NOTE:
 Florian Mickler has joined the regression tracking team.  He is going to
 browse the list periodically to close fixed regressions, add patches etc.
 So, when the listed regressions you care about are fixed, please report
 that to Florian.  If there's a working patch for a regression you care
 about, please report that to him too.]

This message contains a list of some regressions from 2.6.35,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.35, please let us
know either and we'll add them to the list.  Also, please let us know
if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2010-09-12       28       14          13
  2010-08-30       21       16          15


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17952
Subject		: bdi-default hung waiting for kthread_stop to finish
Submitter	: Jeff Layton <jlayton@redhat.com>
Date		: 2010-09-02 18:55 (11 days old)
Message-ID	: <20100902145509.28e4f998@tlielax.poochiereds.net>
References	: http://marc.info/?l=linux-kernel&m=128345371904504&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17752
Subject		: 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)
Submitter	: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date		: 2010-09-01 6:37 (12 days old)
Message-ID	: <tkrat.ed8eda6bc8ffe64e@s5r6.in-berlin.de>
References	: http://marc.info/?l=linux-kernel&m=128332308528119&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17722
Subject		: 2.6.36-rc3: WARNING: at net/mac80211/scan.c:269 ieee80211_scan_completed
Submitter	: Thomas Meyer <thomas@m3y3r.de>
Date		: 2010-08-31 20:14 (13 days old)
Message-ID	: <201008312214.52473.thomas@m3y3r.de>
References	: http://marc.info/?l=linux-kernel&m=128328580504227&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17361
Subject		: Watchdog detected hard LOCKUP in jbd2_journal_get_write_access
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2010-08-29 19:59 (15 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
Subject		: kdump regression compared to v2.6.35
Submitter	: CAI Qian <caiqian@redhat.com>
Date		: 2010-08-27 12:35 (17 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj@kernel.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17331
Subject		: BUG: scheduling while atomic
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-27 7:59 (17 days old)
Message-ID	: <20100827075911.GA5966@swordfish.minsk.epam.com>
References	: http://marc.info/?l=linux-kernel&m=128289602925505&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17321
Subject		: i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e
Submitter	: Arno Schuring <aelschuring@hotmail.com>
Date		: 2010-08-27 20:04 (17 days old)
Message-ID	: <4C781A3A.4010707@hotmail.com>
References	: http://marc.info/?l=linux-kernel&m=128294076822387&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17311
Subject		: 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2010-08-27 1:56 (17 days old)
First-Bad-Commit: http://git.kernel.org/linus/5a652052fedbd7869572c757dd2ffc2ed420c69d
Message-ID	: <AANLkTinHbEW36D5R9NSrGgfbOC0Hri3Tg-fA0iR92Udi@mail.gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128287422106267&w=2
Handled-By	: Johannes Berg <johannes@sipsolutions.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17131
Subject		: WARN with 3c905 boomerang NIC
Submitter	: Doug Nazar <nazard.lkml@gmail.com>
Date		: 2010-08-22 6:35 (22 days old)
Message-ID	: <4C70C516.5020404@gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128245894300623&w=2
Handled-By	: David Miller <davem@davemloft.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject		: 2.6.36-rc1 on zaurus: bluetooth regression
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2010-08-21 15:24 (23 days old)
Message-ID	: <20100821152445.GA1536@ucw.cz>
References	: http://marc.info/?l=linux-kernel&m=128240433828087&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject		: qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter	: Meelis Roos <mroos@linux.ee>
Date		: 2010-08-19 21:03 (25 days old)
Message-ID	: <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
References	: http://marc.info/?l=linux-kernel&m=128225184900892&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16961
Subject		: kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978
Submitter	: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date		: 2010-08-19 9:54 (25 days old)
Message-ID	: <<20100819095429.GA5201@swordfish.minsk.epam.com>>
References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
Handled-By	: Avi Kivity <avi@redhat.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject		: hackbench regression with 2.6.36-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2010-08-18 6:18 (26 days old)
Message-ID	: <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References	: http://marc.info/?l=linux-kernel&m=128211235904910&w=2


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17742
Subject		: 2.6.36-rc2-git5: Oops in snd_pcm_substream_proc_status_read()
Submitter	: Chuck Ebbert <cebbert@redhat.com>
Date		: 2010-09-01 8:19 (12 days old)
Message-ID	: <20100901041924.23a8a865@katamari>
References	: http://marc.info/?l=linux-kernel&m=128332930703451&w=2
		  https://bugzilla.redhat.com/show_bug.cgi?id=628404
		  https://bugzilla.redhat.com/show_bug.cgi?id=628404#c5
Handled-By	: Takashi Iwai <tiwai@suse.de>
Patch		: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-September/031275.html


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.35,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=16444

Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.

Thanks!

[Bug #17341] kdump regression compared to v2.6.35

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
Subject		: kdump regression compared to v2.6.35
Submitter	: CAI Qian <caiqian@redhat.com>
Date		: 2010-08-27 12:35 (17 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj@kernel.org>

2.6.36-rc4-git5: Reported regressions from 2.6.35

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.35,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.35, please let us
know either and we'll add them to the list.  Also, please let us know
if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2010-09-20       38       15          15
  2010-09-12       28       14          13
  2010-08-30       21       16          15


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18872
Subject		: Radeon KMS r100 and STR problems
Submitter	: Richard Mittendorfer <delist@gmx.net>
Date		: 2010-09-17 18:26 (4 days old)
Message-ID	: <20100917202647.aa4b6300.delist@gmx.net>
References	: http://marc.info/?l=linux-kernel&m=128474802809779&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18862
Subject		: [BUG]Kernel 2.6.36rc4 crash when rmmod pm8001
Submitter	: Jack Wang <jack_wang@usish.com>
Date		: 2010-09-17 10:11 (4 days old)
Message-ID	: <3219F4D1734640238A632382C50F633E@usish.com.cn>
References	: http://marc.info/?l=linux-kernel&m=128471846828998&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18742
Subject		: PROBLEM: Kernel panic on 2.6.36-rc4 when loading intel_ips on Core i3 laptop
Submitter	: infernix <infernix@infernix.net>
Date		: 2010-09-15 14:35 (6 days old)
Message-ID	: <4C90D998.6050103@infernix.net>
References	: http://marc.info/?l=linux-kernel&m=128456187928496&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18692
Subject		: 2.6.36-rc4/iwl: warning triggered in net/mac80211/scan.c:266
Submitter	: Michael S. Tsirkin <mst@redhat.com>
Date		: 2010-09-14 14:28 (7 days old)
Message-ID	: <20100914142814.GA8744@redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128447487918792&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18432
Subject		: radeon kms freezes on boot with video= option
Submitter	: Jose Marino <braket@hotmail.com>
Date		: 2010-09-13 22:28 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18402
Subject		: 2.6.36-rc4 KPs whenever booting on a Pentium 4 HT system
Submitter	: Michael Marley <michael@michaelmarley.com>
Date		: 2010-09-13 15:07 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18342
Subject		: [regression] i915 incorrectly detects bogus LVDS connection instead of LVDS1
Submitter	: Woody Suwalski <terraluna977@gmail.com>
Date		: 2010-09-08 15:10 (13 days old)
Message-ID	: <AANLkTim2mrVRCKg-2couMTFV7krHQp0+2e_cbaiT_KYW@mail.gmail.com>
References	: http://marc.info/?l=linux-kernel&m=128395866331382&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=18332
Subject		: [regression] *ERROR* timed out waiting for FORCE_DETECT in 36rc3 on i915
Submitter	: Andi Kleen <andi@firstfloor.org>
Date		: 2010-09-08 13:53 (13 days old)
Message-ID	: <87mxrswddf.fsf@basil.nowhere.org>
References	: http://marc.info/?l=linux-kernel&m=128395400624946&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17752
Subject		: 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory)
Submitter	: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date		: 2010-09-01 6:37 (20 days old)
Message-ID	: <tkrat.ed8eda6bc8ffe64e@s5r6.in-berlin.de>
References	: http://marc.info/?l=linux-kernel&m=128332308528119&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17722
Subject		: 2.6.36-rc3: WARNING: at net/mac80211/scan.c:269 ieee80211_scan_completed
Submitter	: Thomas Meyer <thomas@m3y3r.de>
Date		: 2010-08-31 20:14 (21 days old)
Message-ID	: <201008312214.52473.thomas@m3y3r.de>
References	: http://marc.info/?l=linux-kernel&m=128328580504227&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17361
Subject		: Watchdog detected hard LOCKUP in jbd2_journal_get_write_access
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2010-08-29 19:59 (23 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
Subject		: kdump regression compared to v2.6.35
Submitter	: CAI Qian <caiqian@redhat.com>
Date		: 2010-08-27 12:35 (25 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj@kernel.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject		: 2.6.36-rc1 on zaurus: bluetooth regression
Submitter	: Pavel Machek <pavel@ucw.cz>
Date		: 2010-08-21 15:24 (31 days old)
Message-ID	: <20100821152445.GA1536@ucw.cz>
References	: http://marc.info/?l=linux-kernel&m=128240433828087&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject		: qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter	: Meelis Roos <mroos@linux.ee>
Date		: 2010-08-19 21:03 (33 days old)
Message-ID	: <alpine.SOC.1.00.1008192359310.19654@math.ut.ee>
References	: http://marc.info/?l=linux-kernel&m=128225184900892&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject		: hackbench regression with 2.6.36-rc1
Submitter	: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date		: 2010-08-18 6:18 (34 days old)
Message-ID	: <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References	: http://marc.info/?l=linux-kernel&m=128211235904910&w=2


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.35,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=16444

Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.

Thanks!

[Bug #17341] kdump regression compared to v2.6.35

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 2.6.35.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
Subject		: kdump regression compared to v2.6.35
Submitter	: CAI Qian <caiqian@redhat.com>
Date		: 2010-08-27 12:35 (25 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj@kernel.org>

Re: [Bug #17341] kdump regression compared to v2.6.35

[caiqian]

It had been fixed by Tejun already.

commit 477a3c33d1efa0342a74bd02da2e049191993e2c
Author: Tejun Heo <tj@kernel.org>
Date:   Tue Aug 31 10:54:35 2010 +0200

    workqueue: fix GCWQ_DISASSOCIATED initialization
    
    init_workqueues() incorrectly marks workqueues for all possible CPUs
    associated.  Combined with mayday_mask initialization bug, this can
    make rescuers keep trying to bind to an offline gcwq indefinitely.
    Fix init_workqueues() such that only online CPUs have their gcwqs have
    GCWQ_DISASSOCIATED cleared.

----- "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> This message has been generated automatically as a part of a summary
> report
> of recent regressions.
> 
> The following bug entry is on the current list of known regressions
> from 2.6.35.  Please verify if it still should be listed and let the
> tracking team
> know (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=17341
> Subject		: kdump regression compared to v2.6.35
> Submitter	: CAI Qian <caiqian@redhat.com>
> Date		: 2010-08-27 12:35 (25 days old)
> Message-ID	:
> <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
> References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
> Handled-By	: Tejun Heo <tj@kernel.org>

Re: [Bug #17341] kdump regression compared to v2.6.35

[Rafael J. Wysocki]

On Tuesday, September 21, 2010, caiqian@redhat.com wrote:
> It had been fixed by Tejun already.
> 
> commit 477a3c33d1efa0342a74bd02da2e049191993e2c
> Author: Tejun Heo <tj@kernel.org>
> Date:   Tue Aug 31 10:54:35 2010 +0200
> 
>     workqueue: fix GCWQ_DISASSOCIATED initialization
>     
>     init_workqueues() incorrectly marks workqueues for all possible CPUs
>     associated.  Combined with mayday_mask initialization bug, this can
>     make rescuers keep trying to bind to an offline gcwq indefinitely.
>     Fix init_workqueues() such that only online CPUs have their gcwqs have
>     GCWQ_DISASSOCIATED cleared.

Thanks, closing.

Rafael