* 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ messages in thread
* [Bug #17341] kdump regression compared to v2.6.35
@ 2010-08-29 22:36 ` Rafael J. Wysocki
0 siblings, 0 replies; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC
@ 2010-09-06 5:50 ` Florian Mickler
0 siblings, 0 replies; 90+ 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] 90+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC
@ 2010-09-06 10:30 ` Doug Nazar
0 siblings, 0 replies; 90+ 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] 90+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC
@ 2010-09-06 10:30 ` Doug Nazar
0 siblings, 0 replies; 90+ 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] 90+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC
@ 2010-09-06 11:00 ` Florian Mickler
0 siblings, 0 replies; 90+ 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] 90+ messages in thread
* Re: [Bug #17131] WARN with 3c905 boomerang NIC
@ 2010-09-06 11:00 ` Florian Mickler
0 siblings, 0 replies; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ 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; 90+ 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] 90+ messages in thread
end of thread, other threads:[~2018-08-30 4:45 UTC | newest]
Thread overview: 90+ 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
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.