* 2.6.36-rc3: Reported regressions from 2.6.35 @ 2010-08-29 22:24 Rafael J. Wysocki 2010-08-29 22:24 ` [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev Rafael J. Wysocki ` (15 more replies) 0 siblings, 16 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:24 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-08-29 22:24 ` Rafael J. Wysocki [not found] ` <courier.4C7C99F2.00001F74@fs.ru.acad.bg> 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki ` (14 subsequent siblings) 15 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:24 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, David S. Miller, Eric Dumazet, Jarek Poplawski, Jarek Poplawski, Plamen Petrov 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
[parent not found: <courier.4C7C99F2.00001F74@fs.ru.acad.bg>]
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-08-31 19:26 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-08-31 19:26 UTC (permalink / raw) To: Plamen Petrov Cc: Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Eric Dumazet, Linux Kernel Mailing List, netdev 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-08-31 19:26 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-08-31 19:26 UTC (permalink / raw) To: Plamen Petrov Cc: Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Eric Dumazet, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-08-31 19:26 ` Jarek Poplawski @ 2010-09-01 10:50 ` Eric Dumazet -1 siblings, 0 replies; 91+ messages in thread From: Eric Dumazet @ 2010-09-01 10:50 UTC (permalink / raw) To: Jarek Poplawski, Plamen Petrov, Herbert Xu Cc: Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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; ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-01 10:50 ` Eric Dumazet 0 siblings, 0 replies; 91+ messages in thread From: Eric Dumazet @ 2010-09-01 10:50 UTC (permalink / raw) To: Jarek Poplawski, Plamen Petrov, Herbert Xu Cc: Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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; ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-01 10:50 ` Eric Dumazet @ 2010-09-01 11:20 ` Jarek Poplawski -1 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-01 11:20 UTC (permalink / raw) To: Eric Dumazet Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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; > > > ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-01 11:20 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-01 11:20 UTC (permalink / raw) To: Eric Dumazet Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA 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; > > > ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-01 13:57 ` Eric Dumazet 0 siblings, 0 replies; 91+ messages in thread From: Eric Dumazet @ 2010-09-01 13:57 UTC (permalink / raw) To: Jarek Poplawski Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-01 13:57 ` Eric Dumazet 0 siblings, 0 replies; 91+ messages in thread From: Eric Dumazet @ 2010-09-01 13:57 UTC (permalink / raw) To: Jarek Poplawski Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-01 13:57 ` Eric Dumazet @ 2010-09-01 15:05 ` Jarek Poplawski -1 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-01 15:05 UTC (permalink / raw) To: Eric Dumazet Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-01 15:05 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-01 15:05 UTC (permalink / raw) To: Eric Dumazet Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-01 10:50 ` Eric Dumazet @ 2010-09-02 1:23 ` David Miller -1 siblings, 0 replies; 91+ messages in thread From: David Miller @ 2010-09-02 1:23 UTC (permalink / raw) To: eric.dumazet Cc: jarkao2, pvp-lsts, herbert, rjw, kernel-testers, maciej.rutecki, linux-kernel, netdev 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-02 1:23 ` David Miller 0 siblings, 0 replies; 91+ messages in thread From: David Miller @ 2010-09-02 1:23 UTC (permalink / raw) To: eric.dumazet Cc: jarkao2, pvp-lsts, herbert, rjw, kernel-testers, maciej.rutecki, linux-kernel, netdev 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-01 10:50 ` Eric Dumazet @ 2010-09-03 8:00 ` Plamen Petrov -1 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-03 8:00 UTC (permalink / raw) To: Eric Dumazet Cc: Jarek Poplawski, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev На 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-03 8:00 ` Plamen Petrov 0 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-03 8:00 UTC (permalink / raw) To: Eric Dumazet Cc: Jarek Poplawski, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev На 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-03 8:00 ` Plamen Petrov @ 2010-09-03 9:06 ` Jarek Poplawski -1 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-03 9:06 UTC (permalink / raw) To: Plamen Petrov Cc: Eric Dumazet, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-03 9:06 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-03 9:06 UTC (permalink / raw) To: Plamen Petrov Cc: Eric Dumazet, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-01 10:50 ` Eric Dumazet @ 2010-09-03 8:30 ` Herbert Xu -1 siblings, 0 replies; 91+ messages in thread From: Herbert Xu @ 2010-09-03 8:30 UTC (permalink / raw) To: Eric Dumazet Cc: Jarek Poplawski, Plamen Petrov, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-03 8:30 ` Herbert Xu 0 siblings, 0 replies; 91+ messages in thread From: Herbert Xu @ 2010-09-03 8:30 UTC (permalink / raw) To: Eric Dumazet Cc: Jarek Poplawski, Plamen Petrov, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-01 10:50 ` Eric Dumazet @ 2010-09-04 20:34 ` Jarek Poplawski -1 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-04 20:34 UTC (permalink / raw) To: Eric Dumazet Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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; ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-04 20:34 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-04 20:34 UTC (permalink / raw) To: Eric Dumazet Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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; ^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-05 7:49 ` Eric Dumazet 0 siblings, 0 replies; 91+ messages in thread From: Eric Dumazet @ 2010-09-05 7:49 UTC (permalink / raw) To: Jarek Poplawski Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-05 7:49 ` Eric Dumazet 0 siblings, 0 replies; 91+ messages in thread From: Eric Dumazet @ 2010-09-05 7:49 UTC (permalink / raw) To: Jarek Poplawski Cc: Plamen Petrov, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-05 7:49 ` Eric Dumazet @ 2010-09-08 4:57 ` Plamen Petrov -1 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-08 4:57 UTC (permalink / raw) To: Eric Dumazet Cc: Jarek Poplawski, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev На 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-08 4:57 ` Plamen Petrov 0 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-08 4:57 UTC (permalink / raw) To: Eric Dumazet Cc: Jarek Poplawski, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA На 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! ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-08 4:57 ` Plamen Petrov @ 2010-09-08 6:20 ` Jarek Poplawski -1 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-08 6:20 UTC (permalink / raw) To: Plamen Petrov Cc: Eric Dumazet, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-08 6:20 ` Jarek Poplawski 0 siblings, 0 replies; 91+ messages in thread From: Jarek Poplawski @ 2010-09-08 6:20 UTC (permalink / raw) To: Plamen Petrov Cc: Eric Dumazet, Herbert Xu, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Linux Kernel Mailing List, netdev 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-09-08 6:20 ` Jarek Poplawski @ 2010-09-08 17:32 ` David Miller -1 siblings, 0 replies; 91+ messages in thread From: David Miller @ 2010-09-08 17:32 UTC (permalink / raw) To: jarkao2 Cc: pvp-lsts, eric.dumazet, herbert, rjw, kernel-testers, maciej.rutecki, linux-kernel, netdev 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 :-) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-08 17:32 ` David Miller 0 siblings, 0 replies; 91+ messages in thread From: David Miller @ 2010-09-08 17:32 UTC (permalink / raw) To: jarkao2 Cc: pvp-lsts, eric.dumazet, herbert, rjw, kernel-testers, maciej.rutecki, linux-kernel, netdev 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 :-) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-08 20:21 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-09-08 20:21 UTC (permalink / raw) To: David Miller Cc: jarkao2, pvp-lsts, eric.dumazet, herbert, kernel-testers, maciej.rutecki, linux-kernel, netdev 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-08 20:21 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-09-08 20:21 UTC (permalink / raw) To: David Miller Cc: jarkao2-Re5JQEeQqe8AvxtiuMwx3w, pvp-lsts-s6OjJRe3oxUfI6EYonfoRA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q, kernel-testers-u79uwXL29TY76Z2rM5mHXA, maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w, linux-kernel-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-12 6:55 ` Plamen Petrov 0 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-12 6:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: David Miller, jarkao2, eric.dumazet, herbert, kernel-testers, maciej.rutecki, linux-kernel, netdev, stable На 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-12 6:55 ` Plamen Petrov 0 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-12 6:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: David Miller, jarkao2-Re5JQEeQqe8AvxtiuMwx3w, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q, kernel-testers-u79uwXL29TY76Z2rM5mHXA, maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w, linux-kernel-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, stable-DgEjT+Ai2ygdnm+yROfE0A На 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-12 15:55 ` David Miller 0 siblings, 0 replies; 91+ messages in thread From: David Miller @ 2010-09-12 15:55 UTC (permalink / raw) To: pvp-lsts Cc: rjw, jarkao2, eric.dumazet, herbert, kernel-testers, maciej.rutecki, linux-kernel, netdev, stable 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-12 15:55 ` David Miller 0 siblings, 0 replies; 91+ messages in thread From: David Miller @ 2010-09-12 15:55 UTC (permalink / raw) To: pvp-lsts-s6OjJRe3oxUfI6EYonfoRA Cc: rjw-KKrjLPT3xs0, jarkao2-Re5JQEeQqe8AvxtiuMwx3w, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q, kernel-testers-u79uwXL29TY76Z2rM5mHXA, maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w, linux-kernel-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, stable-DgEjT+Ai2ygdnm+yROfE0A 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. ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-13 6:49 ` Plamen Petrov 0 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-13 6:49 UTC (permalink / raw) To: David Miller Cc: rjw, jarkao2, eric.dumazet, herbert, kernel-testers, maciej.rutecki, linux-kernel, netdev, stable На 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-13 6:49 ` Plamen Petrov 0 siblings, 0 replies; 91+ messages in thread From: Plamen Petrov @ 2010-09-13 6:49 UTC (permalink / raw) To: David Miller Cc: rjw-KKrjLPT3xs0, jarkao2-Re5JQEeQqe8AvxtiuMwx3w, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q, kernel-testers-u79uwXL29TY76Z2rM5mHXA, maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w, linux-kernel-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, stable-DgEjT+Ai2ygdnm+yROfE0A На 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-12 17:28 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-09-12 17:28 UTC (permalink / raw) To: Plamen Petrov Cc: David Miller, jarkao2, eric.dumazet, herbert, kernel-testers, maciej.rutecki, linux-kernel, netdev, stable 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev @ 2010-09-12 17:28 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-09-12 17:28 UTC (permalink / raw) To: Plamen Petrov Cc: David Miller, jarkao2-Re5JQEeQqe8AvxtiuMwx3w, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q, kernel-testers-u79uwXL29TY76Z2rM5mHXA, maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w, linux-kernel-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, stable-DgEjT+Ai2ygdnm+yROfE0A 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev 2010-08-31 19:26 ` Jarek Poplawski (?) (?) @ 2018-08-29 21:39 ` Mitchell Erblich -1 siblings, 0 replies; 91+ messages in thread From: Mitchell Erblich @ 2018-08-29 21:39 UTC (permalink / raw) To: Jarek Poplawski Cc: Plamen Petrov, Rafael J. Wysocki, Kernel Testers List, Maciej Rutecki, David S. Miller, Eric Dumazet, Linux Kernel Mailing List, netdev 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki 2010-08-29 22:24 ` [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-30 8:45 ` Meelis Roos 2010-08-29 22:36 ` Rafael J. Wysocki ` (13 subsequent siblings) 15 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Meelis Roos 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki @ 2010-08-30 8:45 ` Meelis Roos 2010-08-30 13:46 ` Florian Mickler 0 siblings, 1 reply; 91+ messages in thread From: Meelis Roos @ 2010-08-30 8:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki > 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) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq @ 2010-08-30 13:46 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 13:46 UTC (permalink / raw) To: Meelis Roos Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq @ 2010-08-30 13:46 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 13:46 UTC (permalink / raw) To: Meelis Roos Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16629] fix BUG: using smp_processor_id() in preemptible code (resend) 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki ` (14 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, H. Peter Anvin, Sergey Senozhatsky 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16629] fix BUG: using smp_processor_id() in preemptible code (resend) @ 2010-08-29 22:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, H. Peter Anvin, Sergey Senozhatsky 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [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. 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (2 preceding siblings ...) 2010-08-29 22:36 ` Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki ` (11 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki ` (14 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Avi Kivity, Sergey Senozhatsky 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 @ 2010-08-29 22:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Avi Kivity, Sergey Senozhatsky 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 2010-08-29 22:36 ` Rafael J. Wysocki @ 2010-08-30 8:55 ` Sergey Senozhatsky -1 siblings, 0 replies; 91+ messages in thread From: Sergey Senozhatsky @ 2010-08-30 8:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Avi Kivity, 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 --] ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 @ 2010-08-30 8:55 ` Sergey Senozhatsky 0 siblings, 0 replies; 91+ messages in thread From: Sergey Senozhatsky @ 2010-08-30 8:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Avi Kivity, 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 --] ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 @ 2010-08-30 13:44 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 13:44 UTC (permalink / raw) To: Sergey Senozhatsky Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Avi Kivity 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 @ 2010-08-30 13:44 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 13:44 UTC (permalink / raw) To: Sergey Senozhatsky Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Avi Kivity 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 @ 2010-08-30 17:38 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-30 17:38 UTC (permalink / raw) To: Sergey Senozhatsky Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Avi Kivity 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 @ 2010-08-30 17:38 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-30 17:38 UTC (permalink / raw) To: Sergey Senozhatsky Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Avi Kivity 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki ` (14 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki, trapdoor6 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) ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. @ 2010-08-29 22:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki, trapdoor6 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) ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. 2010-08-29 22:36 ` Rafael J. Wysocki @ 2010-08-30 9:54 ` trapDoor -1 siblings, 0 replies; 91+ messages in thread From: trapDoor @ 2010-08-30 9:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. @ 2010-08-30 9:54 ` trapDoor 0 siblings, 0 replies; 91+ messages in thread From: trapDoor @ 2010-08-30 9:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. @ 2010-08-30 13:39 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 13:39 UTC (permalink / raw) To: public-trapdoor6-Re5JQEeQqe8AvxtiuMwx3w Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. @ 2010-08-30 13:39 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 13:39 UTC (permalink / raw) To: kernel-testers-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. @ 2010-08-30 14:45 ` trapDoor 0 siblings, 0 replies; 91+ messages in thread From: trapDoor @ 2010-08-30 14:45 UTC (permalink / raw) To: Florian Mickler Cc: Rafael J. Wysocki, Maciej Rutecki, LKML, Kernel Testers List 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D. @ 2010-08-30 14:45 ` trapDoor 0 siblings, 0 replies; 91+ messages in thread From: trapDoor @ 2010-08-30 14:45 UTC (permalink / raw) To: Florian Mickler Cc: Rafael J. Wysocki, Maciej Rutecki, LKML, Kernel Testers List 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #16951] hackbench regression with 2.6.36-rc1 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (5 preceding siblings ...) 2010-08-29 22:36 ` Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17131] WARN with 3c905 boomerang NIC Rafael J. Wysocki ` (8 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Zhang, Yanmin 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17131] WARN with 3c905 boomerang NIC 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (6 preceding siblings ...) 2010-08-29 22:36 ` [Bug #16951] hackbench regression with 2.6.36-rc1 Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-09-06 5:50 ` Florian Mickler 2010-08-29 22:36 ` [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / Rafael J. Wysocki ` (7 subsequent siblings) 15 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, David Miller, Doug Nazar 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC 2010-08-29 22:36 ` [Bug #17131] WARN with 3c905 boomerang NIC Rafael J. Wysocki @ 2010-09-06 5:50 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-09-06 5:50 UTC (permalink / raw) To: Doug Nazar Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, David Miller, Rafael J. Wysocki, paulmck 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC @ 2010-09-06 5:50 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-09-06 5:50 UTC (permalink / raw) To: Doug Nazar Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, David Miller, Rafael J. Wysocki, paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC @ 2010-09-06 10:30 ` Doug Nazar 0 siblings, 0 replies; 91+ messages in thread From: Doug Nazar @ 2010-09-06 10:30 UTC (permalink / raw) To: Florian Mickler Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, David Miller, Rafael J. Wysocki, paulmck 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC @ 2010-09-06 10:30 ` Doug Nazar 0 siblings, 0 replies; 91+ messages in thread From: Doug Nazar @ 2010-09-06 10:30 UTC (permalink / raw) To: Florian Mickler Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, David Miller, Rafael J. Wysocki, paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC @ 2010-09-06 11:00 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-09-06 11:00 UTC (permalink / raw) To: Doug Nazar Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, David Miller, Rafael J. Wysocki, paulmck 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC @ 2010-09-06 11:00 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-09-06 11:00 UTC (permalink / raw) To: Doug Nazar Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, David Miller, Rafael J. Wysocki, paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (7 preceding siblings ...) 2010-08-29 22:36 ` [Bug #17131] WARN with 3c905 boomerang NIC Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-30 4:36 ` Torsten Kaiser 2010-08-29 22:36 ` [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display Rafael J. Wysocki ` (6 subsequent siblings) 15 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Torsten Kaiser 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / 2010-08-29 22:36 ` [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / Rafael J. Wysocki @ 2010-08-30 4:36 ` Torsten Kaiser 0 siblings, 0 replies; 91+ messages in thread From: Torsten Kaiser @ 2010-08-30 4:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / @ 2010-08-30 4:36 ` Torsten Kaiser 0 siblings, 0 replies; 91+ messages in thread From: Torsten Kaiser @ 2010-08-30 4:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / @ 2010-08-30 9:27 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 9:27 UTC (permalink / raw) To: Torsten Kaiser Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / @ 2010-08-30 9:27 ` Florian Mickler 0 siblings, 0 replies; 91+ messages in thread From: Florian Mickler @ 2010-08-30 9:27 UTC (permalink / raw) To: kernel-testers-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / 2010-08-30 4:36 ` Torsten Kaiser (?) (?) @ 2010-08-30 17:40 ` Rafael J. Wysocki -1 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-30 17:40 UTC (permalink / raw) To: Torsten Kaiser Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (8 preceding siblings ...) 2010-08-29 22:36 ` [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-30 18:59 ` Jonathan Corbet 2010-08-29 22:36 ` [Bug #17061] 2.6.36-rc1 on zaurus: bluetooth regression Rafael J. Wysocki ` (5 subsequent siblings) 15 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Chris Wilson, Eric Anholt, Jonathan Corbet 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display 2010-08-29 22:36 ` [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display Rafael J. Wysocki @ 2010-08-30 18:59 ` Jonathan Corbet 2010-08-30 20:42 ` Rafael J. Wysocki 0 siblings, 1 reply; 91+ messages in thread From: Jonathan Corbet @ 2010-08-30 18:59 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Chris Wilson, Eric Anholt 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display @ 2010-08-30 20:42 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-30 20:42 UTC (permalink / raw) To: Jonathan Corbet Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Chris Wilson, Eric Anholt, Jesse Barnes, DRI 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display @ 2010-08-30 20:42 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-30 20:42 UTC (permalink / raw) To: Jonathan Corbet Cc: Linux Kernel Mailing List, Kernel Testers List, Maciej Rutecki, Chris Wilson, Eric Anholt, Jesse Barnes, DRI 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17061] 2.6.36-rc1 on zaurus: bluetooth regression 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (9 preceding siblings ...) 2010-08-29 22:36 ` [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17301] i915: 2.6.36-rc2 wrong resolution on gdm start Rafael J. Wysocki ` (4 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Pavel Machek 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17301] i915: 2.6.36-rc2 wrong resolution on gdm start 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (10 preceding siblings ...) 2010-08-29 22:36 ` [Bug #17061] 2.6.36-rc1 on zaurus: bluetooth regression Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17321] i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e Rafael J. Wysocki ` (3 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Chris Wilson, Eric Anholt, Ivan Bulatovic, Jesse Barnes 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17321] i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (11 preceding siblings ...) 2010-08-29 22:36 ` [Bug #17301] i915: 2.6.36-rc2 wrong resolution on gdm start Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki ` (2 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Arno Schuring 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki ` (14 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Johannes Berg, Maxime Bizon, Miles Lane 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected @ 2010-08-29 22:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Johannes Berg, Maxime Bizon, Miles Lane 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17341] kdump regression compared to v2.6.35 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki ` (14 subsequent siblings) 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, CAI Qian, Tejun Heo 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17341] kdump regression compared to v2.6.35 @ 2010-08-29 22:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, CAI Qian, Tejun Heo 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> ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17331] BUG: scheduling while atomic 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki ` (14 preceding siblings ...) 2010-08-29 22:36 ` Rafael J. Wysocki @ 2010-08-29 22:36 ` Rafael J. Wysocki 15 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-08-29 22:36 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Sergey Senozhatsky 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 ^ permalink raw reply [flat|nested] 91+ messages in thread
* 2.6.36-rc3-git5: Reported regressions from 2.6.35 @ 2010-09-12 18:11 Rafael J. Wysocki 2010-09-12 18:14 ` [Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected Rafael J. Wysocki 0 siblings, 1 reply; 91+ messages in thread From: Rafael J. Wysocki @ 2010-09-12 18:11 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds, Kernel Testers List, Network Development, Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List, DRI [NOTE: Florian Mickler has joined the regression tracking team. He is going to browse the list periodically to close fixed regressions, add patches etc. So, when the listed regressions you care about are fixed, please report that to Florian. If there's a working patch for a regression you care about, please report that to him too.] This message contains a list of some regressions from 2.6.35, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.35, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2010-09-12 28 14 13 2010-08-30 21 16 15 Unresolved regressions ---------------------- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17952 Subject : bdi-default hung waiting for kthread_stop to finish Submitter : Jeff Layton <jlayton@redhat.com> Date : 2010-09-02 18:55 (11 days old) Message-ID : <20100902145509.28e4f998@tlielax.poochiereds.net> References : http://marc.info/?l=linux-kernel&m=128345371904504&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17752 Subject : 2.6.36-rc3: inconsistent lock state (iprune_sem, shrink_icache_memory) Submitter : Stefan Richter <stefanr@s5r6.in-berlin.de> Date : 2010-09-01 6:37 (12 days old) Message-ID : <tkrat.ed8eda6bc8ffe64e@s5r6.in-berlin.de> References : http://marc.info/?l=linux-kernel&m=128332308528119&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17722 Subject : 2.6.36-rc3: WARNING: at net/mac80211/scan.c:269 ieee80211_scan_completed Submitter : Thomas Meyer <thomas@m3y3r.de> Date : 2010-08-31 20:14 (13 days old) Message-ID : <201008312214.52473.thomas@m3y3r.de> References : http://marc.info/?l=linux-kernel&m=128328580504227&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17361 Subject : Watchdog detected hard LOCKUP in jbd2_journal_get_write_access Submitter : Christian Casteyde <casteyde.christian@free.fr> Date : 2010-08-29 19:59 (15 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17341 Subject : kdump regression compared to v2.6.35 Submitter : CAI Qian <caiqian@redhat.com> Date : 2010-08-27 12:35 (17 days old) Message-ID : <2136707099.1405541282912500148.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> References : http://marc.info/?l=linux-kernel&m=128291252612135&w=2 Handled-By : Tejun Heo <tj@kernel.org> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17331 Subject : BUG: scheduling while atomic Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Date : 2010-08-27 7:59 (17 days old) Message-ID : <20100827075911.GA5966@swordfish.minsk.epam.com> References : http://marc.info/?l=linux-kernel&m=128289602925505&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17321 Subject : i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e Submitter : Arno Schuring <aelschuring@hotmail.com> Date : 2010-08-27 20:04 (17 days old) Message-ID : <4C781A3A.4010707@hotmail.com> References : http://marc.info/?l=linux-kernel&m=128294076822387&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17311 Subject : 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected Submitter : Miles Lane <miles.lane@gmail.com> Date : 2010-08-27 1:56 (17 days old) First-Bad-Commit: http://git.kernel.org/linus/5a652052fedbd7869572c757dd2ffc2ed420c69d Message-ID : <AANLkTinHbEW36D5R9NSrGgfbOC0Hri3Tg-fA0iR92Udi@mail.gmail.com> References : http://marc.info/?l=linux-kernel&m=128287422106267&w=2 Handled-By : Johannes Berg <johannes@sipsolutions.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17131 Subject : WARN with 3c905 boomerang NIC Submitter : Doug Nazar <nazard.lkml@gmail.com> Date : 2010-08-22 6:35 (22 days old) Message-ID : <4C70C516.5020404@gmail.com> References : http://marc.info/?l=linux-kernel&m=128245894300623&w=2 Handled-By : David Miller <davem@davemloft.net> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061 Subject : 2.6.36-rc1 on zaurus: bluetooth regression Submitter : Pavel Machek <pavel@ucw.cz> Date : 2010-08-21 15:24 (23 days old) Message-ID : <20100821152445.GA1536@ucw.cz> References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971 Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Submitter : Meelis Roos <mroos@linux.ee> Date : 2010-08-19 21:03 (25 days old) Message-ID : <alpine.SOC.1.00.1008192359310.19654@math.ut.ee> References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16961 Subject : kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Date : 2010-08-19 9:54 (25 days old) Message-ID : <<20100819095429.GA5201@swordfish.minsk.epam.com>> References : http://marc.info/?l=linux-kernel&m=128221169606214&w=2 Handled-By : Avi Kivity <avi@redhat.com> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951 Subject : hackbench regression with 2.6.36-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2010-08-18 6:18 (26 days old) Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com> References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2 Regressions with patches ------------------------ Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17742 Subject : 2.6.36-rc2-git5: Oops in snd_pcm_substream_proc_status_read() Submitter : Chuck Ebbert <cebbert@redhat.com> Date : 2010-09-01 8:19 (12 days old) Message-ID : <20100901041924.23a8a865@katamari> References : http://marc.info/?l=linux-kernel&m=128332930703451&w=2 https://bugzilla.redhat.com/show_bug.cgi?id=628404 https://bugzilla.redhat.com/show_bug.cgi?id=628404#c5 Handled-By : Takashi Iwai <tiwai@suse.de> Patch : http://mailman.alsa-project.org/pipermail/alsa-devel/2010-September/031275.html For details, please visit the bug entries and follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. There also is a Bugzilla entry used for tracking the regressions from 2.6.35, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=16444 Please let the tracking team know if there are any Bugzilla entries that should be added to the list in there. Thanks! ^ permalink raw reply [flat|nested] 91+ messages in thread
* [Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected 2010-09-12 18:11 2.6.36-rc3-git5: Reported regressions from 2.6.35 Rafael J. Wysocki @ 2010-09-12 18:14 ` Rafael J. Wysocki 0 siblings, 0 replies; 91+ messages in thread From: Rafael J. Wysocki @ 2010-09-12 18:14 UTC (permalink / raw) To: Linux Kernel Mailing List Cc: Kernel Testers List, Maciej Rutecki, Johannes Berg, Maxime Bizon, Miles Lane 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 (17 days old) First-Bad-Commit: http://git.kernel.org/linus/5a652052fedbd7869572c757dd2ffc2ed420c69d Message-ID : <AANLkTinHbEW36D5R9NSrGgfbOC0Hri3Tg-fA0iR92Udi@mail.gmail.com> References : http://marc.info/?l=linux-kernel&m=128287422106267&w=2 Handled-By : Johannes Berg <johannes@sipsolutions.net> ^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2018-08-30 4:45 UTC | newest] Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-29 22:24 2.6.36-rc3: Reported regressions from 2.6.35 Rafael J. Wysocki 2010-08-29 22:24 ` [Bug #16626] Machine hangs with EIP at skb_copy_and_csum_dev Rafael J. Wysocki [not found] ` <courier.4C7C99F2.00001F74@fs.ru.acad.bg> 2010-08-31 19:26 ` Jarek Poplawski 2010-08-31 19:26 ` Jarek Poplawski 2010-09-01 10:50 ` Eric Dumazet 2010-09-01 10:50 ` Eric Dumazet 2010-09-01 11:20 ` Jarek Poplawski 2010-09-01 11:20 ` Jarek Poplawski 2010-09-01 13:57 ` Eric Dumazet 2010-09-01 13:57 ` Eric Dumazet 2010-09-01 15:05 ` Jarek Poplawski 2010-09-01 15:05 ` Jarek Poplawski 2010-09-02 1:23 ` David Miller 2010-09-02 1:23 ` David Miller 2010-09-03 8:00 ` Plamen Petrov 2010-09-03 8:00 ` Plamen Petrov 2010-09-03 9:06 ` Jarek Poplawski 2010-09-03 9:06 ` Jarek Poplawski 2010-09-03 8:30 ` Herbert Xu 2010-09-03 8:30 ` Herbert Xu 2010-09-04 20:34 ` Jarek Poplawski 2010-09-04 20:34 ` Jarek Poplawski 2010-09-05 7:49 ` Eric Dumazet 2010-09-05 7:49 ` Eric Dumazet 2010-09-08 4:57 ` Plamen Petrov 2010-09-08 4:57 ` Plamen Petrov 2010-09-08 6:20 ` Jarek Poplawski 2010-09-08 6:20 ` Jarek Poplawski 2010-09-08 17:32 ` David Miller 2010-09-08 17:32 ` David Miller 2010-09-08 20:21 ` Rafael J. Wysocki 2010-09-08 20:21 ` Rafael J. Wysocki 2010-09-12 6:55 ` Plamen Petrov 2010-09-12 6:55 ` Plamen Petrov 2010-09-12 15:55 ` David Miller 2010-09-12 15:55 ` David Miller 2010-09-13 6:49 ` Plamen Petrov 2010-09-13 6:49 ` Plamen Petrov 2010-09-12 17:28 ` Rafael J. Wysocki 2010-09-12 17:28 ` Rafael J. Wysocki 2018-08-29 21:39 ` Mitchell Erblich 2010-08-29 22:36 ` [Bug #16971] qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq Rafael J. Wysocki 2010-08-30 8:45 ` Meelis Roos 2010-08-30 13:46 ` Florian Mickler 2010-08-30 13:46 ` Florian Mickler 2010-08-29 22:36 ` [Bug #16629] fix BUG: using smp_processor_id() in preemptible code (resend) Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [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 2010-08-29 22:36 ` [Bug #16961] kernel BUG at arch/x86/kvm/../../../virt/kvm/kvm_main.c:1978 Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-30 8:55 ` Sergey Senozhatsky 2010-08-30 8:55 ` Sergey Senozhatsky 2010-08-30 13:44 ` Florian Mickler 2010-08-30 13:44 ` Florian Mickler 2010-08-30 17:38 ` Rafael J. Wysocki 2010-08-30 17:38 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #16881] [REGRESSION, Radeon-KMS] 2.6.36-rc1,2 - missing textures in 0 A.D Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-30 9:54 ` trapDoor 2010-08-30 9:54 ` trapDoor 2010-08-30 13:39 ` Florian Mickler 2010-08-30 13:39 ` Florian Mickler 2010-08-30 14:45 ` trapDoor 2010-08-30 14:45 ` trapDoor 2010-08-29 22:36 ` [Bug #16951] hackbench regression with 2.6.36-rc1 Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17131] WARN with 3c905 boomerang NIC Rafael J. Wysocki 2010-09-06 5:50 ` Florian Mickler 2010-09-06 5:50 ` Florian Mickler 2010-09-06 10:30 ` Doug Nazar 2010-09-06 10:30 ` Doug Nazar 2010-09-06 11:00 ` Florian Mickler 2010-09-06 11:00 ` Florian Mickler 2010-08-29 22:36 ` [Bug #17041] 2.6.36-rc1 hangs during XFS barrier test for / Rafael J. Wysocki 2010-08-30 4:36 ` Torsten Kaiser 2010-08-30 4:36 ` Torsten Kaiser 2010-08-30 9:27 ` Florian Mickler 2010-08-30 9:27 ` Florian Mickler 2010-08-30 17:40 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17151] i915: 2.6.36-rc2 hoses my Intel display Rafael J. Wysocki 2010-08-30 18:59 ` Jonathan Corbet 2010-08-30 20:42 ` Rafael J. Wysocki 2010-08-30 20:42 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17061] 2.6.36-rc1 on zaurus: bluetooth regression Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17301] i915: 2.6.36-rc2 wrong resolution on gdm start Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17321] i386 WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x2f/0x7e Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17341] kdump regression compared to v2.6.35 Rafael J. Wysocki 2010-08-29 22:36 ` Rafael J. Wysocki 2010-08-29 22:36 ` [Bug #17331] BUG: scheduling while atomic Rafael J. Wysocki 2010-09-12 18:11 2.6.36-rc3-git5: Reported regressions from 2.6.35 Rafael J. Wysocki 2010-09-12 18:14 ` [Bug #17311] 2.6.36-rc2-git4 - INFO: possible circular locking dependency detected Rafael J. Wysocki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.