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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> >Date		: 2010-08-19 09:57 (11 days old)
> >Handled-By	:  Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >
> >
> 
> 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

[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

[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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> 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

[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

[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

[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

[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

[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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
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

[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

[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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> Signed-off-by: Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> 
> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
>> Signed-off-by: Jarek Poplawski<jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> CC: Eric Dumazet<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>>
>> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
>
>

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

[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

[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

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> 
> 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

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> 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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
>>
>> 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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> Signed-off-by: Jarek Poplawski <jarkao2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Plamen Petrov <pvp-lsts-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

Thanks,
Plamen

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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
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

[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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> 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

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> 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-s6OjJRe3oxUfI6EYonfoRA@public.gmane.org>
> >>
> >> 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

[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 #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 #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-Y27EyoLml9s@public.gmane.org> 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-Y27EyoLml9s@public.gmane.org>
> > Date		: 2010-08-19 21:03 (11 days old)
> > Message-ID	: <alpine.SOC.1.00.1008192359310.19654-ptEonEWSGqKptlylMvRsHA@public.gmane.org>
> > 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

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 #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-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>

[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: 16587 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-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

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

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-XMD5yJDbdMReXY1tMh2IBg@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-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> > Date		: 2010-08-19 9:54 (11 days old)
> > Message-ID	: <20100819095429.GA5201-dY8u8AhHFaWtd10JCjopabkcH5ONE+aC-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> > References	: http://marc.info/?l=linux-kernel&m=128221169606214&w=2
> > Handled-By	: Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@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

[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-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

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

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 #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)

[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-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.

-- 
Regards
Tomasz

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-XMD5yJDbdMQAvxtiuMwx3w@public.gmane.organe.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.

[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-sVu6HhrpSfRAfugRpC6u6w@public.gmane.org> wrote:
>
>
> On Mon, 30 Aug 2010 10:54:41 +0100
> trapDoor <trapdoor6-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@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

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 #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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-08-18 9:11 (12 days old)
Message-ID	: <20100818091157.GA5238-dY8u8AhHFaWtd10JCjopabkcH5ONE+aC@public.gmane.org>
References	: http://marc.info/?l=linux-kernel&m=128212276618793&w=2
Handled-By	: H. Peter Anvin <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Patch		: http://marc.info/?l=linux-kernel&m=128212276618793&w=2

[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 #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 #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-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

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-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> > Date            : 2010-08-20 (10 days old)
> > Message-ID      : <AANLkTim1PXibiY98GUdMj-UZLTav+n7GAnJ0Mjn6_5a3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> > 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 /

[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 #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-KKrjLPT3xs0@public.gmane.org> 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

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 #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-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=17131
> Subject		: WARN with 3c905 boomerang NIC
> Submitter	: Doug Nazar <nazard.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2010-08-22 6:35 (8 days old)
> Message-ID	: <4C70C516.5020404-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> References	: http://marc.info/?l=linux-kernel&m=128245894300623&w=2
> Handled-By	: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> 
> 
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

[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

[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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

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 #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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-08-27 1:56 (3 days old)
First-Bad-Commit: http://git.kernel.org/linus/5a652052fedbd7869572c757dd2ffc2ed420c69d
Message-ID	: <AANLkTinHbEW36D5R9NSrGgfbOC0Hri3Tg-fA0iR92Udi-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References	: http://marc.info/?l=linux-kernel&m=128287422106267&w=2
Handled-By	: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

[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 #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 #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 #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

[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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date		: 2010-08-27 12:35 (3 days old)
Message-ID	: <2136707099.1405541282912500148.JavaMail.root-k5qu2F3t005+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
References	: http://marc.info/?l=linux-kernel&m=128291252612135&w=2
Handled-By	: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

[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>

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

[trapDoor]

---------- Forwarded message ----------
From:  <bugzilla-daemon@bugzilla.kernel.org>
Date: Mon, Aug 30, 2010 at 8:28 PM
Subject: [Bug 16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing
textures in 0 A.D.
To: trapdoor6@gmail.com


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


--- Comment #8 from Alex Deucher <alexdeucher@gmail.com>  2010-08-30
19:28:00 ---
> I've installed 0ad here, however, I've never used it before.  Can you explain>
> how to trigger the bug?

I can't log on to bugzilla again, so replying from here.

When you start the game please choose single player, default map
(Arcadia) and accept (you can skip the players setup). The bug appears
right away when the map has been loaded and the game begins. On my box
that happens only on kernels 2.6.36-rc[1-3]. On 2.6.35.[0-4] it's OK.

-- 
Thanks,
Tomasz

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

[trapDoor]

On Mon, Aug 30, 2010 at 9:31 PM, trapDoor <trapdoor6@gmail.com> wrote:
> ---------- Forwarded message ----------
> From:  <bugzilla-daemon@bugzilla.kernel.org>
> Date: Mon, Aug 30, 2010 at 8:28 PM
> Subject: [Bug 16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing
> textures in 0 A.D.
> To: trapdoor6@gmail.com
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16881
>
>
> --- Comment #8 from Alex Deucher <alexdeucher@gmail.com>  2010-08-30
> 19:28:00 ---
>> I've installed 0ad here, however, I've never used it before.  Can you explain>
>> how to trigger the bug?
>
> I can't log on to bugzilla again, so replying from here.
>
> When you start the game please choose single player, default map
> (Arcadia) and accept (you can skip the players setup). The bug appears
> right away when the map has been loaded and the game begins. On my box
> that happens only on kernels 2.6.36-rc[1-3]. On 2.6.35.[0-4] it's OK.
>
> --
> Thanks,
> Tomasz
>

One more thing. I have no support for S3TC compressed textures enabled
in mesa and that turns up a performance warning message. I just accept
it to get to the initial game menu. Lack of S3TC support causes
performance slowdown on both 'good' and 'bad' kernels but this is
rather irrelevant for the case we are testing. What's important is to
keep the same settings within libdrm, mesa etc when running the game
on 2.6.35.x and 2.6.36-rcx

-- 
Thanks,
Tomasz

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

[bugzilla-daemon]

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

           Summary: [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing
                    textures in 0 A.D.
           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.36-rc2
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
        AssignedTo: drivers_video-dri@kernel-bugs.osdl.org
        ReportedBy: trapdoor6@gmail.com
                CC: trapdoor6@gmail.com
        Regression: Yes


Created an attachment (id=27751)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=27751)
0 A.D. on kernel 2.6.35.3

Pasting below what I already posted on LKML. These e-mails describe the
problem.
Also attaching related screenshots and archived log files.


---------- Forwarded messages ----------
### Link to LKML thread: http://lkml.org/lkml/2010/8/24/19

From: trapDoor <trapdoor6@gmail.com>
Date: Tue, Aug 24, 2010 at 12:27 PM
Subject: Re: [REGRESSION, Radeon-KMS] 2.6.36-rc1 - graphic issues in 0. A.D.
To: Alex Deucher <alexdeucher@gmail.com>


On Tue, Aug 24, 2010 at 6:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Mon, Aug 23, 2010 at 12:00 PM, trapDoor <trapdoor6@gmail.com> wrote:
>> On Mon, Aug 23, 2010 at 6:12 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>> On Sun, Aug 22, 2010 at 3:41 PM, trapDoor <trapdoor6@gmail.com> wrote:
>>>> Hello,
>>>> Just wanted to let you know about this before bisecting which
>>>> hopefully I will be able to start tomorrow. Please take a look at the
>>>> screenshots in below links to see the difference with rendering
>>>> textures in 0 A.D. alpha1 on kernel 2.6.35.3 and 2.6.36-rc1-git3. [0
>>>> A.D. - strategic game, OS clone of Age of Empires; home page:
>>>> http://wildfiregames.com/0ad/]
>>>>
>>>> 0 A.D. on kernel 2.6.35.3 [good]:
>>>> http://picasaweb.google.co.uk/104351852606666221362/0ad?authkey=Gv1sRgCMne0NqXpuzR_gE#5508312214769142226
>>>>
>>>> 0 A.D. on kernel 2.6.36-rc1-git3:
>>>> http://picasaweb.google.co.uk/104351852606666221362/0ad?authkey=Gv1sRgCMne0NqXpuzR_gE#5508312218519295058
>>>>
>>>> Please note that in both cases only kernel was different. The other
>>>> components [including hardware] were in the same versions and had the
>>>> same options (like the game itself, xorg-ati drivers, mesa, libdrm
>>>> [S3TC disabled], etc.). So it must be kernel then.
>>>
>>> What card?  Anything in your dmesg?
>>>
>>> Alex
>>>
>>
>> Hi Alex,
>> Sorry for lack of details in my first e-mail. I was hoping to send you
>> the logs together with bisecting results. Unfortunately there are
>> other issues between 2.6.35-git2 - the last 'good' kernel (which
>> doesn't include the first drm pull for 2.6.36 window merge) - and
>> 2.6.36-rc1. Due to those issues I can't bisect.
>>
>> For example:
>> 1) First I tried to narrow the problem down to the closest affected
>> kernel snapshot. So I marked 2.6.35-git2 as good and I was expecting
>> that 2.6.35-git3 will be a bad one (as -git3 is the first snapshot
>> that includes drm patches from the first drm pull). But on -git3 0
>> A.D. even fails to start.
>>
>> 2) Then I was hoping to do bisecting between 2.6.35-git11 and
>> 2.6.35-git12 (-git12 is the first snapshot that includes patches from
>> the second drm pull). But these both snapshots won't even compile for
>> me. It stops suddenly at the second stage of making modules without
>> giving any errors (despite kernel debugging enabled in .config). I
>> remember I had this problem for a while, AFAIR since around
>> 2.6.35-git5 to -git15 - between these I couldn't compile any snapshot
>> I had tried.
>>
>> It's very likely that the issue I wanted to bisect is related to one
>> of or both drm pulls . So doing bisect between e.g. these kernels:
>> 2.6.35-git16 (which includes both drm pulls; assuming it's the first
>> snapshot since -git5 I could compile) and 2.6.36-rc1 would be
>> pointless - they both will be bad.
>>
>>
>> ------------
>> Now, this is my card:
>>
>> Asus ATI Radeon HD3650 Silent 512MB
>> some glxinfo details:
>>        OpenGL vendor string: Advanced Micro Devices, Inc.
>>        OpenGL renderer string: Mesa DRI R600 (RV635 9598) 20090101  TCL DRI2
>>        OpenGL version string: 2.1 Mesa 7.9-devel
>>        OpenGL shading language version string: 1.20
>>
>>
>> ------------
>> About the logs. It happens that 0 A.D. does produce really huge logs.
>> Running the game just for about 10 SECONDS (counting after chosen map
>> has been loaded) relulted in these:
>>
>> On a 'good' kernel 2.6.35.3
>>        60K     ./Xorg.0.log
>>        48K     ./dmesg
>>        27M     ./kern.log
>>        27M     ./syslog
>>        27M     ./messages
>>        81M     [total]
>>
>> on a bad kernel 2.6.36-rc1
>>        60K     ./Xorg.0.log
>>        52K     ./dmesg
>>        21M     ./kern.log
>>        21M     ./syslog
>>        21M     ./messages
>>        63M     [total]
>>
>> There's no mistake above: 3 logs had been blown up to over 20M during
>> only the little time when the game was running.
>> How I did it: deleted all those logs completely, re-booted from the
>> 'good' kernel, run the game and stopped. Then archived the logs,
>> deleted again and repeated the same on the 'bad' kernel.
>>
>> So it looks like 99,999% of all lines in: kern.log, messages in syslog
>> were produced on both kernels when 0 A.D. was running. Before I first
>> time run it, I had never seen kern.log and messages in /var/log at
>> all, and syslog was never bigger than around 1,5M (with logs collected
>> from several boots and during a couple of days). Running 0 A.D. for a
>> couple of minutes results in about 1G for each of those 3 logs.
>>
>> After compressing, the archive files are relatively small:
>>        2.0M    ./2.6.35.3_0ad-logs.tar.bz2
>>        680K    ./2.6.35.3_0ad-logs.tar.lzma
>>
>>        1.6M    ./2.6.36-rc1-00159-g36423a5_0ad-logs.tar.bz2
>>        748K    ./2.6.36-rc1-00159-g36423a5_0ad-logs.tar.lzma [yes, somehow >> this came up bigger than 2.6.35.3(...).lzma]
>>
>>
>> Do you mind if I send the .lzma's to you (unless you prefer .bz2)? I
>> won't cc LKML or anyone of course, they will be sent only to you.
>> Please let me know.
>
> I don't really need the whole files, likely it's just a few messages
> repeated.  Go ahead and send me the files and I'll take a look.
>
> Alex
>

Files attached.
The problem still occurs on 2.6.36-rc2-00098-gd1b113b (which includes
drm patches from yesterday's pull).

--
Thanks
Tomasz
---------- End of forwarded messages ----------


Tomasz

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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





--- Comment #1 from trapdoor6@gmail.com  2010-08-24 12:26:19 ---
Created an attachment (id=27761)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=27761)
0 A.D. on kernel 2.6.36-rc1-git3

Lots of missing textures; they are displayed correctly on kernel 2.6.35.3

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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


trapdoor6@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|All                         |x86-64




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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





--- Comment #2 from trapdoor6@gmail.com  2010-08-24 12:32:21 ---
Created an attachment (id=27771)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=27771)
logs generated on 2.6.35.3 when 0 A.D. was running

These logs uncompressed are 81 MB. Archived in tar.lzma format for best
compression ratio.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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





--- Comment #3 from trapdoor6@gmail.com  2010-08-24 12:34:13 ---
Created an attachment (id=27781)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=27781)
logs generated on 2.6.36-rc1-git3 when 0 A.D. was running

These logs uncompressed are 62 MB. Archived in tar.lzma format for best
compression ratio

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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


Rafael J. Wysocki <rjw@sisk.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maciej.rutecki@gmail.com,
                   |                            |rjw@sisk.pl
             Blocks|                            |16444




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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





--- Comment #4 from Rafael J. Wysocki <rjw@sisk.pl>  2010-08-26 20:00:53 ---
*** Bug 17141 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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


Florian Mickler <florian@mickler.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |florian@mickler.org




--- Comment #5 from Florian Mickler <florian@mickler.org>  2010-08-30 13:38:27 ---

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

> 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.
>

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
--

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

[bugzilla-daemon]

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


Alex Deucher <alexdeucher@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexdeucher@gmail.com




--- Comment #6 from Alex Deucher <alexdeucher@gmail.com>  2010-08-30 17:01:45 ---
Do you know what specific commit caused the breakage?  Both sets of logs have
the same vbo message.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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





--- Comment #7 from trapdoor6@gmail.com  2010-08-30 18:07:05 ---
Alex,
Unfortunately I don't know. I would if I could do bisecting. But due to the
problems I described in the first e-mail I couldn't. So far I've got only what
I had initially: the screenshot and the logs. Maybe there are some other logs
which could give us something more specific? I have searched in my home folder
in the 0 A.D. config and cache files but I can't see anything useful there.

I wonder if anyone else has come across the same issue? Or maybe you would be
able to reproduce it? That involves installing O A.D., unfortunately (I don't
what other software would be good to use as an equivalent for testing this
case).

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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





--- Comment #8 from Alex Deucher <alexdeucher@gmail.com>  2010-08-30 19:28:00 ---
I've installed 0ad here, however, I've never used it before.  Can you explain
how to trigger the bug?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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


trapdoor6@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Kernel Version|2.6.36-rc2                  |2.6.36-rc2,3




--- Comment #9 from trapdoor6@gmail.com  2010-08-30 20:53:51 ---
[originally posted on LKML]

I can't log on to bugzilla again, so replying from here [LKML].

When you start the game please choose single player, default map
(Arcadia) and accept (you can skip the players setup). The bug appears
right away when the map has been loaded and the game begins. On my box
that happens only on kernels 2.6.36-rc[1-3]. On 2.6.35.[0-4] it's OK.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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





--- Comment #10 from trapdoor6@gmail.com  2010-08-30 20:54:56 ---
One more thing. I have no support for S3TC compressed textures enabled
in mesa and that turns up a performance warning message. I just accept
it to get to the initial game menu. Lack of S3TC support causes
performance slowdown on both 'good' and 'bad' kernels but this is
rather irrelevant for the case we are testing. What's important is to
keep the same settings within libdrm, mesa etc when running the game
on 2.6.35.x and 2.6.36-rcx

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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





--- Comment #11 from Alex Deucher <alexdeucher@gmail.com>  2010-08-30 21:33:07 ---
Weird; works fine here (other than the vbo warnings).  Everything renders
correctly.  What version of mesa are you using?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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





--- Comment #12 from trapdoor6@gmail.com  2010-08-30 22:29:27 ---
Here you are:
mesa 7.9.0+git20100830.f3eebb84-0ubuntu0sarvatt~lucid [classic drivers]

Installed from the following Ubuntu (PPA) repository:
https://edge.launchpad.net/~xorg-edgers/+archive/ppa/

Published on 2010-08-24
  * Checkout from git 20100823 (master branch) up to commit:
1288d5c39234e7c54ae2fbb81dd788c98c62a7b3
[http://cgit.freedesktop.org/mesa/mesa/commit/?id=1288d5c39234e7c54ae2fbb81dd788c98c62a7b3]

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--

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

[bugzilla-daemon]

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





--- Comment #13 from trapdoor6@gmail.com  2010-08-30 22:34:39 ---
Also here is my driconf config [~/dric], maybe it's something there ?

<driconf>
    <device screen="0" driver="dri2">
        <application name="Default">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
    <device screen="0" driver="r600">
        <application name="all">
            <option name="force_s3tc_enable" value="false" />
            <option name="disable_s3tc" value="true" />
            <option name="fp_optimization" value="0" />
            <option name="fthrottle_mode" value="2" />
            <option name="disable_stencil_two_side" value="false" />
            <option name="tcl_mode" value="3" />
            <option name="texture_depth" value="0" />
            <option name="def_max_anisotropy" value="1.0" />
            <option name="no_rast" value="false" />
            <option name="command_buffer_size" value="8" />
            <option name="round_mode" value="0" />
            <option name="dither_mode" value="0" />
            <option name="texture_coord_units" value="8" />
            <option name="disable_lowimpact_fallback" value="true" />
            <option name="texture_image_units" value="8" />
            <option name="color_reduction" value="1" />
            <option name="vblank_mode" value="0" />
        </application>
    </device>
</driconf>

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--