* 2.6.29-rc4: Reported regressions from 2.6.28
@ 2009-02-08 19:05 Rafael J. Wysocki
2009-02-08 19:06 ` Rafael J. Wysocki
` (48 more replies)
0 siblings, 49 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:05 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List
This message contains a list of some regressions from 2.6.28, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.28, please let me know
either and I'll add them to the list. Also, please let me 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
----------------------------------------
2009-02-08 82 45 36
2009-02-04 66 51 39
2009-01-20 38 35 27
2009-01-11 13 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject : uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-02-08 14:58 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123410529909318&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject : BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter : Alessandro Bono <alessandro.bono@gmail.com>
Date : 2009-02-08 11:04 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409113223833&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
Subject : 2.6.28.4 regression: mmap fails if mlockall used
Submitter : Sami Farin <safari-kernel@safari.iki.fi>
Date : 2009-02-08 10:52 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject : USB flash disk surprise disconnect
Submitter : Vegard Nossum <vegard.nossum@gmail.com>
Date : 2009-02-08 10:21 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <paul@burly.ondioline.org>
Date : 2009-01-21 7:15 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
Subject : Build failure with latest -git: btrfs on ppc64
Submitter : Chuck Ebbert <cebbert@redhat.com>
Date : 2009-02-07 20:50 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12664
Subject : viafb triggers BUG at mm/vmalloc.c:294
Submitter : wixor <wixorpeek@gmail.com>
Date : 2009-02-07 19:44 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123403591109515&w=4
Handled-By : Alexey Dobriyan <adobriyan@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12661
Subject : commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Date : 2009-02-05 14:41 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ff3b938ec6782e6585a83d5459b98b0c3f6eb8
References : http://marc.info/?l=linux-kernel&m=123384496107361&w=4
Handled-By : Herbert Xu <herbert@gondor.apana.org.au>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12660
Subject : Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-02-04 21:11 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123378196022258&w=4
Handled-By : Ingo Molnar <mingo@elte.hu>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12659
Subject : Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
Submitter : 2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash drives
Date : 2009-02-03 4:58 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123363718614763&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12656
Subject : iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
Submitter : Alex Riesen <fork0@users.sf.net>
Date : 2009-02-08 01:52 (1 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12650
Subject : Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
Submitter : Damien Wyart <damien.wyart@free.fr>
Date : 2009-01-20 16:25 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123246937207675&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12649
Subject : Early crash with 2.6.29-rc3
Submitter : Andrew McMillan <andrew@morphoss.com>
Date : 2009-02-04 20:03 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123377840816097&w=4
Handled-By : Len Brown <lenb@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12617
Subject : unable to compile e100 firmware into kernel
Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
Date : 2009-01-31 15:59 (9 days old)
References : http://marc.info/?l=linux-kernel&m=123341764915181&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12615
Subject : boot hangs while bringing up gianfar ethernet
Submitter : Ira Snyder <iws@ovro.caltech.edu>
Date : 2009-01-29 19:41 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123325817201665&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
Subject : [Suspend regression][DRM, RADEON]
Submitter : etienne <etienne.basset@numericable.fr>
Date : 2009-01-28 22:00 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
http://marc.info/?l=linux-kernel&m=123334865404574&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12610
Subject : sync-Regression in 2.6.28.2?
Submitter : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date : 2009-01-27 9:35 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123304977706620&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh@veritas.com>
Date : 2009-01-21 21:12 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
Submitter : Jan Kara <jack@suse.cz>
Date : 2009-01-30 1:23 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-01-29 11:35 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12571
Subject : Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
Submitter : Ross Boswell <drb@med.co.nz>
Date : 2009-01-29 03:46 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12551
Subject : end_request: I/O error, dev cciss/c0d0, sector 87435720
Submitter : Ralf Hildebrandt <ralf.hildebrandt@charite.de>
Date : 2009-01-27 06:51 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12510
Subject : 2.6.29-rc2 dies on startup
Submitter : Ferenc Wagner <wferi@niif.hu>
Date : 2009-01-19 12:53 (21 days old)
References : http://marc.info/?l=linux-kernel&m=123236969321703&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12508
Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2009-01-17 22:46 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
References : http://marc.info/?l=linux-kernel&m=123223247325452&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
Subject : [slab corruption] BUG key_jar: Poison overwritten
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-01-15 18:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
Handled-By : David Howells <dhowells@redhat.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12502
Subject : pipe_read oops on sh
Submitter : Adrian McMenamin <lkmladrian@gmail.com>
Date : 2009-01-15 9:48 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123201298005600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12501
Subject : build bug in eeepc-laptop.c
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-01-14 17:25 (26 days old)
References : http://lkml.org/lkml/2009/1/14/315
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-01-13 18:34 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12497
Subject : new barrier warnings in 2.6.29-rc1
Submitter : Christoph Hellwig <hch@lst.de>
Date : 2009-01-12 15:46 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123177528217154&w=4
Handled-By : Jens Axboe <jens.axboe@oracle.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12494
Subject : Sony backlight regression from 2.6.28 to 29-rc
Submitter : Norbert Preining <preining@logic.at>
Date : 2009-01-19 8:14 (21 days old)
References : http://marc.info/?l=linux-acpi&m=123235286829512&w=4
Handled-By : Mattia Dongili <malattia@linux.it>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By : Bob Copeland <me@bobcopeland.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
Subject : X hangs following switch from radeonfb console - Bisected
Submitter : Graham Murray <graham@gmurray.org.uk>
Date : 2009-01-13 14:03 (27 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
Subject : possible circular locking dependency on i915 dma
Submitter : Wang Chen <wangchen@cn.fujitsu.com>
Date : 2009-01-08 14:11 (32 days old)
References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12418
Subject : Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Date : 2009-01-07 22:43 (33 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
References : http://marc.info/?l=linux-kernel&m=123136836213319&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Date : 2009-01-05 4:13 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12663
Subject : Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
Submitter : Jiri Slaby <jirislaby@gmail.com>
Date : 2009-02-07 18:40 (2 days old)
References : http://lkml.org/lkml/2009/2/7/100
Handled-By : Brian Gerst <brgerst@gmail.com>
Patch : http://lkml.org/lkml/2009/2/7/100
http://lkml.org/lkml/2009/2/8/59
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12662
Subject : linux 2.6.29-rc3 kernel failure with mptsas
Submitter : Morten P.D. Stevens <mstevens@win-professional.com>
Date : 2009-02-05 22:29 (4 days old)
References : http://marc.info/?l=linux-kernel&m=123387302729741&w=4
Handled-By : Andrew Morton <akpm@linux-foundation.org>
Patch : http://marc.info/?l=linux-kernel&m=123396429501103&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12618
Subject : hackbench [pthread mode] regression with 2.6.29-rc3
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-02-01 7:30 (8 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=490dea45d00f01847ebebd007685d564aaf2cd98
References : http://marc.info/?l=linux-kernel&m=123347347726527&w=4
Handled-By : Peter Zijlstra <peterz@infradead.org>
Patch : http://marc.info/?l=linux-kernel&m=123383366122146&w=4
http://marc.info/?l=linux-kernel&m=123383366222152&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
Subject : v2.6.29-rc2 libata sff 32bit PIO regression
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-01-23 23:52 (17 days old)
References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
http://marc.info/?l=linux-kernel&m=123254501314058&w=4
Handled-By : Mikael Pettersson <mikpe@it.uu.se>
Hugh Dickins <hugh@veritas.com>
Sergei Shtylyov <sshtylyov@ru.mvista.com>
Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
Subject : fb_mmap: circular locking dependency on hibernation
Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
Date : 2009-01-27 18:37 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
Handled-By : Andrea Righi <righi.andrea@gmail.com>
Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
Subject : swsusp cannot find resume device (sometimes)
Submitter : Rafael J. Wysocki <rjw@sisk.pl>
Date : 2009-01-09 12:24 (31 days old)
References : http://marc.info/?l=linux-kernel&m=123150395731165&w=4
Handled-By : Arjan van de Ven <arjan@infradead.org>
Patch : http://marc.info/?l=linux-kernel&m=123156441218358&w=4
http://marc.info/?t=123156453100002&r=1&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Handled-By : Roland Dreier <rolandd@cisco.com>
Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12441
Subject : Xorg can't use dri on radeon X1950 AGP
Submitter : Daniel Vetter <daniel@ffwll.ch>
Date : 2009-01-13 05:20 (27 days old)
Handled-By : Dave Airlie <airlied@linux.ie>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=20032&action=view
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12415
Subject : WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
Submitter : Christian Borntraeger <borntraeger@de.ibm.com>
Date : 2009-01-05 10:36 (35 days old)
References : http://marc.info/?l=linux-wireless&m=123115178019082&w=4
Handled-By : Reinette Chatre <reinette.chatre@intel.com>
Patch : http://marc.info/?l=linux-wireless&m=123316414222201&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.28,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=12398
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:06 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Date : 2009-01-05 4:13 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?
@ 2009-02-08 19:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
Submitter : Jeff Chua <jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-05 4:13 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12418] Repeated ioctl(4, 0x40046445, ..) loop in glxgears
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Pallipadi, Venkatesh
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12418
Subject : Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Date : 2009-01-07 22:43 (33 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
References : http://marc.info/?l=linux-kernel&m=123136836213319&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12444] X hangs following switch from radeonfb console - Bisected
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Graham Murray
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
Subject : X hangs following switch from radeonfb console - Bisected
Submitter : Graham Murray <graham@gmurray.org.uk>
Date : 2009-01-13 14:03 (27 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12441] Xorg can't use dri on radeon X1950 AGP
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Vetter, Dave Airlie
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12441
Subject : Xorg can't use dri on radeon X1950 AGP
Submitter : Daniel Vetter <daniel@ffwll.ch>
Date : 2009-01-13 05:20 (27 days old)
Handled-By : Dave Airlie <airlied@linux.ie>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=20032&action=view
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christian Borntraeger, Reinette Chatre,
Tomas Winkler
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12415
Subject : WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
Submitter : Christian Borntraeger <borntraeger@de.ibm.com>
Date : 2009-01-05 10:36 (35 days old)
References : http://marc.info/?l=linux-wireless&m=123115178019082&w=4
Handled-By : Reinette Chatre <reinette.chatre@intel.com>
Patch : http://marc.info/?l=linux-wireless&m=123316414222201&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12419] possible circular locking dependency on i915 dma
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Wang Chen
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
Subject : possible circular locking dependency on i915 dma
Submitter : Wang Chen <wangchen@cn.fujitsu.com>
Date : 2009-01-08 14:11 (32 days old)
References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12490] ath5k related kernel panic in 2.6.29-rc1
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Sergey S. Kostyliov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By : Bob Copeland <me@bobcopeland.com>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12491] i915 lockdep warning
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Brandeburg, Jesse, Roland Dreier
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Handled-By : Roland Dreier <rolandd@cisco.com>
Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12418] Repeated ioctl(4, 0x40046445, ..) loop in glxgears
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Pallipadi, Venkatesh
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12418
Subject : Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter : Pallipadi, Venkatesh <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-01-07 22:43 (33 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
References : http://marc.info/?l=linux-kernel&m=123136836213319&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12444] X hangs following switch from radeonfb console - Bisected
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Graham Murray
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
Subject : X hangs following switch from radeonfb console - Bisected
Submitter : Graham Murray <graham-0mDQKtL6jrwDXYZnReoRVg@public.gmane.org>
Date : 2009-01-13 14:03 (27 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12441] Xorg can't use dri on radeon X1950 AGP
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Vetter, Dave Airlie
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12441
Subject : Xorg can't use dri on radeon X1950 AGP
Submitter : Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Date : 2009-01-13 05:20 (27 days old)
Handled-By : Dave Airlie <airlied-cv59FeDIM0c@public.gmane.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=20032&action=view
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12419] possible circular locking dependency on i915 dma
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Wang Chen
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
Subject : possible circular locking dependency on i915 dma
Submitter : Wang Chen <wangchen-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date : 2009-01-08 14:11 (32 days old)
References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christian Borntraeger, Reinette Chatre,
Tomas Winkler
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12415
Subject : WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
Submitter : Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Date : 2009-01-05 10:36 (35 days old)
References : http://marc.info/?l=linux-wireless&m=123115178019082&w=4
Handled-By : Reinette Chatre <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Patch : http://marc.info/?l=linux-wireless&m=123316414222201&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12491] i915 lockdep warning
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Brandeburg, Jesse, Roland Dreier
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Handled-By : Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12490] ath5k related kernel panic in 2.6.29-rc1
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Sergey S. Kostyliov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-12 7:38 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By : Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12496] swsusp cannot find resume device (sometimes)
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arjan van de Ven, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
Subject : swsusp cannot find resume device (sometimes)
Submitter : Rafael J. Wysocki <rjw@sisk.pl>
Date : 2009-01-09 12:24 (31 days old)
References : http://marc.info/?l=linux-kernel&m=123150395731165&w=4
Handled-By : Arjan van de Ven <arjan@infradead.org>
Patch : http://marc.info/?l=linux-kernel&m=123156441218358&w=4
http://marc.info/?t=123156453100002&r=1&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12497] new barrier warnings in 2.6.29-rc1
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christoph Hellwig, Jens Axboe, Tejun Heo
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12497
Subject : new barrier warnings in 2.6.29-rc1
Submitter : Christoph Hellwig <hch@lst.de>
Date : 2009-01-12 15:46 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123177528217154&w=4
Handled-By : Jens Axboe <jens.axboe@oracle.com>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12494] Sony backlight regression from 2.6.28 to 29-rc
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Mattia Dongili, Norbert Preining
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12494
Subject : Sony backlight regression from 2.6.28 to 29-rc
Submitter : Norbert Preining <preining@logic.at>
Date : 2009-01-19 8:14 (21 days old)
References : http://marc.info/?l=linux-acpi&m=123235286829512&w=4
Handled-By : Mattia Dongili <malattia@linux.it>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arjan van de Ven, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
Subject : swsusp cannot find resume device (sometimes)
Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Date : 2009-01-09 12:24 (31 days old)
References : http://marc.info/?l=linux-kernel&m=123150395731165&w=4
Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123156441218358&w=4
http://marc.info/?t=123156453100002&r=1&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12497] new barrier warnings in 2.6.29-rc1
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christoph Hellwig, Jens Axboe, Tejun Heo
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12497
Subject : new barrier warnings in 2.6.29-rc1
Submitter : Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Date : 2009-01-12 15:46 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123177528217154&w=4
Handled-By : Jens Axboe <jens.axboe-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12494] Sony backlight regression from 2.6.28 to 29-rc
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Mattia Dongili, Norbert Preining
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12494
Subject : Sony backlight regression from 2.6.28 to 29-rc
Submitter : Norbert Preining <preining-DX+603jRYB8@public.gmane.org>
Date : 2009-01-19 8:14 (21 days old)
References : http://marc.info/?l=linux-acpi&m=123235286829512&w=4
Handled-By : Mattia Dongili <malattia-k2GhghHVRtY@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12502] pipe_read oops on sh
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Adrian McMenamin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12502
Subject : pipe_read oops on sh
Submitter : Adrian McMenamin <lkmladrian@gmail.com>
Date : 2009-01-15 9:48 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123201298005600&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Howells, Ingo Molnar, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
Subject : [slab corruption] BUG key_jar: Poison overwritten
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-01-15 18:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
Handled-By : David Howells <dhowells@redhat.com>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12499] Problem with using bluetooth adaper connected to usb port
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-01-13 18:34 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12501] build bug in eeepc-laptop.c
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Matthew Garrett
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12501
Subject : build bug in eeepc-laptop.c
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-01-14 17:25 (26 days old)
References : http://lkml.org/lkml/2009/1/14/315
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12499] Problem with using bluetooth adaper connected to usb port
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 18:34 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12502] pipe_read oops on sh
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Adrian McMenamin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12502
Subject : pipe_read oops on sh
Submitter : Adrian McMenamin <lkmladrian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-15 9:48 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123201298005600&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Howells, Ingo Molnar, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
Subject : [slab corruption] BUG key_jar: Poison overwritten
Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date : 2009-01-15 18:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
Handled-By : David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12501] build bug in eeepc-laptop.c
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Matthew Garrett
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12501
Subject : build bug in eeepc-laptop.c
Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date : 2009-01-14 17:25 (26 days old)
References : http://lkml.org/lkml/2009/1/14/315
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Mikael Pettersson
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12508
Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2009-01-17 22:46 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
References : http://marc.info/?l=linux-kernel&m=123223247325452&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12510] 2.6.29-rc2 dies on startup
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ferenc Wagner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12510
Subject : 2.6.29-rc2 dies on startup
Submitter : Ferenc Wagner <wferi@niif.hu>
Date : 2009-01-19 12:53 (21 days old)
References : http://marc.info/?l=linux-kernel&m=123236969321703&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12551] end_request: I/O error, dev cciss/c0d0, sector 87435720
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12551
Subject : end_request: I/O error, dev cciss/c0d0, sector 87435720
Submitter : Ralf Hildebrandt <ralf.hildebrandt@charite.de>
Date : 2009-01-27 06:51 (13 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12571] Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ross Boswell
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12571
Subject : Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
Submitter : Ross Boswell <drb@med.co.nz>
Date : 2009-01-29 03:46 (11 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Mikael Pettersson
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12508
Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date : 2009-01-17 22:46 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
References : http://marc.info/?l=linux-kernel&m=123223247325452&w=4
Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12551] end_request: I/O error, dev cciss/c0d0, sector 87435720
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12551
Subject : end_request: I/O error, dev cciss/c0d0, sector 87435720
Submitter : Ralf Hildebrandt <ralf.hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
Date : 2009-01-27 06:51 (13 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12510] 2.6.29-rc2 dies on startup
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ferenc Wagner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12510
Subject : 2.6.29-rc2 dies on startup
Submitter : Ferenc Wagner <wferi-eEbw3PyuezQ@public.gmane.org>
Date : 2009-01-19 12:53 (21 days old)
References : http://marc.info/?l=linux-kernel&m=123236969321703&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12571] Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ross Boswell
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12571
Subject : Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
Submitter : Ross Boswell <drb-KpQn0vuWxAmlVyrhU4qvOw@public.gmane.org>
Date : 2009-01-29 03:46 (11 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12574] possible circular locking dependency detected
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Michael S. Tsirkin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-01-29 11:35 (11 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12600] i915 lockdep warning
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Brandeburg, Jesse
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Jan Kara, Linus Torvalds,
Nick Piggin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
Submitter : Jan Kara <jack@suse.cz>
Date : 2009-01-30 1:23 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12574] possible circular locking dependency detected
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Michael S. Tsirkin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-29 11:35 (11 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12600] i915 lockdep warning
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Brandeburg, Jesse
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Jan Kara, Linus Torvalds,
Nick Piggin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Date : 2009-01-30 1:23 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12606] fb_mmap: circular locking dependency on hibernation
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrea Righi, Andrey Borzenkov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
Subject : fb_mmap: circular locking dependency on hibernation
Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
Date : 2009-01-27 18:37 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
Handled-By : Andrea Righi <righi.andrea@gmail.com>
Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Hugh Dickins, Jesse Barnes
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh@veritas.com>
Date : 2009-01-21 21:12 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Cox, Hugh Dickins, Larry Finger,
Mikael Pettersson, Sergei Shtylyov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
Subject : v2.6.29-rc2 libata sff 32bit PIO regression
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-01-23 23:52 (17 days old)
References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
http://marc.info/?l=linux-kernel&m=123254501314058&w=4
Handled-By : Mikael Pettersson <mikpe@it.uu.se>
Hugh Dickins <hugh@veritas.com>
Sergei Shtylyov <sshtylyov@ru.mvista.com>
Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12610] sync-Regression in 2.6.28.2?
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Federico Cuello, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12610
Subject : sync-Regression in 2.6.28.2?
Submitter : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date : 2009-01-27 9:35 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123304977706620&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Hugh Dickins, Jesse Barnes
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Date : 2009-01-21 21:12 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12610] sync-Regression in 2.6.28.2?
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Federico Cuello, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12610
Subject : sync-Regression in 2.6.28.2?
Submitter : Ralf Hildebrandt <Ralf.Hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
Date : 2009-01-27 9:35 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123304977706620&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Cox, Hugh Dickins, Larry Finger,
Mikael Pettersson, Sergei Shtylyov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
Subject : v2.6.29-rc2 libata sff 32bit PIO regression
Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date : 2009-01-23 23:52 (17 days old)
References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
http://marc.info/?l=linux-kernel&m=123254501314058&w=4
Handled-By : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Sergei Shtylyov <sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrea Righi, Andrey Borzenkov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
Subject : fb_mmap: circular locking dependency on hibernation
Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
Date : 2009-01-27 18:37 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
Handled-By : Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12613] [Suspend regression][DRM, RADEON]
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Dave Airlie, etienne,
Soeren Sonnenburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
Subject : [Suspend regression][DRM, RADEON]
Submitter : etienne <etienne.basset@numericable.fr>
Date : 2009-01-28 22:00 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
http://marc.info/?l=linux-kernel&m=123334865404574&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12615] boot hangs while bringing up gianfar ethernet
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ira Snyder, Peter Korsgaard
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12615
Subject : boot hangs while bringing up gianfar ethernet
Submitter : Ira Snyder <iws@ovro.caltech.edu>
Date : 2009-01-29 19:41 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123325817201665&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12617] unable to compile e100 firmware into kernel
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrey Borzenkov, David Woodhouse, Jesse Brandeburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12617
Subject : unable to compile e100 firmware into kernel
Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
Date : 2009-01-31 15:59 (9 days old)
References : http://marc.info/?l=linux-kernel&m=123341764915181&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Dave Airlie, etienne,
Soeren Sonnenburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
Subject : [Suspend regression][DRM, RADEON]
Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date : 2009-01-28 22:00 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
http://marc.info/?l=linux-kernel&m=123334865404574&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12617] unable to compile e100 firmware into kernel
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrey Borzenkov, David Woodhouse, Jesse Brandeburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12617
Subject : unable to compile e100 firmware into kernel
Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
Date : 2009-01-31 15:59 (9 days old)
References : http://marc.info/?l=linux-kernel&m=123341764915181&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12615] boot hangs while bringing up gianfar ethernet
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ira Snyder, Peter Korsgaard
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12615
Subject : boot hangs while bringing up gianfar ethernet
Submitter : Ira Snyder <iws-lulEs6mt1IksTUYHLfqkUA@public.gmane.org>
Date : 2009-01-29 19:41 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123325817201665&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12618] hackbench [pthread mode] regression with 2.6.29-rc3
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Peter Zijlstra, Zhang, Yanmin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12618
Subject : hackbench [pthread mode] regression with 2.6.29-rc3
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-02-01 7:30 (8 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=490dea45d00f01847ebebd007685d564aaf2cd98
References : http://marc.info/?l=linux-kernel&m=123347347726527&w=4
Handled-By : Peter Zijlstra <peterz@infradead.org>
Patch : http://marc.info/?l=linux-kernel&m=123383366122146&w=4
http://marc.info/?l=linux-kernel&m=123383366222152&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12650] Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Damien Wyart
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12650
Subject : Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
Submitter : Damien Wyart <damien.wyart@free.fr>
Date : 2009-01-20 16:25 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123246937207675&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12649] Early crash with 2.6.29-rc3
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andrew McMillan, Len Brown
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12649
Subject : Early crash with 2.6.29-rc3
Submitter : Andrew McMillan <andrew@morphoss.com>
Date : 2009-02-04 20:03 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123377840816097&w=4
Handled-By : Len Brown <lenb@kernel.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12656] iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alex Riesen, Reinette Chatre
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12656
Subject : iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
Submitter : Alex Riesen <fork0@users.sf.net>
Date : 2009-02-08 01:52 (1 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12656] iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alex Riesen, Reinette Chatre
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12656
Subject : iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
Submitter : Alex Riesen <fork0-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org>
Date : 2009-02-08 01:52 (1 days old)
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12618] hackbench [pthread mode] regression with 2.6.29-rc3
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Peter Zijlstra, Zhang, Yanmin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12618
Subject : hackbench [pthread mode] regression with 2.6.29-rc3
Submitter : Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date : 2009-02-01 7:30 (8 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=490dea45d00f01847ebebd007685d564aaf2cd98
References : http://marc.info/?l=linux-kernel&m=123347347726527&w=4
Handled-By : Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123383366122146&w=4
http://marc.info/?l=linux-kernel&m=123383366222152&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12650] Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Damien Wyart
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12650
Subject : Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
Submitter : Damien Wyart <damien.wyart-GANU6spQydw@public.gmane.org>
Date : 2009-01-20 16:25 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123246937207675&w=2
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12649] Early crash with 2.6.29-rc3
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andrew McMillan, Len Brown
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12649
Subject : Early crash with 2.6.29-rc3
Submitter : Andrew McMillan <andrew-xbaEBkN4YytWk0Htik3J/w@public.gmane.org>
Date : 2009-02-04 20:03 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123377840816097&w=4
Handled-By : Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12659] Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List,
2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash
drives, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12659
Subject : Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
Submitter : 2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash drives
Date : 2009-02-03 4:58 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123363718614763&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12660] Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Mathieu Desnoyers
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12660
Subject : Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-02-04 21:11 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123378196022258&w=4
Handled-By : Ingo Molnar <mingo@elte.hu>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David S. Miller, Herbert Xu, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12661
Subject : commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Date : 2009-02-05 14:41 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ff3b938ec6782e6585a83d5459b98b0c3f6eb8
References : http://marc.info/?l=linux-kernel&m=123384496107361&w=4
Handled-By : Herbert Xu <herbert@gondor.apana.org.au>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David S. Miller, Herbert Xu, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12661
Subject : commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
Submitter : Jeff Chua <jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-05 14:41 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ff3b938ec6782e6585a83d5459b98b0c3f6eb8
References : http://marc.info/?l=linux-kernel&m=123384496107361&w=4
Handled-By : Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12660] Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Mathieu Desnoyers
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12660
Subject : Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
Submitter : Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
Date : 2009-02-04 21:11 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123378196022258&w=4
Handled-By : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12659] Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List,
2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash
drives, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12659
Subject : Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
Submitter : 2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash drives
Date : 2009-02-03 4:58 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123363718614763&w=4
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12662] linux 2.6.29-rc3 kernel failure with mptsas
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Morten P.D. Stevens
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12662
Subject : linux 2.6.29-rc3 kernel failure with mptsas
Submitter : Morten P.D. Stevens <mstevens@win-professional.com>
Date : 2009-02-05 22:29 (4 days old)
References : http://marc.info/?l=linux-kernel&m=123387302729741&w=4
Handled-By : Andrew Morton <akpm@linux-foundation.org>
Patch : http://marc.info/?l=linux-kernel&m=123396429501103&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12662] linux 2.6.29-rc3 kernel failure with mptsas
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Morten P.D. Stevens
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12662
Subject : linux 2.6.29-rc3 kernel failure with mptsas
Submitter : Morten P.D. Stevens <mstevens-APqb+XXLJz/QQQFqJy/XgFaTQe2KTcn/@public.gmane.org>
Date : 2009-02-05 22:29 (4 days old)
References : http://marc.info/?l=linux-kernel&m=123387302729741&w=4
Handled-By : Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123396429501103&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12663] Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Brian Gerst, Jiri Slaby
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12663
Subject : Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
Submitter : Jiri Slaby <jirislaby@gmail.com>
Date : 2009-02-07 18:40 (2 days old)
References : http://lkml.org/lkml/2009/2/7/100
Handled-By : Brian Gerst <brgerst@gmail.com>
Patch : http://lkml.org/lkml/2009/2/7/100
http://lkml.org/lkml/2009/2/8/59
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexey Dobriyan, wixor
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12664
Subject : viafb triggers BUG at mm/vmalloc.c:294
Submitter : wixor <wixorpeek@gmail.com>
Date : 2009-02-07 19:44 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123403591109515&w=4
Handled-By : Alexey Dobriyan <adobriyan@gmail.com>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12666] Build failure with latest -git: btrfs on ppc64
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Chuck Ebbert, Kyle McMartin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
Subject : Build failure with latest -git: btrfs on ppc64
Submitter : Chuck Ebbert <cebbert@redhat.com>
Date : 2009-02-07 20:50 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Paul Collins, Thomas Gleixner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <paul@burly.ondioline.org>
Date : 2009-01-21 7:15 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12668] USB flash disk surprise disconnect
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject : USB flash disk surprise disconnect
Submitter : Vegard Nossum <vegard.nossum@gmail.com>
Date : 2009-02-08 10:21 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Chuck Ebbert, Kyle McMartin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
Subject : Build failure with latest -git: btrfs on ppc64
Submitter : Chuck Ebbert <cebbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2009-02-07 20:50 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12663] Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Brian Gerst, Jiri Slaby
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12663
Subject : Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
Submitter : Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-07 18:40 (2 days old)
References : http://lkml.org/lkml/2009/2/7/100
Handled-By : Brian Gerst <brgerst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://lkml.org/lkml/2009/2/7/100
http://lkml.org/lkml/2009/2/8/59
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexey Dobriyan, wixor
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12664
Subject : viafb triggers BUG at mm/vmalloc.c:294
Submitter : wixor <wixorpeek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-07 19:44 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123403591109515&w=4
Handled-By : Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12668] USB flash disk surprise disconnect
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject : USB flash disk surprise disconnect
Submitter : Vegard Nossum <vegard.nossum-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-08 10:21 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Paul Collins, Thomas Gleixner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
Date : 2009-01-21 7:15 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12670] BUG: unable to handle kernel paging request at pin_to_kill+0x21
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alessandro Bono
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject : BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter : Alessandro Bono <alessandro.bono@gmail.com>
Date : 2009-02-08 11:04 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409113223833&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12669] 2.6.28.4 regression: mmap fails if mlockall used
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Hugh Dickins, Sami Farin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
Subject : 2.6.28.4 regression: mmap fails if mlockall used
Submitter : Sami Farin <safari-kernel@safari.iki.fi>
Date : 2009-02-08 10:52 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12671] uvc_status_cleanup(): undefined reference to `input_unregister_device'
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ingo Molnar
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject : uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-02-08 14:58 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123410529909318&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12670] BUG: unable to handle kernel paging request at pin_to_kill+0x21
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alessandro Bono
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject : BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter : Alessandro Bono <alessandro.bono-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-08 11:04 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409113223833&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12671] uvc_status_cleanup(): undefined reference to `input_unregister_device'
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ingo Molnar
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject : uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date : 2009-02-08 14:58 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123410529909318&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12669] 2.6.28.4 regression: mmap fails if mlockall used
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Hugh Dickins, Sami Farin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
Subject : 2.6.28.4 regression: mmap fails if mlockall used
Submitter : Sami Farin <safari-kernel-nmB1AuG+Lnw9NyIDpsMsJw@public.gmane.org>
Date : 2009-02-08 10:52 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 21:53 ` Kyle McMartin
-1 siblings, 0 replies; 243+ messages in thread
From: Kyle McMartin @ 2009-02-08 21:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Chuck Ebbert,
Kyle McMartin
On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> Subject : Build failure with latest -git: btrfs on ppc64
> Submitter : Chuck Ebbert <cebbert@redhat.com>
> Date : 2009-02-07 20:50 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
>
Just fyi, patch here:
Subject: x86: spinlocks: define dummy __raw_spin_is_contended
Date: Sun, 8 Feb 2009 13:03:41 -0500
Message-ID: <20090208180341.GC11398@bombadil.infradead.org>
cheers, Kyle
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-08 21:53 ` Kyle McMartin
0 siblings, 0 replies; 243+ messages in thread
From: Kyle McMartin @ 2009-02-08 21:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Chuck Ebbert,
Kyle McMartin
On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> Subject : Build failure with latest -git: btrfs on ppc64
> Submitter : Chuck Ebbert <cebbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date : 2009-02-07 20:50 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
>
Just fyi, patch here:
Subject: x86: spinlocks: define dummy __raw_spin_is_contended
Date: Sun, 8 Feb 2009 13:03:41 -0500
Message-ID: <20090208180341.GC11398-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
cheers, Kyle
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
` (45 preceding siblings ...)
2009-02-08 21:55 ` 2.6.29-rc4: Reported regressions from 2.6.28 Linus Torvalds
@ 2009-02-08 21:55 ` Linus Torvalds
2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-02-08 21:57 ` [linux-pm] " Alan Stern
2009-02-09 7:36 ` Stefan Richter
48 siblings, 2 replies; 243+ messages in thread
From: Linus Torvalds @ 2009-02-08 21:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> Subject : 2.6.28.4 regression: mmap fails if mlockall used
> Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> Date : 2009-02-08 10:52 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Oh, Hugh just sent a patch, and it's now commit
d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
something like 20 minutes..
Linus
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
` (44 preceding siblings ...)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 21:55 ` Linus Torvalds
2009-02-08 21:55 ` Linus Torvalds
` (2 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2009-02-08 21:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Adrian Bunk, Linux SCSI List, Network Development,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linux PM List
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> Subject : 2.6.28.4 regression: mmap fails if mlockall used
> Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> Date : 2009-02-08 10:52 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Oh, Hugh just sent a patch, and it's now commit
d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
something like 20 minutes..
Linus
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [linux-pm] 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
` (46 preceding siblings ...)
2009-02-08 21:55 ` Linus Torvalds
@ 2009-02-08 21:57 ` Alan Stern
2009-02-09 0:43 ` Rafael J. Wysocki
2009-02-09 7:36 ` Stefan Richter
48 siblings, 1 reply; 243+ messages in thread
From: Alan Stern @ 2009-02-08 21:57 UTC (permalink / raw)
To: Vegard Nossum, Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Natalie Protasevich
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
> Subject : USB flash disk surprise disconnect
> Submitter : Vegard Nossum <vegard.nossum@gmail.com>
> Date : 2009-02-08 10:21 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
Is there any reason to think this is a regression rather than a
one-time fluke?
If it really is a regression, additional debugging info would help.
The log excerpt in the email report doesn't show anything that happened
prior to the disconnect.
Alan Stern
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 22:00 ` Andrea Righi
-1 siblings, 0 replies; 243+ messages in thread
From: Andrea Righi @ 2009-02-08 22:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> Subject : fb_mmap: circular locking dependency on hibernation
> Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
> Date : 2009-01-27 18:37 (13 days old)
> References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> Handled-By : Andrea Righi <righi.andrea@gmail.com>
> Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
This is fixed by:
commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
Author: Andrea Righi <righi.andrea@gmail.com>
Date: Wed Feb 4 15:12:03 2009 -0800
fbmem: don't call copy_from/to_user() with mutex held
Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem
ioctl().
fb_mmap() is called under mm->mmap_sem (A) held, that also acquires
fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does
copy_from/to_user() that might acquire mm->mmap_sem (A), causing a
deadlock.
NOTE: it doesn't push down the fb_info->lock in each own driver's
fb_ioctl(), so there are still potential deadlocks elsewhere.
Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Cc: Dave Jones <davej@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Johannes Weiner <hannes@saeurebad.de>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 22:00 ` Andrea Righi
0 siblings, 0 replies; 243+ messages in thread
From: Andrea Righi @ 2009-02-08 22:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> Subject : fb_mmap: circular locking dependency on hibernation
> Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
> Date : 2009-01-27 18:37 (13 days old)
> References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> Handled-By : Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
This is fixed by:
commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
Author: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed Feb 4 15:12:03 2009 -0800
fbmem: don't call copy_from/to_user() with mutex held
Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem
ioctl().
fb_mmap() is called under mm->mmap_sem (A) held, that also acquires
fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does
copy_from/to_user() that might acquire mm->mmap_sem (A), causing a
deadlock.
NOTE: it doesn't push down the fb_info->lock in each own driver's
fb_ioctl(), so there are still potential deadlocks elsewhere.
Signed-off-by: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>
Cc: Johannes Weiner <hannes-BfM5BwqdGSkPyMaTEpOvjQ@public.gmane.org>
Cc: Krzysztof Helt <krzysztof.h1-5tc4TXWwyLM@public.gmane.org>
Cc: Harvey Harrison <harvey.harrison-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stefan Richter <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 21:55 ` Linus Torvalds
@ 2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
1 sibling, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List
On Sunday 08 February 2009, Linus Torvalds wrote:
>
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> > Subject : 2.6.28.4 regression: mmap fails if mlockall used
> > Submitter : Sami Farin <safari-kernel-nmB1AuG+Lnw9NyIDpsMsJw@public.gmane.org>
> > Date : 2009-02-08 10:52 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
>
> Oh, Hugh just sent a patch, and it's now commit
> d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
> something like 20 minutes..
Yes, I saw the Hugh's message right after sending the report.
Bug closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
@ 2009-02-08 22:04 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List
On Sunday 08 February 2009, Linus Torvalds wrote:
>
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> > Subject : 2.6.28.4 regression: mmap fails if mlockall used
> > Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> > Date : 2009-02-08 10:52 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
>
> Oh, Hugh just sent a patch, and it's now commit
> d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
> something like 20 minutes..
Yes, I saw the Hugh's message right after sending the report.
Bug closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 21:55 ` Linus Torvalds
@ 2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
1 sibling, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Adrian Bunk, Linux SCSI List, Network Development,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linux PM List
On Sunday 08 February 2009, Linus Torvalds wrote:
>
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> > Subject : 2.6.28.4 regression: mmap fails if mlockall used
> > Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> > Date : 2009-02-08 10:52 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
>
> Oh, Hugh just sent a patch, and it's now commit
> d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
> something like 20 minutes..
Yes, I saw the Hugh's message right after sending the report.
Bug closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 22:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:06 UTC (permalink / raw)
To: righi.andrea
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On Sunday 08 February 2009, Andrea Righi wrote:
> On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> > Subject : fb_mmap: circular locking dependency on hibernation
> > Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
> > Date : 2009-01-27 18:37 (13 days old)
> > References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> > Handled-By : Andrea Righi <righi.andrea@gmail.com>
> > Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
>
> This is fixed by:
>
> commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
> Author: Andrea Righi <righi.andrea@gmail.com>
> Date: Wed Feb 4 15:12:03 2009 -0800
>
> fbmem: don't call copy_from/to_user() with mutex held
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 22:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:06 UTC (permalink / raw)
To: righi.andrea-Re5JQEeQqe8AvxtiuMwx3w
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On Sunday 08 February 2009, Andrea Righi wrote:
> On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> > Subject : fb_mmap: circular locking dependency on hibernation
> > Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
> > Date : 2009-01-27 18:37 (13 days old)
> > References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> > Handled-By : Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
>
> This is fixed by:
>
> commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
> Author: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed Feb 4 15:12:03 2009 -0800
>
> fbmem: don't call copy_from/to_user() with mutex held
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 22:07 ` etienne
-1 siblings, 0 replies; 243+ messages in thread
From: etienne @ 2009-02-08 22:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Dave Airlie, Soeren Sonnenburg
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> Subject : [Suspend regression][DRM, RADEON]
> Submitter : etienne <etienne.basset@numericable.fr>
> Date : 2009-01-28 22:00 (12 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>
>
>
hello,
yes it's still present in -rc4
But I noticed that when I switch off KDE4.2 desktop effects, suspend to
ram is 100% reliable with 2.6.29-rc4
With 2.6.28, STR is 100% reliable with or without desktop effects
hope this helps,
Etienne
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 22:07 ` etienne
0 siblings, 0 replies; 243+ messages in thread
From: etienne @ 2009-02-08 22:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Dave Airlie, Soeren Sonnenburg
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> Subject : [Suspend regression][DRM, RADEON]
> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> Date : 2009-01-28 22:00 (12 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>
>
>
hello,
yes it's still present in -rc4
But I noticed that when I switch off KDE4.2 desktop effects, suspend to
ram is 100% reliable with 2.6.29-rc4
With 2.6.28, STR is 100% reliable with or without desktop effects
hope this helps,
Etienne
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
2009-02-08 21:53 ` Kyle McMartin
(?)
@ 2009-02-08 22:08 ` Rafael J. Wysocki
2009-02-10 20:00 ` Chuck Ebbert
-1 siblings, 1 reply; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:08 UTC (permalink / raw)
To: Kyle McMartin
Cc: Linux Kernel Mailing List, Kernel Testers List, Chuck Ebbert
On Sunday 08 February 2009, Kyle McMartin wrote:
> On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> > Subject : Build failure with latest -git: btrfs on ppc64
> > Submitter : Chuck Ebbert <cebbert@redhat.com>
> > Date : 2009-02-07 20:50 (2 days old)
> > References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
> >
>
> Just fyi, patch here:
> Subject: x86: spinlocks: define dummy __raw_spin_is_contended
> Date: Sun, 8 Feb 2009 13:03:41 -0500
> Message-ID: <20090208180341.GC11398@bombadil.infradead.org>
Thanks, updated the bug entry with this patch.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 22:11 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:11 UTC (permalink / raw)
To: etienne
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Soeren Sonnenburg, Benjamin Herrenschmidt
On Sunday 08 February 2009, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset@numericable.fr>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 22:11 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:11 UTC (permalink / raw)
To: etienne
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Soeren Sonnenburg, Benjamin Herrenschmidt
On Sunday 08 February 2009, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 22:12 ` Ingo Molnar
-1 siblings, 0 replies; 243+ messages in thread
From: Ingo Molnar @ 2009-02-08 22:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
* Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> Subject : [slab corruption] BUG key_jar: Poison overwritten
> Submitter : Ingo Molnar <mingo@elte.hu>
> Date : 2009-01-15 18:16 (25 days old)
> References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> Handled-By : David Howells <dhowells@redhat.com>
This slab corruption has not triggered again. It's either a very rare thing (in
which case there's no realistic way to debug it via this angle), or it got fixed
meanwhile.
Please close it. Thanks,
Ingo
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-08 22:12 ` Ingo Molnar
0 siblings, 0 replies; 243+ messages in thread
From: Ingo Molnar @ 2009-02-08 22:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
* Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> Subject : [slab corruption] BUG key_jar: Poison overwritten
> Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> Date : 2009-01-15 18:16 (25 days old)
> References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> Handled-By : David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
This slab corruption has not triggered again. It's either a very rare thing (in
which case there's no realistic way to debug it via this angle), or it got fixed
meanwhile.
Please close it. Thanks,
Ingo
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 23:38 ` Mikael Pettersson
-1 siblings, 0 replies; 243+ messages in thread
From: Mikael Pettersson @ 2009-02-08 23:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Mikael Pettersson
Rafael J. Wysocki wrote:
>This message has been generated automatically as a part of a report
>of recent regressions.
>
>The following bug entry is on the current list of known regressions
>from 2.6.28. Please verify if it still should be listed and let me know
>(either way).
>
>
>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
>Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
>Submitter : Mikael Pettersson <mikpe@it.uu.se>
>Date : 2009-01-17 22:46 (23 days old)
>First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
>x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
>References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
>Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Fixed in 2.6.29-rc4.
See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-08 23:38 ` Mikael Pettersson
0 siblings, 0 replies; 243+ messages in thread
From: Mikael Pettersson @ 2009-02-08 23:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Mikael Pettersson
Rafael J. Wysocki wrote:
>This message has been generated automatically as a part of a report
>of recent regressions.
>
>The following bug entry is on the current list of known regressions
>from 2.6.28. Please verify if it still should be listed and let me know
>(either way).
>
>
>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
>Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
>Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
>Date : 2009-01-17 22:46 (23 days old)
>First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
>x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
>References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
>Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Fixed in 2.6.29-rc4.
See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 0:38 ` Arjan van de Ven
-1 siblings, 0 replies; 243+ messages in thread
From: Arjan van de Ven @ 2009-02-09 0:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki, greg
On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me
> know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> Subject : swsusp cannot find resume device (sometimes)
> Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> Date : 2009-01-09 12:24 (31 days old)
> References :
> http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> Handled-By : Arjan van de Ven <arjan@infradead.org>
> Patch :
> http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> http://marc.info/?t=123156453100002&r=1&w=4
>
>
the patches are in -mm waiting for gregkh to pick them up and push...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 0:38 ` Arjan van de Ven
0 siblings, 0 replies; 243+ messages in thread
From: Arjan van de Ven @ 2009-02-09 0:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, greg-U8xfFu+wG4EAvxtiuMwx3w
On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me
> know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> Subject : swsusp cannot find resume device (sometimes)
> Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> Date : 2009-01-09 12:24 (31 days old)
> References :
> http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Patch :
> http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> http://marc.info/?t=123156453100002&r=1&w=4
>
>
the patches are in -mm waiting for gregkh to pick them up and push...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-09 0:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:39 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt
On Monday 09 February 2009, Mikael Pettersson wrote:
> Rafael J. Wysocki wrote:
> >This message has been generated automatically as a part of a report
> >of recent regressions.
> >
> >The following bug entry is on the current list of known regressions
> >from 2.6.28. Please verify if it still should be listed and let me know
> >(either way).
> >
> >
> >Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
> >Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
> >Submitter : Mikael Pettersson <mikpe@it.uu.se>
> >Date : 2009-01-17 22:46 (23 days old)
> >First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
> >x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
> >References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
> >Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Fixed in 2.6.29-rc4.
Thanks, closed.
> See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
Yes, but I wasn't quite sure if that was a mainline commit or a commit from
the Ben's tree.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-09 0:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:39 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt
On Monday 09 February 2009, Mikael Pettersson wrote:
> Rafael J. Wysocki wrote:
> >This message has been generated automatically as a part of a report
> >of recent regressions.
> >
> >The following bug entry is on the current list of known regressions
> >from 2.6.28. Please verify if it still should be listed and let me know
> >(either way).
> >
> >
> >Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
> >Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
> >Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
> >Date : 2009-01-17 22:46 (23 days old)
> >First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
> >x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
> >References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
> >Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
>
> Fixed in 2.6.29-rc4.
Thanks, closed.
> See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
Yes, but I wasn't quite sure if that was a mainline commit or a commit from
the Ben's tree.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-09 0:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
On Sunday 08 February 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> > Subject : [slab corruption] BUG key_jar: Poison overwritten
> > Submitter : Ingo Molnar <mingo@elte.hu>
> > Date : 2009-01-15 18:16 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> > Handled-By : David Howells <dhowells@redhat.com>
>
> This slab corruption has not triggered again. It's either a very rare thing (in
> which case there's no realistic way to debug it via this angle), or it got fixed
> meanwhile.
>
> Please close it. Thanks,
Closed as "unreproducible".
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-09 0:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
On Sunday 08 February 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> > Subject : [slab corruption] BUG key_jar: Poison overwritten
> > Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> > Date : 2009-01-15 18:16 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> > Handled-By : David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> This slab corruption has not triggered again. It's either a very rare thing (in
> which case there's no realistic way to debug it via this angle), or it got fixed
> meanwhile.
>
> Please close it. Thanks,
Closed as "unreproducible".
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [linux-pm] 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 21:57 ` [linux-pm] " Alan Stern
@ 2009-02-09 0:43 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:43 UTC (permalink / raw)
To: Alan Stern, Vegard Nossum; +Cc: Linux Kernel Mailing List, Natalie Protasevich
On Sunday 08 February 2009, Alan Stern wrote:
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
> > Subject : USB flash disk surprise disconnect
> > Submitter : Vegard Nossum <vegard.nossum@gmail.com>
> > Date : 2009-02-08 10:21 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
>
> Is there any reason to think this is a regression rather than a
> one-time fluke?
Well, Vegard is the right person to ask this question.
I saw the message, so I assumed it was sent as a regression report.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 1:12 ` Roland Dreier
-1 siblings, 0 replies; 243+ messages in thread
From: Roland Dreier @ 2009-02-09 1:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Bob Copeland,
Brandeburg, Jesse
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Looks like a dup of 12491 to me.
- R.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
@ 2009-02-09 1:12 ` Roland Dreier
0 siblings, 0 replies; 243+ messages in thread
From: Roland Dreier @ 2009-02-09 1:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Bob Copeland,
Brandeburg, Jesse
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Looks like a dup of 12491 to me.
- R.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 2:26 ` Dave Airlie
0 siblings, 0 replies; 243+ messages in thread
From: Dave Airlie @ 2009-02-09 2:26 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset@numericable.fr> wrote:
> Rafael J. Wysocki wrote:
>>
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.28. Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>> Subject : [Suspend regression][DRM, RADEON]
>> Submitter : etienne <etienne.basset@numericable.fr>
>> Date : 2009-01-28 22:00 (12 days old)
>> First-Bad-Commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>
>>
>>
>
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
> is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
>
Hi Etienne,
Can you try commenting out the calls to the radeon_suspend and
radeon_resume hooks in radeon_drv.c?
Dave.
> hope this helps,
> Etienne
>
>
>
>
>
>
>
> --
> 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/
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 2:26 ` Dave Airlie
0 siblings, 0 replies; 243+ messages in thread
From: Dave Airlie @ 2009-02-09 2:26 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> Rafael J. Wysocki wrote:
>>
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.28. Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>> Subject : [Suspend regression][DRM, RADEON]
>> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
>> Date : 2009-01-28 22:00 (12 days old)
>> First-Bad-Commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>
>>
>>
>
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
> is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
>
Hi Etienne,
Can you try commenting out the calls to the radeon_suspend and
radeon_resume hooks in radeon_drv.c?
Dave.
> hope this helps,
> Etienne
>
>
>
>
>
>
>
> --
> 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/
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 2:27 ` Greg KH
0 siblings, 0 replies; 243+ messages in thread
From: Greg KH @ 2009-02-09 2:27 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me
> > know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > Subject : swsusp cannot find resume device (sometimes)
> > Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> > Date : 2009-01-09 12:24 (31 days old)
> > References :
> > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > Handled-By : Arjan van de Ven <arjan@infradead.org>
> > Patch :
> > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > http://marc.info/?t=123156453100002&r=1&w=4
> >
> >
>
> the patches are in -mm waiting for gregkh to pick them up and push...
Ok, I'm totally confused now, care to point out exactly which ones I
should be picking up and pushing?
thanks,
greg "i'm slow, humor me" k-h
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 2:27 ` Greg KH
0 siblings, 0 replies; 243+ messages in thread
From: Greg KH @ 2009-02-09 2:27 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me
> > know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > Subject : swsusp cannot find resume device (sometimes)
> > Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> > Date : 2009-01-09 12:24 (31 days old)
> > References :
> > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > Patch :
> > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > http://marc.info/?t=123156453100002&r=1&w=4
> >
> >
>
> the patches are in -mm waiting for gregkh to pick them up and push...
Ok, I'm totally confused now, care to point out exactly which ones I
should be picking up and pushing?
thanks,
greg "i'm slow, humor me" k-h
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 4:23 ` Herbert Xu
-1 siblings, 0 replies; 243+ messages in thread
From: Herbert Xu @ 2009-02-09 4:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
The patch in question has already been reverted. So while we
still need to track down the underlying problem with rlogin, it's
no longer a kernel regression.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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] 243+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-09 4:23 ` Herbert Xu
0 siblings, 0 replies; 243+ messages in thread
From: Herbert Xu @ 2009-02-09 4:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
The patch in question has already been reverted. So while we
still need to track down the underlying problem with rlogin, it's
no longer a kernel regression.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
2009-02-08 22:07 ` etienne
@ 2009-02-09 5:50 ` Soeren Sonnenburg
-1 siblings, 0 replies; 243+ messages in thread
From: Soeren Sonnenburg @ 2009-02-09 5:50 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie
On Sun, 2009-02-08 at 23:07 +0100, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset@numericable.fr>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
For me it is reliable as soon as compositing/dri is disabled on 2.6.29.
On 2.6.28 it worked with compositing/dri *sometimes* - so 2.6.29 is the
first reliable kernel for me (when not using 3d).
Soeren
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 5:50 ` Soeren Sonnenburg
0 siblings, 0 replies; 243+ messages in thread
From: Soeren Sonnenburg @ 2009-02-09 5:50 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie
On Sun, 2009-02-08 at 23:07 +0100, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset@numericable.fr>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
For me it is reliable as soon as compositing/dri is disabled on 2.6.29.
On 2.6.28 it worked with compositing/dri *sometimes* - so 2.6.29 is the
first reliable kernel for me (when not using 3d).
Soeren
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-09 7:36 ` Stefan Richter
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 243+ messages in thread
From: Stefan Richter @ 2009-02-09 7:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Now closed as duplicate of
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
> Handled-By : Roland Dreier <rolandd@cisco.com>
> Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
--
Stefan Richter
-=====-==--= --=- -=--=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
@ 2009-02-09 7:36 ` Stefan Richter
0 siblings, 0 replies; 243+ messages in thread
From: Stefan Richter @ 2009-02-09 7:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Now closed as duplicate of
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
> Handled-By : Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
--
Stefan Richter
-=====-==--= --=- -=--=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 7:53 ` Paul Collins
-1 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-09 7:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul@burly.ondioline.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
message was not logged, so it's either gone away or else become much
more difficult to reproduce.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 7:53 ` Paul Collins
0 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-09 7:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
message was not logged, so it's either gone away or else become much
more difficult to reproduce.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 9:18 ` Ingo Molnar
0 siblings, 0 replies; 243+ messages in thread
From: Ingo Molnar @ 2009-02-09 9:18 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Thomas Gleixner
* Paul Collins <paul@burly.ondioline.org> wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul@burly.ondioline.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Various suspend handlers were enabling irqs spuriously - fixed by recent patches in
-rc4. The warning above is consistent with the timekeeping code being surprised with
a premature irqs-enable.
Ingo
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 9:18 ` Ingo Molnar
0 siblings, 0 replies; 243+ messages in thread
From: Ingo Molnar @ 2009-02-09 9:18 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Thomas Gleixner
* Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org> wrote:
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Various suspend handlers were enabling irqs spuriously - fixed by recent patches in
-rc4. The warning above is consistent with the timekeeping code being surprised with
a premature irqs-enable.
Ingo
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:17 ` wixor
-1 siblings, 0 replies; 243+ messages in thread
From: wixor @ 2009-02-09 10:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
There was no support for Chrome9 framebuffer before 2.6.28, so that is
a progress. However now that we have it, it doesn't work (at least for
me).... The BUG appearing seemed to be an mm-issue also reported by
others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
don't know if it was there before 2.6.28. It doesn't look like any
solution has been merged to mainline.
It is certainly an issue, but I'm not sure if it's also a regression
from 2.6.28.
--
wixor
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-09 10:17 ` wixor
0 siblings, 0 replies; 243+ messages in thread
From: wixor @ 2009-02-09 10:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
There was no support for Chrome9 framebuffer before 2.6.28, so that is
a progress. However now that we have it, it doesn't work (at least for
me).... The BUG appearing seemed to be an mm-issue also reported by
others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
don't know if it was there before 2.6.28. It doesn't look like any
solution has been merged to mainline.
It is certainly an issue, but I'm not sure if it's also a regression
from 2.6.28.
--
wixor
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:24 ` Hugh Dickins
-1 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:24 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Jesse Barnes
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
> Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
> Submitter : Hugh Dickins <hugh@veritas.com>
> Date : 2009-01-21 21:12 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
> References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
> Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Please still list it for now, but I expect Ben's fix to be in -rc5.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-09 10:24 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:24 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Jesse Barnes
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
> Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
> Submitter : Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
> Date : 2009-01-21 21:12 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
> References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
> Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Please still list it for now, but I expect Ben's fix to be in -rc5.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:25 ` Hugh Dickins
-1 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alan Cox,
Larry Finger, Mikael Pettersson, Sergei Shtylyov
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
> Subject : v2.6.29-rc2 libata sff 32bit PIO regression
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> Date : 2009-01-23 23:52 (17 days old)
> References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
> http://marc.info/?l=linux-kernel&m=123254501314058&w=4
> Handled-By : Mikael Pettersson <mikpe@it.uu.se>
> Hugh Dickins <hugh@veritas.com>
> Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
Please still list it for now, but I expect Sergei's and Alan's fixes
to be in -rc5.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
@ 2009-02-09 10:25 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alan Cox,
Larry Finger, Mikael Pettersson, Sergei Shtylyov
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
> Subject : v2.6.29-rc2 libata sff 32bit PIO regression
> Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> Date : 2009-01-23 23:52 (17 days old)
> References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
> http://marc.info/?l=linux-kernel&m=123254501314058&w=4
> Handled-By : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
> Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
> Sergei Shtylyov <sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
> Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
Please still list it for now, but I expect Sergei's and Alan's fixes
to be in -rc5.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12669] 2.6.28.4 regression: mmap fails if mlockall used
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:32 ` Hugh Dickins
-1 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Sami Farin
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> Subject : 2.6.28.4 regression: mmap fails if mlockall used
> Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> Date : 2009-02-08 10:52 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Please still list it for now, but I expect
d5b562330ec766292a3ac54ae5e0673610bd5b3d
mm: fix error case in mlock downgrade reversion
(which went in just after -rc4) to have fixed it:
let's wait for confirmation from Sami before removing.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12669] 2.6.28.4 regression: mmap fails if mlockall used
@ 2009-02-09 10:32 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Sami Farin
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> Subject : 2.6.28.4 regression: mmap fails if mlockall used
> Submitter : Sami Farin <safari-kernel-nmB1AuG+Lnw9NyIDpsMsJw@public.gmane.org>
> Date : 2009-02-08 10:52 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Please still list it for now, but I expect
d5b562330ec766292a3ac54ae5e0673610bd5b3d
mm: fix error case in mlock downgrade reversion
(which went in just after -rc4) to have fixed it:
let's wait for confirmation from Sami before removing.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:32 ` Thomas Gleixner
-1 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2009-02-09 10:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Paul Collins
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul@burly.ondioline.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
First bad commit ? The commit adds a WARN_ON to getnstimeofday() when
it is called while timekeeping is suspended. So instead of pointing to
that commit can we please figure out WTF this happens?
Looking at the call stack this is pretty obvious:
[ee4fdc80] [c0053b10] do_gettimeofday+0x1c/0x58
[ee4fdcb0] [c0348868] evdev_event+0x28/0x158
[ee4fdce0] [c0340ce4] input_pass_event+0xac/0xb0
[ee4fdd00] [c0343a44] input_event+0x80/0x98
[ee4fdd20] [c02f6d24] via_pmu_event+0x88/0x8c
[ee4fdd30] [c02f4f60] via_pmu_interrupt+0x6e0/0xb2c
[ee4fdd90] [c02f5664] pmu_wait_complete+0x50/0x84
[ee4fddb0] [c02f6764] powerbook_sleep+0x9f0/0xb24
[ee4fde40] [c00607f8] suspend_devices_and_enter+0x10c/0x180
[ee4fde60] [c0060a1c] enter_state+0x11c/0x160
[ee4fde80] [c02f4404] pmu_ioctl+0x15c/0x24c
[ee4fde90] [c00bab04] vfs_ioctl+0x8c/0x90
[ee4fdea0] [c00babb8] do_vfs_ioctl+0x8c/0x70c
[ee4fdf10] [c00bb2d4] sys_ioctl+0x9c/0xa4
[ee4fdf40] [c0012eb8] ret_from_syscall+0x0/0x38
powerbook_sleep() calls into the event interface which calls
gettimeofday() _AFTER_ timekeeping was suspended already so the
WARN_ON triggers.
Thanks,
tglx
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 10:32 ` Thomas Gleixner
0 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2009-02-09 10:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Paul Collins
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
First bad commit ? The commit adds a WARN_ON to getnstimeofday() when
it is called while timekeeping is suspended. So instead of pointing to
that commit can we please figure out WTF this happens?
Looking at the call stack this is pretty obvious:
[ee4fdc80] [c0053b10] do_gettimeofday+0x1c/0x58
[ee4fdcb0] [c0348868] evdev_event+0x28/0x158
[ee4fdce0] [c0340ce4] input_pass_event+0xac/0xb0
[ee4fdd00] [c0343a44] input_event+0x80/0x98
[ee4fdd20] [c02f6d24] via_pmu_event+0x88/0x8c
[ee4fdd30] [c02f4f60] via_pmu_interrupt+0x6e0/0xb2c
[ee4fdd90] [c02f5664] pmu_wait_complete+0x50/0x84
[ee4fddb0] [c02f6764] powerbook_sleep+0x9f0/0xb24
[ee4fde40] [c00607f8] suspend_devices_and_enter+0x10c/0x180
[ee4fde60] [c0060a1c] enter_state+0x11c/0x160
[ee4fde80] [c02f4404] pmu_ioctl+0x15c/0x24c
[ee4fde90] [c00bab04] vfs_ioctl+0x8c/0x90
[ee4fdea0] [c00babb8] do_vfs_ioctl+0x8c/0x70c
[ee4fdf10] [c00bb2d4] sys_ioctl+0x9c/0xa4
[ee4fdf40] [c0012eb8] ret_from_syscall+0x0/0x38
powerbook_sleep() calls into the event interface which calls
gettimeofday() _AFTER_ timekeeping was suspended already so the
WARN_ON triggers.
Thanks,
tglx
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 13:59 ` Michael S. Tsirkin
-1 siblings, 0 replies; 243+ messages in thread
From: Michael S. Tsirkin @ 2009-02-09 13:59 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
I have verified that this still occurs on 2.6.29-rc4.
On Sun, Feb 8, 2009 at 9:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
> Subject : possible circular locking dependency detected
> Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
> Date : 2009-01-29 11:35 (11 days old)
>
>
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-09 13:59 ` Michael S. Tsirkin
0 siblings, 0 replies; 243+ messages in thread
From: Michael S. Tsirkin @ 2009-02-09 13:59 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
I have verified that this still occurs on 2.6.29-rc4.
On Sun, Feb 8, 2009 at 9:21 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
> Subject : possible circular locking dependency detected
> Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2009-01-29 11:35 (11 days old)
>
>
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
@ 2009-02-09 17:21 ` Bob Copeland
0 siblings, 0 replies; 243+ messages in thread
From: Bob Copeland @ 2009-02-09 17:21 UTC (permalink / raw)
To: Roland Dreier, Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Brandeburg, Jesse
On Sun, 08 Feb 2009 17:12:21 -0800, Roland Dreier wrote
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> > Subject : i915 lockdep warning
> > Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> > Date : 2009-01-13 23:17 (27 days old)
> > References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
>
> Looks like a dup of 12491 to me.
>
> - R.
I can also confirm that Roland's patch fixes it for me.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
@ 2009-02-09 17:21 ` Bob Copeland
0 siblings, 0 replies; 243+ messages in thread
From: Bob Copeland @ 2009-02-09 17:21 UTC (permalink / raw)
To: Roland Dreier, Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Brandeburg, Jesse
On Sun, 08 Feb 2009 17:12:21 -0800, Roland Dreier wrote
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> > Subject : i915 lockdep warning
> > Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Date : 2009-01-13 23:17 (27 days old)
> > References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
>
> Looks like a dup of 12491 to me.
>
> - R.
I can also confirm that Roland's patch fixes it for me.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 18:08 ` etienne
0 siblings, 0 replies; 243+ messages in thread
From: etienne @ 2009-02-09 18:08 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset@numericable.fr> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset@numericable.fr>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I just tested that and I didn't change anything (cannot STR/resume with
desktop effect, STR/resume OK without desktop effects)
thanks,
Etienne
the patch i used, to verify i understood you ;)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon
index fef2078..805b367 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -90,8 +90,8 @@ static struct drm_driver driver = {
.postclose = radeon_driver_postclose,
.lastclose = radeon_driver_lastclose,
.unload = radeon_driver_unload,
- .suspend = radeon_suspend,
- .resume = radeon_resume,
+/* .suspend = radeon_suspend,
+ .resume = radeon_resume, */
.get_vblank_counter = radeon_get_vblank_counter,
.enable_vblank = radeon_enable_vblank,
.disable_vblank = radeon_disable_vblank,
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 18:08 ` etienne
0 siblings, 0 replies; 243+ messages in thread
From: etienne @ 2009-02-09 18:08 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I just tested that and I didn't change anything (cannot STR/resume with
desktop effect, STR/resume OK without desktop effects)
thanks,
Etienne
the patch i used, to verify i understood you ;)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon
index fef2078..805b367 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -90,8 +90,8 @@ static struct drm_driver driver = {
.postclose = radeon_driver_postclose,
.lastclose = radeon_driver_lastclose,
.unload = radeon_driver_unload,
- .suspend = radeon_suspend,
- .resume = radeon_resume,
+/* .suspend = radeon_suspend,
+ .resume = radeon_resume, */
.get_vblank_counter = radeon_get_vblank_counter,
.enable_vblank = radeon_enable_vblank,
.disable_vblank = radeon_disable_vblank,
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 19:31 ` etienne
0 siblings, 0 replies; 243+ messages in thread
From: etienne @ 2009-02-09 19:31 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset@numericable.fr> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset@numericable.fr>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I created the following "shot in the dark" patch that solves my problem!
I looked at the change between 2.6.28 and .29rc, and only the
radeon_cp.c:radeon_cp_init_ring_buffer changes stroke my eyes (cause
it's called by radeon_cp_resume indirectedly)
I don't understand what i did and how this works, but it works for me
regards
Etienne
Signed-off-by: etienne <etienne.basset@numericable.fr>
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 63212d7..fc6e134
100644
---
a/drivers/gpu/drm/radeon/radeon_cp.c
+++
b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -557,7 +557,8 @@ static int radeon_do_engine_reset(struct drm_device
* dev)
}
static void radeon_cp_init_ring_buffer(struct drm_device *
dev,
- drm_radeon_private_t *
dev_priv)
+ drm_radeon_private_t *
dev_priv,
+ struct drm_radeon_master_private
*master)
{
u32 ring_start,
cur_read_ptr;
u32
tmp;
@@ -668,13 +669,13 @@ static void radeon_cp_init_ring_buffer(struct
drm_device *
dev,
RADEON_WRITE(RADEON_BUS_CNTL,
tmp);
} /* PCIE cards appears to not need this
*/
- dev_priv->scratch[0] =
0;
+ master->sarea_priv->last_frame = dev_priv->scratch[0] = 0;
RADEON_WRITE(RADEON_LAST_FRAME_REG, 0);
- dev_priv->scratch[1] = 0;
+ master->sarea_priv->last_dispatch = dev_priv->scratch[1] = 0;
RADEON_WRITE(RADEON_LAST_DISPATCH_REG, 0);
- dev_priv->scratch[2] = 0;
+ master->sarea_priv->last_clear = dev_priv->scratch[2] = 0;
RADEON_WRITE(RADEON_LAST_CLEAR_REG, 0);
radeon_do_wait_for_idle(dev_priv);
@@ -1215,7 +1216,7 @@ static int radeon_do_init_cp(struct drm_device
*dev, drm_radeon_init_t *init,
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
dev_priv->last_buf = 0;
@@ -1281,9 +1282,11 @@ static int radeon_do_cleanup_cp(struct drm_device
* dev)
*
* Charl P. Botha <http://cpbotha.net>
*/
-static int radeon_do_resume_cp(struct drm_device * dev)
+static int radeon_do_resume_cp(struct drm_device * dev,
+ struct drm_file * file_priv)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
+ struct drm_radeon_master_private * master_priv =
file_priv->master->driver_priv;
if (!dev_priv) {
DRM_ERROR("Called with no initialization\n");
@@ -1304,7 +1307,7 @@ static int radeon_do_resume_cp(struct drm_device *
dev)
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
radeon_do_engine_reset(dev);
radeon_irq_set_state(dev, RADEON_SW_INT_ENABLE, 1);
@@ -1480,7 +1483,7 @@ int radeon_cp_idle(struct drm_device *dev, void
*data, struct drm_file *file_pri
int radeon_cp_resume(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
- return radeon_do_resume_cp(dev);
+ return radeon_do_resume_cp(dev, file_priv);
}
int radeon_engine_reset(struct drm_device *dev, void *data, struct
drm_file *file_priv)
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 19:31 ` etienne
0 siblings, 0 replies; 243+ messages in thread
From: etienne @ 2009-02-09 19:31 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I created the following "shot in the dark" patch that solves my problem!
I looked at the change between 2.6.28 and .29rc, and only the
radeon_cp.c:radeon_cp_init_ring_buffer changes stroke my eyes (cause
it's called by radeon_cp_resume indirectedly)
I don't understand what i did and how this works, but it works for me
regards
Etienne
Signed-off-by: etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 63212d7..fc6e134
100644
---
a/drivers/gpu/drm/radeon/radeon_cp.c
+++
b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -557,7 +557,8 @@ static int radeon_do_engine_reset(struct drm_device
* dev)
}
static void radeon_cp_init_ring_buffer(struct drm_device *
dev,
- drm_radeon_private_t *
dev_priv)
+ drm_radeon_private_t *
dev_priv,
+ struct drm_radeon_master_private
*master)
{
u32 ring_start,
cur_read_ptr;
u32
tmp;
@@ -668,13 +669,13 @@ static void radeon_cp_init_ring_buffer(struct
drm_device *
dev,
RADEON_WRITE(RADEON_BUS_CNTL,
tmp);
} /* PCIE cards appears to not need this
*/
- dev_priv->scratch[0] =
0;
+ master->sarea_priv->last_frame = dev_priv->scratch[0] = 0;
RADEON_WRITE(RADEON_LAST_FRAME_REG, 0);
- dev_priv->scratch[1] = 0;
+ master->sarea_priv->last_dispatch = dev_priv->scratch[1] = 0;
RADEON_WRITE(RADEON_LAST_DISPATCH_REG, 0);
- dev_priv->scratch[2] = 0;
+ master->sarea_priv->last_clear = dev_priv->scratch[2] = 0;
RADEON_WRITE(RADEON_LAST_CLEAR_REG, 0);
radeon_do_wait_for_idle(dev_priv);
@@ -1215,7 +1216,7 @@ static int radeon_do_init_cp(struct drm_device
*dev, drm_radeon_init_t *init,
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
dev_priv->last_buf = 0;
@@ -1281,9 +1282,11 @@ static int radeon_do_cleanup_cp(struct drm_device
* dev)
*
* Charl P. Botha <http://cpbotha.net>
*/
-static int radeon_do_resume_cp(struct drm_device * dev)
+static int radeon_do_resume_cp(struct drm_device * dev,
+ struct drm_file * file_priv)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
+ struct drm_radeon_master_private * master_priv =
file_priv->master->driver_priv;
if (!dev_priv) {
DRM_ERROR("Called with no initialization\n");
@@ -1304,7 +1307,7 @@ static int radeon_do_resume_cp(struct drm_device *
dev)
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
radeon_do_engine_reset(dev);
radeon_irq_set_state(dev, RADEON_SW_INT_ENABLE, 1);
@@ -1480,7 +1483,7 @@ int radeon_cp_idle(struct drm_device *dev, void
*data, struct drm_file *file_pri
int radeon_cp_resume(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
- return radeon_do_resume_cp(dev);
+ return radeon_do_resume_cp(dev, file_priv);
}
int radeon_engine_reset(struct drm_device *dev, void *data, struct
drm_file *file_priv)
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 23:46 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 23:46 UTC (permalink / raw)
To: Greg KH
Cc: Arjan van de Ven, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton
On Monday 09 February 2009, Greg KH wrote:
> On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> > On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me
> > > know (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > > Subject : swsusp cannot find resume device (sometimes)
> > > Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> > > Date : 2009-01-09 12:24 (31 days old)
> > > References :
> > > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > > Handled-By : Arjan van de Ven <arjan@infradead.org>
> > > Patch :
> > > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > > http://marc.info/?t=123156453100002&r=1&w=4
> > >
> > >
> >
> > the patches are in -mm waiting for gregkh to pick them up and push...
>
> Ok, I'm totally confused now, care to point out exactly which ones I
> should be picking up and pushing?
Patches from -mm called:
drivers-consolidate-driver_probe_done-loops-into-one-place.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-checkpatch-fixes.patch
resume-wait-for-device-probing-to-finish.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-fix.patch
in this order.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 23:46 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 23:46 UTC (permalink / raw)
To: Greg KH
Cc: Arjan van de Ven, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton
On Monday 09 February 2009, Greg KH wrote:
> On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> > On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me
> > > know (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > > Subject : swsusp cannot find resume device (sometimes)
> > > Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> > > Date : 2009-01-09 12:24 (31 days old)
> > > References :
> > > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > > Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > > Patch :
> > > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > > http://marc.info/?t=123156453100002&r=1&w=4
> > >
> > >
> >
> > the patches are in -mm waiting for gregkh to pick them up and push...
>
> Ok, I'm totally confused now, care to point out exactly which ones I
> should be picking up and pushing?
Patches from -mm called:
drivers-consolidate-driver_probe_done-loops-into-one-place.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-checkpatch-fixes.patch
resume-wait-for-device-probing-to-finish.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-fix.patch
in this order.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-10 16:28 ` Jan Kara
-1 siblings, 0 replies; 243+ messages in thread
From: Jan Kara @ 2009-02-10 16:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
Yes, I've verified with latest git and the regression is still there.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack@suse.cz>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
Honza
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-10 16:28 ` Jan Kara
0 siblings, 0 replies; 243+ messages in thread
From: Jan Kara @ 2009-02-10 16:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
Yes, I've verified with latest git and the regression is still there.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
Honza
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-10 20:00 ` Chuck Ebbert
0 siblings, 0 replies; 243+ messages in thread
From: Chuck Ebbert @ 2009-02-10 20:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kyle McMartin, Linux Kernel Mailing List, Kernel Testers List
On Sun, 8 Feb 2009 23:08:13 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Sunday 08 February 2009, Kyle McMartin wrote:
> > On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> > > Subject : Build failure with latest -git: btrfs on ppc64
> > > Submitter : Chuck Ebbert <cebbert@redhat.com>
> > > Date : 2009-02-07 20:50 (2 days old)
> > > References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
> > >
> >
> > Just fyi, patch here:
> > Subject: x86: spinlocks: define dummy __raw_spin_is_contended
> > Date: Sun, 8 Feb 2009 13:03:41 -0500
> > Message-ID: <20090208180341.GC11398@bombadil.infradead.org>
>
Patch was merged, commit a5ef7ca0e2636bad0ccd07b996d775348ae2b65e
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-10 20:00 ` Chuck Ebbert
0 siblings, 0 replies; 243+ messages in thread
From: Chuck Ebbert @ 2009-02-10 20:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kyle McMartin, Linux Kernel Mailing List, Kernel Testers List
On Sun, 8 Feb 2009 23:08:13 +0100
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Sunday 08 February 2009, Kyle McMartin wrote:
> > On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> > > Subject : Build failure with latest -git: btrfs on ppc64
> > > Submitter : Chuck Ebbert <cebbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > Date : 2009-02-07 20:50 (2 days old)
> > > References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
> > >
> >
> > Just fyi, patch here:
> > Subject: x86: spinlocks: define dummy __raw_spin_is_contended
> > Date: Sun, 8 Feb 2009 13:03:41 -0500
> > Message-ID: <20090208180341.GC11398-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
>
Patch was merged, commit a5ef7ca0e2636bad0ccd07b996d775348ae2b65e
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-10 22:37 ` Michael S. Tsirkin
-1 siblings, 0 replies; 243+ messages in thread
From: Michael S. Tsirkin @ 2009-02-10 22:37 UTC (permalink / raw)
To: Dave Airlie, dri-devel
Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki
Dave, dri guys,
Could you take a look at this circular dependency please (below)? I
observe it when suspending laptop with radeon drm loaded and with
lockdep enabled. It seems that the root of the problem is that
various vm ops such as drm_vm_open, drm_mmap) are called with mm
semaphore taken, and take dev->struct_mutex. On the other hand,
drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
which depends on mm semaphore indirectly.
What do you think?
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-01-29 11:35 (11 days old)
/var/log/message dump below.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc4-mst-debug #95
-------------------------------------------------------
sleep.sh/6730 is trying to acquire lock:
(&per_cpu(cpu_policy_rwsem, cpu)){----}, at: [<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
but task is already holding lock:
(&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&cpu_hotplug.lock){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c012d8fc>] get_online_cpus+0x2c/0x40
[<c010d96f>] mtrr_del_page+0x2f/0x160
[<c010dada>] mtrr_del+0x3a/0x50
[<f851a342>] drm_rmmap_locked+0xc2/0x180 [drm]
[<f8521d31>] drm_master_destroy+0x151/0x160 [drm]
[<c022a37c>] kref_put+0x2c/0x80
[<f8521af2>] drm_master_put+0x12/0x20 [drm]
[<f851dd1b>] drm_release+0x25b/0x4a0 [drm]
[<c019781d>] __fput+0xbd/0x1d0
[<c0197c09>] fput+0x19/0x20
[<c0194a47>] filp_close+0x47/0x70
[<c0194ada>] sys_close+0x6a/0xc0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #5 (&dev->struct_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<f8522add>] drm_vm_open+0x2d/0x50 [drm]
[<c012a397>] dup_mm+0x227/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #4 (&mm->mmap_sem/1){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c01441e8>] down_write_nested+0x48/0x70
[<c012a238>] dup_mm+0xc8/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #3 (&mm->mmap_sem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0183d73>] might_fault+0x73/0x90
[<c022f633>] copy_to_user+0x33/0x60
[<c01a3975>] filldir64+0xb5/0xe0
[<c01e0c2f>] sysfs_readdir+0x11f/0x1f0
[<c01a3b0d>] vfs_readdir+0x8d/0xb0
[<c01a3b99>] sys_getdents64+0x69/0xc0
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #2 (sysfs_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c01e0f0c>] sysfs_addrm_start+0x2c/0xb0
[<c01e14a0>] create_dir+0x40/0x90
[<c01e1556>] sysfs_create_subdir+0x16/0x20
[<c01e2770>] internal_create_group+0x50/0x1a0
[<c01e28ec>] sysfs_create_group+0xc/0x10
[<f81674fc>] cpufreq_stat_notifier_policy+0x9c/0x230 [cpufreq_stats]
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144d24>] __blocking_notifier_call_chain+0x44/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c0226>] __cpufreq_set_policy+0xd6/0x230
[<c02c14a8>] cpufreq_add_dev+0x4e8/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #1 ((cpufreq_policy_notifier_list).rwsem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0367441>] down_read+0x41/0x60
[<c0144d0a>] __blocking_notifier_call_chain+0x2a/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c1165>] cpufreq_add_dev+0x1a5/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){----}:
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
other info that might help us debug this:
4 locks held by sleep.sh/6730:
#0: (&buffer->mutex){--..}, at: [<c01e025b>] sysfs_write_file+0x2b/0x100
#1: (pm_mutex){--..}, at: [<c015cbdb>] enter_state+0x4b/0x1c0
#2: (cpu_add_remove_lock){--..}, at: [<c012d83f>] cpu_maps_update_begin+0xf/0x20
#3: (&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
stack backtrace:
Pid: 6730, comm: sleep.sh Not tainted 2.6.29-rc4-mst-debug #95
Call Trace:
[<c015166c>] print_circular_bug_tail+0x7c/0xe0
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c013cf1e>] ? __cancel_work_timer+0x2e/0x190
[<c01532d0>] lock_acquire+0x60/0x80
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012d83f>] ? cpu_maps_update_begin+0xf/0x20
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c02531cb>] ? acpi_disable_all_gpes+0x25/0x2a
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c015cd50>] ? state_store+0x0/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c0103247>] ? sysenter_exit+0xf/0x18
[<c01e0230>] ? sysfs_write_file+0x0/0x100
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
--
MST
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-10 22:37 ` Michael S. Tsirkin
0 siblings, 0 replies; 243+ messages in thread
From: Michael S. Tsirkin @ 2009-02-10 22:37 UTC (permalink / raw)
To: Dave Airlie, dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki
Dave, dri guys,
Could you take a look at this circular dependency please (below)? I
observe it when suspending laptop with radeon drm loaded and with
lockdep enabled. It seems that the root of the problem is that
various vm ops such as drm_vm_open, drm_mmap) are called with mm
semaphore taken, and take dev->struct_mutex. On the other hand,
drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
which depends on mm semaphore indirectly.
What do you think?
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-29 11:35 (11 days old)
/var/log/message dump below.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc4-mst-debug #95
-------------------------------------------------------
sleep.sh/6730 is trying to acquire lock:
(&per_cpu(cpu_policy_rwsem, cpu)){----}, at: [<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
but task is already holding lock:
(&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&cpu_hotplug.lock){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c012d8fc>] get_online_cpus+0x2c/0x40
[<c010d96f>] mtrr_del_page+0x2f/0x160
[<c010dada>] mtrr_del+0x3a/0x50
[<f851a342>] drm_rmmap_locked+0xc2/0x180 [drm]
[<f8521d31>] drm_master_destroy+0x151/0x160 [drm]
[<c022a37c>] kref_put+0x2c/0x80
[<f8521af2>] drm_master_put+0x12/0x20 [drm]
[<f851dd1b>] drm_release+0x25b/0x4a0 [drm]
[<c019781d>] __fput+0xbd/0x1d0
[<c0197c09>] fput+0x19/0x20
[<c0194a47>] filp_close+0x47/0x70
[<c0194ada>] sys_close+0x6a/0xc0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #5 (&dev->struct_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<f8522add>] drm_vm_open+0x2d/0x50 [drm]
[<c012a397>] dup_mm+0x227/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #4 (&mm->mmap_sem/1){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c01441e8>] down_write_nested+0x48/0x70
[<c012a238>] dup_mm+0xc8/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #3 (&mm->mmap_sem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0183d73>] might_fault+0x73/0x90
[<c022f633>] copy_to_user+0x33/0x60
[<c01a3975>] filldir64+0xb5/0xe0
[<c01e0c2f>] sysfs_readdir+0x11f/0x1f0
[<c01a3b0d>] vfs_readdir+0x8d/0xb0
[<c01a3b99>] sys_getdents64+0x69/0xc0
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #2 (sysfs_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c01e0f0c>] sysfs_addrm_start+0x2c/0xb0
[<c01e14a0>] create_dir+0x40/0x90
[<c01e1556>] sysfs_create_subdir+0x16/0x20
[<c01e2770>] internal_create_group+0x50/0x1a0
[<c01e28ec>] sysfs_create_group+0xc/0x10
[<f81674fc>] cpufreq_stat_notifier_policy+0x9c/0x230 [cpufreq_stats]
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144d24>] __blocking_notifier_call_chain+0x44/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c0226>] __cpufreq_set_policy+0xd6/0x230
[<c02c14a8>] cpufreq_add_dev+0x4e8/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #1 ((cpufreq_policy_notifier_list).rwsem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0367441>] down_read+0x41/0x60
[<c0144d0a>] __blocking_notifier_call_chain+0x2a/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c1165>] cpufreq_add_dev+0x1a5/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){----}:
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
other info that might help us debug this:
4 locks held by sleep.sh/6730:
#0: (&buffer->mutex){--..}, at: [<c01e025b>] sysfs_write_file+0x2b/0x100
#1: (pm_mutex){--..}, at: [<c015cbdb>] enter_state+0x4b/0x1c0
#2: (cpu_add_remove_lock){--..}, at: [<c012d83f>] cpu_maps_update_begin+0xf/0x20
#3: (&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
stack backtrace:
Pid: 6730, comm: sleep.sh Not tainted 2.6.29-rc4-mst-debug #95
Call Trace:
[<c015166c>] print_circular_bug_tail+0x7c/0xe0
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c013cf1e>] ? __cancel_work_timer+0x2e/0x190
[<c01532d0>] lock_acquire+0x60/0x80
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012d83f>] ? cpu_maps_update_begin+0xf/0x20
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c02531cb>] ? acpi_disable_all_gpes+0x25/0x2a
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c015cd50>] ? state_store+0x0/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c0103247>] ? sysenter_exit+0xf/0x18
[<c01e0230>] ? sysfs_write_file+0x0/0x100
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
--
MST
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-10 22:41 ` Eric Anholt
0 siblings, 0 replies; 243+ messages in thread
From: Eric Anholt @ 2009-02-10 22:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Dave Airlie, dri-devel, Linux Kernel Mailing List,
Kernel Testers List, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
> Dave, dri guys,
> Could you take a look at this circular dependency please (below)? I
> observe it when suspending laptop with radeon drm loaded and with
> lockdep enabled. It seems that the root of the problem is that
> various vm ops such as drm_vm_open, drm_mmap) are called with mm
> semaphore taken, and take dev->struct_mutex. On the other hand,
> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
> which depends on mm semaphore indirectly.
>
> What do you think?
Yes, there are real lock inversions now due to the GTT mmap code. It's
going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
path to go away, but the fact that mmap_sem is held over the fault
handler pretty much kills that). It's high on the list, though.
--
Eric Anholt
eric@anholt.net eric.anholt@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-10 22:41 ` Eric Anholt
0 siblings, 0 replies; 243+ messages in thread
From: Eric Anholt @ 2009-02-10 22:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Dave Airlie, dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
> Dave, dri guys,
> Could you take a look at this circular dependency please (below)? I
> observe it when suspending laptop with radeon drm loaded and with
> lockdep enabled. It seems that the root of the problem is that
> various vm ops such as drm_vm_open, drm_mmap) are called with mm
> semaphore taken, and take dev->struct_mutex. On the other hand,
> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
> which depends on mm semaphore indirectly.
>
> What do you think?
Yes, there are real lock inversions now due to the GTT mmap code. It's
going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
path to go away, but the fact that mmap_sem is held over the fault
handler pretty much kills that). It's high on the list, though.
--
Eric Anholt
eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org eric.anholt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
2009-02-10 22:41 ` Eric Anholt
@ 2009-02-11 7:10 ` Thomas Hellström
-1 siblings, 0 replies; 243+ messages in thread
From: Thomas Hellström @ 2009-02-11 7:10 UTC (permalink / raw)
To: Eric Anholt
Cc: Michael S. Tsirkin, Dave Airlie, Rafael J. Wysocki, dri-devel,
Linux Kernel Mailing List, Kernel Testers List
Eric Anholt wrote:
> On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
>
>> Dave, dri guys,
>> Could you take a look at this circular dependency please (below)? I
>> observe it when suspending laptop with radeon drm loaded and with
>> lockdep enabled. It seems that the root of the problem is that
>> various vm ops such as drm_vm_open, drm_mmap) are called with mm
>> semaphore taken, and take dev->struct_mutex. On the other hand,
>> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
>> which depends on mm semaphore indirectly.
>>
>> What do you think?
>>
>
> Yes, there are real lock inversions now due to the GTT mmap code. It's
> going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
> path to go away, but the fact that mmap_sem is held over the fault
> handler pretty much kills that). It's high on the list, though.
>
Shouldn't it be possible to relax this given that in the fault()
handler, the mmap_sem() is taken in read mode only. This means that it
should be deadlock-safe (but still a little ugly) to take the mmap_sem()
in read mode when the struct mutex is held.
Another quick way to fix potential deadlocks, would be to take the
struct mutex in the following way in fault():
if (!mutex_trylock(&dev->struct_mutex)) {
needs_resched();
return VM_FAULT_NOPAGE;
}
/Thomas
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ------------------------------------------------------------------------
>
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-11 7:10 ` Thomas Hellström
0 siblings, 0 replies; 243+ messages in thread
From: Thomas Hellström @ 2009-02-11 7:10 UTC (permalink / raw)
To: Eric Anholt
Cc: Kernel Testers List, Dave Airlie, Michael S. Tsirkin,
Linux Kernel Mailing List, Rafael J. Wysocki, dri-devel
Eric Anholt wrote:
> On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
>
>> Dave, dri guys,
>> Could you take a look at this circular dependency please (below)? I
>> observe it when suspending laptop with radeon drm loaded and with
>> lockdep enabled. It seems that the root of the problem is that
>> various vm ops such as drm_vm_open, drm_mmap) are called with mm
>> semaphore taken, and take dev->struct_mutex. On the other hand,
>> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
>> which depends on mm semaphore indirectly.
>>
>> What do you think?
>>
>
> Yes, there are real lock inversions now due to the GTT mmap code. It's
> going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
> path to go away, but the fact that mmap_sem is held over the fault
> handler pretty much kills that). It's high on the list, though.
>
Shouldn't it be possible to relax this given that in the fault()
handler, the mmap_sem() is taken in read mode only. This means that it
should be deadlock-safe (but still a little ugly) to take the mmap_sem()
in read mode when the struct mutex is held.
Another quick way to fix potential deadlocks, would be to take the
struct mutex in the following way in fault():
if (!mutex_trylock(&dev->struct_mutex)) {
needs_resched();
return VM_FAULT_NOPAGE;
}
/Thomas
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ------------------------------------------------------------------------
>
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 1:47 ` Nick Piggin
0 siblings, 0 replies; 243+ messages in thread
From: Nick Piggin @ 2009-02-12 1:47 UTC (permalink / raw)
To: Jan Kara
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Linus Torvalds
On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> Yes, I've verified with latest git and the regression is still there.
I'm working on this FWIW...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack@suse.cz>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
> Honza
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 1:47 ` Nick Piggin
0 siblings, 0 replies; 243+ messages in thread
From: Nick Piggin @ 2009-02-12 1:47 UTC (permalink / raw)
To: Jan Kara
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Linus Torvalds
On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> Yes, I've verified with latest git and the regression is still there.
I'm working on this FWIW...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
> Honza
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 2:02 ` Linus Torvalds
0 siblings, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2009-02-12 2:02 UTC (permalink / raw)
To: Nick Piggin
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu, 12 Feb 2009, Nick Piggin wrote:
> On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me know
> > > (either way).
> > Yes, I've verified with latest git and the regression is still there.
>
> I'm working on this FWIW...
Shouldn't we just revert it? The code does look to be broken.
It also looks like the interaction with that ever-buggy "nr_to_write"
thing are totally wrong. I can see that whole
if (!cycled) {
..
index = 0;
goto retry
}
doing all the wrong things: if we ever hit the combination of
"!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
the right thing.
I dunno. That whole piece-of-sh*t function has been incredibly buggy this
release. The code is an unreadable mess, and I think that "cyclic" stuff
is part of the reason for it being messy and buggy. Please convince me
it's worth saving, or let me revert the whole stinking pile of crud?
Please?
Linus
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 2:02 ` Linus Torvalds
0 siblings, 0 replies; 243+ messages in thread
From: Linus Torvalds @ 2009-02-12 2:02 UTC (permalink / raw)
To: Nick Piggin
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu, 12 Feb 2009, Nick Piggin wrote:
> On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me know
> > > (either way).
> > Yes, I've verified with latest git and the regression is still there.
>
> I'm working on this FWIW...
Shouldn't we just revert it? The code does look to be broken.
It also looks like the interaction with that ever-buggy "nr_to_write"
thing are totally wrong. I can see that whole
if (!cycled) {
..
index = 0;
goto retry
}
doing all the wrong things: if we ever hit the combination of
"!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
the right thing.
I dunno. That whole piece-of-sh*t function has been incredibly buggy this
release. The code is an unreadable mess, and I think that "cyclic" stuff
is part of the reason for it being messy and buggy. Please convince me
it's worth saving, or let me revert the whole stinking pile of crud?
Please?
Linus
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 3:34 ` Nick Piggin
0 siblings, 0 replies; 243+ messages in thread
From: Nick Piggin @ 2009-02-12 3:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 12 Feb 2009, Nick Piggin wrote:
>
> > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > (either way).
> > > Yes, I've verified with latest git and the regression is still there.
> >
> > I'm working on this FWIW...
>
> Shouldn't we just revert it? The code does look to be broken.
>
> It also looks like the interaction with that ever-buggy "nr_to_write"
> thing are totally wrong. I can see that whole
>
> if (!cycled) {
> ..
> index = 0;
> goto retry
> }
>
> doing all the wrong things: if we ever hit the combination of
> "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> the right thing.
Doh, I think you spotted the bug. I was going off on the wrong track.
> I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> release. The code is an unreadable mess, and I think that "cyclic" stuff
> is part of the reason for it being messy and buggy. Please convince me
> it's worth saving, or let me revert the whole stinking pile of crud?
Well... the cyclic stuff apparently gets used by some filesystems to do
data integrity stuff, so I think the problem addressed by my broken
commit maybe shouldn't be ignored.
Maybe you're being harsh on this function. It has been two thinko bugs
so far. Before this release cycle it seemed to have the record for the
most data integrity bugs in a single function...
How's this? Jan, can you test with the bdb workload please?
--
A bug was introduced into write_cache_pages cyclic writeout by commit
31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
is that we should cycle back and look for more dirty pages at the
beginning of the file if there is no more work to be done.
But the !done condition was dropped from the test. This means that any
time the page writeout loop breaks (eg. due to nr_to_write == 0), we
will set index to 0, then goto again. This will set done_index to index,
then find done is set, so will proceed to the end of the function. When
updating mapping->writeback_index for cyclic writeout, we now use
done_index == 0, so we're always cycling back to 0.
This seemed to be causing random mmap writes (slapadd and iozone) to
start writing more pages from the LRU and writeout would slowdown.
With this patch, iozone random write performance is increased nearly
5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
+++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
@@ -1079,7 +1079,7 @@ continue_unlock:
pagevec_release(&pvec);
cond_resched();
}
- if (!cycled) {
+ if (!cycled && !done) {
/*
* range_cyclic:
* We hit the last page and there is more work to be done: wrap
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 3:34 ` Nick Piggin
0 siblings, 0 replies; 243+ messages in thread
From: Nick Piggin @ 2009-02-12 3:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 12 Feb 2009, Nick Piggin wrote:
>
> > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > (either way).
> > > Yes, I've verified with latest git and the regression is still there.
> >
> > I'm working on this FWIW...
>
> Shouldn't we just revert it? The code does look to be broken.
>
> It also looks like the interaction with that ever-buggy "nr_to_write"
> thing are totally wrong. I can see that whole
>
> if (!cycled) {
> ..
> index = 0;
> goto retry
> }
>
> doing all the wrong things: if we ever hit the combination of
> "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> the right thing.
Doh, I think you spotted the bug. I was going off on the wrong track.
> I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> release. The code is an unreadable mess, and I think that "cyclic" stuff
> is part of the reason for it being messy and buggy. Please convince me
> it's worth saving, or let me revert the whole stinking pile of crud?
Well... the cyclic stuff apparently gets used by some filesystems to do
data integrity stuff, so I think the problem addressed by my broken
commit maybe shouldn't be ignored.
Maybe you're being harsh on this function. It has been two thinko bugs
so far. Before this release cycle it seemed to have the record for the
most data integrity bugs in a single function...
How's this? Jan, can you test with the bdb workload please?
--
A bug was introduced into write_cache_pages cyclic writeout by commit
31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
is that we should cycle back and look for more dirty pages at the
beginning of the file if there is no more work to be done.
But the !done condition was dropped from the test. This means that any
time the page writeout loop breaks (eg. due to nr_to_write == 0), we
will set index to 0, then goto again. This will set done_index to index,
then find done is set, so will proceed to the end of the function. When
updating mapping->writeback_index for cyclic writeout, we now use
done_index == 0, so we're always cycling back to 0.
This seemed to be causing random mmap writes (slapadd and iozone) to
start writing more pages from the LRU and writeout would slowdown.
With this patch, iozone random write performance is increased nearly
5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
Signed-off-by: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>
---
Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
+++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
@@ -1079,7 +1079,7 @@ continue_unlock:
pagevec_release(&pvec);
cond_resched();
}
- if (!cycled) {
+ if (!cycled && !done) {
/*
* range_cyclic:
* We hit the last page and there is more work to be done: wrap
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 14:32 ` Jan Kara
0 siblings, 0 replies; 243+ messages in thread
From: Jan Kara @ 2009-02-12 14:32 UTC (permalink / raw)
To: Nick Piggin
Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu 12-02-09 04:34:23, Nick Piggin wrote:
> On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 12 Feb 2009, Nick Piggin wrote:
> >
> > > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > >
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > > (either way).
> > > > Yes, I've verified with latest git and the regression is still there.
> > >
> > > I'm working on this FWIW...
> >
> > Shouldn't we just revert it? The code does look to be broken.
> >
> > It also looks like the interaction with that ever-buggy "nr_to_write"
> > thing are totally wrong. I can see that whole
> >
> > if (!cycled) {
> > ..
> > index = 0;
> > goto retry
> > }
> >
> > doing all the wrong things: if we ever hit the combination of
> > "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> > the right thing.
>
> Doh, I think you spotted the bug. I was going off on the wrong track.
>
>
> > I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> > release. The code is an unreadable mess, and I think that "cyclic" stuff
> > is part of the reason for it being messy and buggy. Please convince me
> > it's worth saving, or let me revert the whole stinking pile of crud?
>
> Well... the cyclic stuff apparently gets used by some filesystems to do
> data integrity stuff, so I think the problem addressed by my broken
> commit maybe shouldn't be ignored.
>
> Maybe you're being harsh on this function. It has been two thinko bugs
> so far. Before this release cycle it seemed to have the record for the
> most data integrity bugs in a single function...
>
> How's this? Jan, can you test with the bdb workload please?
Yes, this patch returns write performance of BDB workload back to
original numbers. Thanks for the fix.
Honza
> --
>
> A bug was introduced into write_cache_pages cyclic writeout by commit
> 31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
> is that we should cycle back and look for more dirty pages at the
> beginning of the file if there is no more work to be done.
>
> But the !done condition was dropped from the test. This means that any
> time the page writeout loop breaks (eg. due to nr_to_write == 0), we
> will set index to 0, then goto again. This will set done_index to index,
> then find done is set, so will proceed to the end of the function. When
> updating mapping->writeback_index for cyclic writeout, we now use
> done_index == 0, so we're always cycling back to 0.
>
> This seemed to be causing random mmap writes (slapadd and iozone) to
> start writing more pages from the LRU and writeout would slowdown.
>
> With this patch, iozone random write performance is increased nearly
> 5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> ---
> Index: linux-2.6/mm/page-writeback.c
> ===================================================================
> --- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
> +++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
> @@ -1079,7 +1079,7 @@ continue_unlock:
> pagevec_release(&pvec);
> cond_resched();
> }
> - if (!cycled) {
> + if (!cycled && !done) {
> /*
> * range_cyclic:
> * We hit the last page and there is more work to be done: wrap
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 14:32 ` Jan Kara
0 siblings, 0 replies; 243+ messages in thread
From: Jan Kara @ 2009-02-12 14:32 UTC (permalink / raw)
To: Nick Piggin
Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu 12-02-09 04:34:23, Nick Piggin wrote:
> On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 12 Feb 2009, Nick Piggin wrote:
> >
> > > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > >
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > > (either way).
> > > > Yes, I've verified with latest git and the regression is still there.
> > >
> > > I'm working on this FWIW...
> >
> > Shouldn't we just revert it? The code does look to be broken.
> >
> > It also looks like the interaction with that ever-buggy "nr_to_write"
> > thing are totally wrong. I can see that whole
> >
> > if (!cycled) {
> > ..
> > index = 0;
> > goto retry
> > }
> >
> > doing all the wrong things: if we ever hit the combination of
> > "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> > the right thing.
>
> Doh, I think you spotted the bug. I was going off on the wrong track.
>
>
> > I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> > release. The code is an unreadable mess, and I think that "cyclic" stuff
> > is part of the reason for it being messy and buggy. Please convince me
> > it's worth saving, or let me revert the whole stinking pile of crud?
>
> Well... the cyclic stuff apparently gets used by some filesystems to do
> data integrity stuff, so I think the problem addressed by my broken
> commit maybe shouldn't be ignored.
>
> Maybe you're being harsh on this function. It has been two thinko bugs
> so far. Before this release cycle it seemed to have the record for the
> most data integrity bugs in a single function...
>
> How's this? Jan, can you test with the bdb workload please?
Yes, this patch returns write performance of BDB workload back to
original numbers. Thanks for the fix.
Honza
> --
>
> A bug was introduced into write_cache_pages cyclic writeout by commit
> 31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
> is that we should cycle back and look for more dirty pages at the
> beginning of the file if there is no more work to be done.
>
> But the !done condition was dropped from the test. This means that any
> time the page writeout loop breaks (eg. due to nr_to_write == 0), we
> will set index to 0, then goto again. This will set done_index to index,
> then find done is set, so will proceed to the end of the function. When
> updating mapping->writeback_index for cyclic writeout, we now use
> done_index == 0, so we're always cycling back to 0.
>
> This seemed to be causing random mmap writes (slapadd and iozone) to
> start writing more pages from the LRU and writeout would slowdown.
>
> With this patch, iozone random write performance is increased nearly
> 5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
>
> Signed-off-by: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>
> ---
> Index: linux-2.6/mm/page-writeback.c
> ===================================================================
> --- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
> +++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
> @@ -1079,7 +1079,7 @@ continue_unlock:
> pagevec_release(&pvec);
> cond_resched();
> }
> - if (!cycled) {
> + if (!cycled && !done) {
> /*
> * range_cyclic:
> * We hit the last page and there is more work to be done: wrap
--
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-14 14:29 ` Theodore Tso
-1 siblings, 0 replies; 243+ messages in thread
From: Theodore Tso @ 2009-02-14 14:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack@suse.cz>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
3a4c6800. So this bug can be closed now...
- Ted
P.S. One good thing about the commit 31a12666 was that made an
otherwise very hard to hit potential deadlock condition in ext4 very
easy to hit, and thus for us to detect and to fix. So, thanks. :-)
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-14 14:29 ` Theodore Tso
0 siblings, 0 replies; 243+ messages in thread
From: Theodore Tso @ 2009-02-14 14:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
3a4c6800. So this bug can be closed now...
- Ted
P.S. One good thing about the commit 31a12666 was that made an
otherwise very hard to hit potential deadlock condition in ext4 very
easy to hit, and thus for us to detect and to fix. So, thanks. :-)
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-14 19:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 19:53 UTC (permalink / raw)
To: Theodore Tso
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Saturday 14 February 2009, Theodore Tso wrote:
> On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack@suse.cz>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
> >
>
> Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
> 3a4c6800. So this bug can be closed now...
The bug has been closed already.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-14 19:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 19:53 UTC (permalink / raw)
To: Theodore Tso
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Saturday 14 February 2009, Theodore Tso wrote:
> On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
> >
>
> Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
> 3a4c6800. So this bug can be closed now...
The bug has been closed already.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-14 22:35 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:35 UTC (permalink / raw)
To: Herbert Xu
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Monday 09 February 2009, Herbert Xu wrote:
> On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
>
> The patch in question has already been reverted. So while we
> still need to track down the underlying problem with rlogin, it's
> no longer a kernel regression.
I've closed the bug, sorry for the slow response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-14 22:35 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:35 UTC (permalink / raw)
To: Herbert Xu
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Monday 09 February 2009, Herbert Xu wrote:
> On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
>
> The patch in question has already been reverted. So while we
> still need to track down the underlying problem with rlogin, it's
> no longer a kernel regression.
I've closed the bug, sorry for the slow response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-14 22:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:39 UTC (permalink / raw)
To: wixor; +Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
On Monday 09 February 2009, wixor wrote:
> There was no support for Chrome9 framebuffer before 2.6.28, so that is
> a progress. However now that we have it, it doesn't work (at least for
> me).... The BUG appearing seemed to be an mm-issue also reported by
> others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
> don't know if it was there before 2.6.28. It doesn't look like any
> solution has been merged to mainline.
>
> It is certainly an issue, but I'm not sure if it's also a regression
> from 2.6.28.
I've dropped it from the list of recent regressions, sorry for the slow
response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-14 22:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:39 UTC (permalink / raw)
To: wixor; +Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
On Monday 09 February 2009, wixor wrote:
> There was no support for Chrome9 framebuffer before 2.6.28, so that is
> a progress. However now that we have it, it doesn't work (at least for
> me).... The BUG appearing seemed to be an mm-issue also reported by
> others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
> don't know if it was there before 2.6.28. It doesn't look like any
> solution has been merged to mainline.
>
> It is certainly an issue, but I'm not sure if it's also a regression
> from 2.6.28.
I've dropped it from the list of recent regressions, sorry for the slow
response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-14 22:42 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:42 UTC (permalink / raw)
To: Paul Collins
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
On Monday 09 February 2009, Paul Collins wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul@burly.ondioline.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Thanks, I've closed the bug.
Sorry for the slow response.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-14 22:42 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:42 UTC (permalink / raw)
To: Paul Collins
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
On Monday 09 February 2009, Paul Collins wrote:
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Thanks, I've closed the bug.
Sorry for the slow response.
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 7:17 ` Paul Collins
0 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-16 7:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner, benh
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Monday 09 February 2009, Paul Collins wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
>> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
>> > Submitter : Paul Collins <paul@burly.ondioline.org>
>> > Date : 2009-01-21 7:15 (19 days old)
>> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
>> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>>
>> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
>> message was not logged, so it's either gone away or else become much
>> more difficult to reproduce.
>
> Thanks, I've closed the bug.
It turns out I didn't test this properly. The warning is only triggered
when I close and open the lid, not when I run 'snooze' to suspend and
hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
Whatever is triggering the warning is still present in 2.6.29-rc5.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 7:17 ` Paul Collins
0 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-16 7:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
> On Monday 09 February 2009, Paul Collins wrote:
>> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>>
>> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
>> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
>> > Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
>> > Date : 2009-01-21 7:15 (19 days old)
>> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
>> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>>
>> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
>> message was not logged, so it's either gone away or else become much
>> more difficult to reproduce.
>
> Thanks, I've closed the bug.
It turns out I didn't test this properly. The warning is only triggered
when I close and open the lid, not when I run 'snooze' to suspend and
hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
Whatever is triggering the warning is still present in 2.6.29-rc5.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 9:10 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-16 9:10 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
> It turns out I didn't test this properly. The warning is only
> triggered
> when I close and open the lid, not when I run 'snooze' to suspend and
> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>
> Whatever is triggering the warning is still present in 2.6.29-rc5.
Right, we probably need to stop sending input events from the PMU driver
when it's "suspended".
Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 9:10 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-16 9:10 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
> It turns out I didn't test this properly. The warning is only
> triggered
> when I close and open the lid, not when I run 'snooze' to suspend and
> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>
> Whatever is triggering the warning is still present in 2.6.29-rc5.
Right, we probably need to stop sending input events from the PMU driver
when it's "suspended".
Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-16 9:10 ` Benjamin Herrenschmidt
@ 2009-02-16 10:47 ` Paul Collins
-1 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-16 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>> It turns out I didn't test this properly. The warning is only
>> triggered
>> when I close and open the lid, not when I run 'snooze' to suspend and
>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>
>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>
> Right, we probably need to stop sending input events from the PMU driver
> when it's "suspended".
>
> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Just for laughs I slapped together the following, which seems to do the
job, although not especially tidily.
diff --git a/drivers/macintosh/via-pmu-event.c b/drivers/macintosh/via-pmu-event.c
index 25cd565..33c4b45 100644
--- a/drivers/macintosh/via-pmu-event.c
+++ b/drivers/macintosh/via-pmu-event.c
@@ -23,6 +23,7 @@
#include <linux/input.h>
#include <linux/adb.h>
#include <linux/pmu.h>
+#include <linux/bug.h>
#include "via-pmu-event.h"
static struct input_dev *pmu_input_dev;
@@ -56,24 +57,62 @@ static int __init via_pmu_event_init(void)
return err;
}
+static bool lid_event_pending;
+static int lid_event_pending_down;
+static bool power_button_event_pending;
+static int power_button_event_pending_down;
+
void via_pmu_event(int key, int down)
{
if (unlikely(!pmu_input_dev))
return;
- switch (key) {
- case PMU_EVT_POWER:
- input_report_key(pmu_input_dev, KEY_POWER, down);
- break;
- case PMU_EVT_LID:
- input_report_switch(pmu_input_dev, SW_LID, down);
- break;
- default:
- /* no such key handled */
- return;
- }
+ if (!pmu_sys_suspended) {
+ switch (key) {
+ case PMU_EVT_POWER:
+ input_report_key(pmu_input_dev, KEY_POWER, down);
+ break;
+ case PMU_EVT_LID:
+ input_report_switch(pmu_input_dev, SW_LID, down);
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+
+ input_sync(pmu_input_dev);
+ } else {
+ switch (key) {
+ case PMU_EVT_POWER:
+ power_button_event_pending = true;
+ power_button_event_pending_down = down;
+ break;
+ case PMU_EVT_LID:
+ lid_event_pending = true;
+ lid_event_pending_down = down;
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+ }
+}
+void via_pmu_event_resume(void)
+{
+ WARN_ON(pmu_sys_suspended);
+
+ if (power_button_event_pending) {
+ input_report_key(pmu_input_dev, KEY_POWER,
+ power_button_event_pending_down);
+ power_button_event_pending = false;
+ }
+ if (lid_event_pending) {
+ input_report_switch(pmu_input_dev, SW_LID,
+ lid_event_pending_down);
+ lid_event_pending = false;
+ }
input_sync(pmu_input_dev);
}
diff --git a/drivers/macintosh/via-pmu-event.h b/drivers/macintosh/via-pmu-event.h
index 72c54de..2754adc 100644
--- a/drivers/macintosh/via-pmu-event.h
+++ b/drivers/macintosh/via-pmu-event.h
@@ -4,5 +4,6 @@
#define PMU_EVT_POWER 0
#define PMU_EVT_LID 1
extern void via_pmu_event(int key, int down);
+extern void via_pmu_event_resume(void);
#endif /* __VIA_PMU_EVENT_H */
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index b40fb9b..01b8689 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2479,6 +2479,8 @@ static int pmu_sys_resume(struct sys_device *sysdev)
pmu_resume();
pmu_sys_suspended = 0;
+ via_pmu_event_resume();
+
return 0;
}
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 10:47 ` Paul Collins
0 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-16 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>> It turns out I didn't test this properly. The warning is only
>> triggered
>> when I close and open the lid, not when I run 'snooze' to suspend and
>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>
>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>
> Right, we probably need to stop sending input events from the PMU driver
> when it's "suspended".
>
> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Just for laughs I slapped together the following, which seems to do the
job, although not especially tidily.
diff --git a/drivers/macintosh/via-pmu-event.c b/drivers/macintosh/via-pmu-event.c
index 25cd565..33c4b45 100644
--- a/drivers/macintosh/via-pmu-event.c
+++ b/drivers/macintosh/via-pmu-event.c
@@ -23,6 +23,7 @@
#include <linux/input.h>
#include <linux/adb.h>
#include <linux/pmu.h>
+#include <linux/bug.h>
#include "via-pmu-event.h"
static struct input_dev *pmu_input_dev;
@@ -56,24 +57,62 @@ static int __init via_pmu_event_init(void)
return err;
}
+static bool lid_event_pending;
+static int lid_event_pending_down;
+static bool power_button_event_pending;
+static int power_button_event_pending_down;
+
void via_pmu_event(int key, int down)
{
if (unlikely(!pmu_input_dev))
return;
- switch (key) {
- case PMU_EVT_POWER:
- input_report_key(pmu_input_dev, KEY_POWER, down);
- break;
- case PMU_EVT_LID:
- input_report_switch(pmu_input_dev, SW_LID, down);
- break;
- default:
- /* no such key handled */
- return;
- }
+ if (!pmu_sys_suspended) {
+ switch (key) {
+ case PMU_EVT_POWER:
+ input_report_key(pmu_input_dev, KEY_POWER, down);
+ break;
+ case PMU_EVT_LID:
+ input_report_switch(pmu_input_dev, SW_LID, down);
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+
+ input_sync(pmu_input_dev);
+ } else {
+ switch (key) {
+ case PMU_EVT_POWER:
+ power_button_event_pending = true;
+ power_button_event_pending_down = down;
+ break;
+ case PMU_EVT_LID:
+ lid_event_pending = true;
+ lid_event_pending_down = down;
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+ }
+}
+void via_pmu_event_resume(void)
+{
+ WARN_ON(pmu_sys_suspended);
+
+ if (power_button_event_pending) {
+ input_report_key(pmu_input_dev, KEY_POWER,
+ power_button_event_pending_down);
+ power_button_event_pending = false;
+ }
+ if (lid_event_pending) {
+ input_report_switch(pmu_input_dev, SW_LID,
+ lid_event_pending_down);
+ lid_event_pending = false;
+ }
input_sync(pmu_input_dev);
}
diff --git a/drivers/macintosh/via-pmu-event.h b/drivers/macintosh/via-pmu-event.h
index 72c54de..2754adc 100644
--- a/drivers/macintosh/via-pmu-event.h
+++ b/drivers/macintosh/via-pmu-event.h
@@ -4,5 +4,6 @@
#define PMU_EVT_POWER 0
#define PMU_EVT_LID 1
extern void via_pmu_event(int key, int down);
+extern void via_pmu_event_resume(void);
#endif /* __VIA_PMU_EVENT_H */
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index b40fb9b..01b8689 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2479,6 +2479,8 @@ static int pmu_sys_resume(struct sys_device *sysdev)
pmu_resume();
pmu_sys_suspended = 0;
+ via_pmu_event_resume();
+
return 0;
}
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:27 ` Paul Collins
0 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-19 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Paul Collins <paul@burly.ondioline.org> writes:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
>> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>>> It turns out I didn't test this properly. The warning is only
>>> triggered
>>> when I close and open the lid, not when I run 'snooze' to suspend and
>>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>>
>>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>>
>> Right, we probably need to stop sending input events from the PMU driver
>> when it's "suspended".
>>
>> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
>
> Just for laughs I slapped together the following, which seems to do the
> job, although not especially tidily.
And it doesn't even do the job. Judging by this new trace, submitting
input events from the via-pmu resume function is still too early.
NIP [c0053b4c] getnstimeofday+0x24/0x188
LR [c0053ccc] do_gettimeofday+0x1c/0x58
Call Trace:
[eed09cb0] [c0053ccc] do_gettimeofday+0x1c/0x58
[eed09ce0] [c03492cc] evdev_event+0x28/0x158
[eed09d10] [c0341748] input_pass_event+0xac/0xb0
[eed09d30] [c03444a8] input_event+0x80/0x98
[eed09d50] [c02f7668] via_pmu_event_resume+0x60/0xb8 <-- the function I added
[eed09d60] [c02f725c] pmu_sys_resume+0x5c/0x74
[eed09de0] [c02d6420] __sysdev_resume+0x64/0x84
[eed09e00] [c02d6498] sysdev_resume+0x58/0xa4
[eed09e20] [c02dd39c] device_power_up+0x18/0x38
[eed09e40] [c00609d4] suspend_devices_and_enter+0x11c/0x180
[eed09e60] [c0060be8] enter_state+0x11c/0x160
[eed09e80] [c02f4d6c] pmu_ioctl+0x15c/0x24c
[eed09e90] [c00bad34] vfs_ioctl+0x8c/0x90
[eed09ea0] [c00bade8] do_vfs_ioctl+0x8c/0x70c
[eed09f10] [c00bb504] sys_ioctl+0x9c/0xa4
[eed09f40] [c0012eb8] ret_from_syscall+0x0/0x38
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:27 ` Paul Collins
0 siblings, 0 replies; 243+ messages in thread
From: Paul Collins @ 2009-02-19 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org> writes:
> Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
>
>> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>>> It turns out I didn't test this properly. The warning is only
>>> triggered
>>> when I close and open the lid, not when I run 'snooze' to suspend and
>>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>>
>>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>>
>> Right, we probably need to stop sending input events from the PMU driver
>> when it's "suspended".
>>
>> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
>
> Just for laughs I slapped together the following, which seems to do the
> job, although not especially tidily.
And it doesn't even do the job. Judging by this new trace, submitting
input events from the via-pmu resume function is still too early.
NIP [c0053b4c] getnstimeofday+0x24/0x188
LR [c0053ccc] do_gettimeofday+0x1c/0x58
Call Trace:
[eed09cb0] [c0053ccc] do_gettimeofday+0x1c/0x58
[eed09ce0] [c03492cc] evdev_event+0x28/0x158
[eed09d10] [c0341748] input_pass_event+0xac/0xb0
[eed09d30] [c03444a8] input_event+0x80/0x98
[eed09d50] [c02f7668] via_pmu_event_resume+0x60/0xb8 <-- the function I added
[eed09d60] [c02f725c] pmu_sys_resume+0x5c/0x74
[eed09de0] [c02d6420] __sysdev_resume+0x64/0x84
[eed09e00] [c02d6498] sysdev_resume+0x58/0xa4
[eed09e20] [c02dd39c] device_power_up+0x18/0x38
[eed09e40] [c00609d4] suspend_devices_and_enter+0x11c/0x180
[eed09e60] [c0060be8] enter_state+0x11c/0x160
[eed09e80] [c02f4d6c] pmu_ioctl+0x15c/0x24c
[eed09e90] [c00bad34] vfs_ioctl+0x8c/0x90
[eed09ea0] [c00bade8] do_vfs_ioctl+0x8c/0x70c
[eed09f10] [c00bb504] sys_ioctl+0x9c/0xa4
[eed09f40] [c0012eb8] ret_from_syscall+0x0/0x38
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 8:38 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > Just for laughs I slapped together the following, which seems to do
> the
> > job, although not especially tidily.
>
> And it doesn't even do the job. Judging by this new trace, submitting
> input events from the via-pmu resume function is still too early.
>
What's up Thomas ? We can't call gettimeofday() from a sysdev
suspend/resume ? That's a little bit too harsh no ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 8:38 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > Just for laughs I slapped together the following, which seems to do
> the
> > job, although not especially tidily.
>
> And it doesn't even do the job. Judging by this new trace, submitting
> input events from the via-pmu resume function is still too early.
>
What's up Thomas ? We can't call gettimeofday() from a sysdev
suspend/resume ? That's a little bit too harsh no ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 8:38 ` Benjamin Herrenschmidt
@ 2009-02-19 13:00 ` Rafael J. Wysocki
-1 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
resume)?
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 13:00 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
resume)?
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 8:38 ` Benjamin Herrenschmidt
@ 2009-02-19 20:17 ` Thomas Gleixner
-1 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2009-02-19 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Well, harsh or not is not the question here.
Fact is that you call gettimeofday() _before_ the timekeeping code has
resumed.
That's a simple ordering problem. timekeeping is in the sysdev class
as well and it's not the only sysdev which has explicit ordering
requirements.
Thanks,
tglx
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 20:17 ` Thomas Gleixner
0 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2009-02-19 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Well, harsh or not is not the question here.
Fact is that you call gettimeofday() _before_ the timekeeping code has
resumed.
That's a simple ordering problem. timekeeping is in the sysdev class
as well and it's not the only sysdev which has explicit ordering
requirements.
Thanks,
tglx
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 21:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Benjamin Herrenschmidt, Paul Collins, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thursday 19 February 2009, Thomas Gleixner wrote:
> On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
Do we need suspend-resume priorities for sysdevs? Such that sysdevs
with a higher priority will always be suspended earlier and resumed later
than sysdevs with lower priority (or the other way around)?
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 21:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Benjamin Herrenschmidt, Paul Collins, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thursday 19 February 2009, Thomas Gleixner wrote:
> On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
Do we need suspend-resume priorities for sysdevs? Such that sysdevs
with a higher priority will always be suspended earlier and resumed later
than sysdevs with lower priority (or the other way around)?
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:47 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> resume)?
In this case, maybe gtod should just return the frozen time (ie, last
time at the time of suspend) rather than WARN ?
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:47 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> resume)?
In this case, maybe gtod should just return the frozen time (ie, last
time at the time of suspend) rather than WARN ?
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
And how do I control that ordering ?
I find that a bit fishy ... What about making gettimeofday() in the
timekeeping code work, just return a frozen snapshot of the value on
suspend instead ?
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
And how do I control that ordering ?
I find that a bit fishy ... What about making gettimeofday() in the
timekeeping code work, just return a frozen snapshot of the value on
suspend instead ?
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 21:47 ` Benjamin Herrenschmidt
@ 2009-02-19 22:08 ` Rafael J. Wysocki
-1 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> > On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > > Just for laughs I slapped together the following, which seems to do
> > > > the
> > > > > job, although not especially tidily.
> > > >
> > > > And it doesn't even do the job. Judging by this new trace, submitting
> > > > input events from the via-pmu resume function is still too early.
> > > >
> > > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > > suspend/resume ? That's a little bit too harsh no ?
> >
> > Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> > resume)?
>
> In this case, maybe gtod should just return the frozen time (ie, last
> time at the time of suspend) rather than WARN ?
This might work, but there seem to be more problems like this (cpufreq vs
timekeeping for example).
I think we need a more general approach.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 22:08 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> > On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > > Just for laughs I slapped together the following, which seems to do
> > > > the
> > > > > job, although not especially tidily.
> > > >
> > > > And it doesn't even do the job. Judging by this new trace, submitting
> > > > input events from the via-pmu resume function is still too early.
> > > >
> > > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > > suspend/resume ? That's a little bit too harsh no ?
> >
> > Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> > resume)?
>
> In this case, maybe gtod should just return the frozen time (ie, last
> time at the time of suspend) rather than WARN ?
This might work, but there seem to be more problems like this (cpufreq vs
timekeeping for example).
I think we need a more general approach.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 21:51 ` Benjamin Herrenschmidt
@ 2009-02-22 19:31 ` Thomas Gleixner
-1 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2009-02-22 19:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Fri, 20 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
> >
> > Well, harsh or not is not the question here.
> >
> > Fact is that you call gettimeofday() _before_ the timekeeping code has
> > resumed.
> >
> > That's a simple ordering problem. timekeeping is in the sysdev class
> > as well and it's not the only sysdev which has explicit ordering
> > requirements.
>
> And how do I control that ordering ?
>
> I find that a bit fishy ... What about making gettimeofday() in the
> timekeeping code work, just return a frozen snapshot of the value on
> suspend instead ?
We had problems in the past where we just returned frozen time and the
calling code got surprised when the time jumped 5 hours ahead just a
few microseconds later.
What I find more fishy is the fact that the lid switch needs to be a
sysdev. It's a simple input event, which causes the user space code to
trigger the suspend sequence when the lid is shut.
Thanks,
tglx
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-22 19:31 ` Thomas Gleixner
0 siblings, 0 replies; 243+ messages in thread
From: Thomas Gleixner @ 2009-02-22 19:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Fri, 20 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
> >
> > Well, harsh or not is not the question here.
> >
> > Fact is that you call gettimeofday() _before_ the timekeeping code has
> > resumed.
> >
> > That's a simple ordering problem. timekeeping is in the sysdev class
> > as well and it's not the only sysdev which has explicit ordering
> > requirements.
>
> And how do I control that ordering ?
>
> I find that a bit fishy ... What about making gettimeofday() in the
> timekeeping code work, just return a frozen snapshot of the value on
> suspend instead ?
We had problems in the past where we just returned frozen time and the
calling code got surprised when the time jumped 5 hours ahead just a
few microseconds later.
What I find more fishy is the fact that the lid switch needs to be a
sysdev. It's a simple input event, which causes the user space code to
trigger the suspend sequence when the lid is shut.
Thanks,
tglx
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-22 20:46 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-22 20:46 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Sun, 2009-02-22 at 20:31 +0100, Thomas Gleixner wrote:
> We had problems in the past where we just returned frozen time and the
> calling code got surprised when the time jumped 5 hours ahead just a
> few microseconds later.
>
> What I find more fishy is the fact that the lid switch needs to be a
> sysdev. It's a simple input event, which causes the user space code to
> trigger the suspend sequence when the lid is shut.
>
Well, the PMU is a sysdev for lots of good reasons.. then it -also-
happens to provide us with the lid switch event.
I'm a bit surprised by the explanation about the code that is surprised
to see the time jump. IE. Code -will- see the time jump anyway. IE. I
don't see how making gtod blow instead of returning a frozen time will
make any difference whatsoever for code who get the time some time
before suspend and then some time after resume and see a 5 hours gap...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-22 20:46 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-22 20:46 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Sun, 2009-02-22 at 20:31 +0100, Thomas Gleixner wrote:
> We had problems in the past where we just returned frozen time and the
> calling code got surprised when the time jumped 5 hours ahead just a
> few microseconds later.
>
> What I find more fishy is the fact that the lid switch needs to be a
> sysdev. It's a simple input event, which causes the user space code to
> trigger the suspend sequence when the lid is shut.
>
Well, the PMU is a sysdev for lots of good reasons.. then it -also-
happens to provide us with the lid switch event.
I'm a bit surprised by the explanation about the code that is surprised
to see the time jump. IE. Code -will- see the time jump anyway. IE. I
don't see how making gtod blow instead of returning a frozen time will
make any difference whatsoever for code who get the time some time
before suspend and then some time after resume and see a 5 hours gap...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-07 3:05 ` Benjamin Herrenschmidt
@ 2009-02-07 23:15 ` Jesse Barnes
-1 siblings, 0 replies; 243+ messages in thread
From: Jesse Barnes @ 2009-02-07 23:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Friday, February 6, 2009 7:05 pm Benjamin Herrenschmidt wrote:
> On Fri, 2009-02-06 at 14:45 -0800, Jesse Barnes wrote:
> > + if (Base <= 1024*1024) {
> > + /* Try legacy_mem (may not be available or implemented) */
> > + if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
> > + addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED,
> > fd, Base); + close(fd);
> > + if (addr && addr != MAP_FAILED)
> > + return addr;
> > + }
> > }
> > - return addr;
> > +
> > + /* Fall back to old method if legacy_mem fails or Base >= 1M */
> > + return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
> > PCIIOC_MMAP_IS_MEM); }
>
> I don't like the fallback if legacy_mem exists and returns an error,
> that's an indication that legacy memory is -not- available and thus
> whatever 'fallback' X will try (supposedly using /dev/mem) will be
> horribly broken and will probably end up scribbling all over system
> memory :-)
Yeah, but unless we fix all the callers (and possibly their callers), not
falling back will keep X from starting...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 23:15 ` Jesse Barnes
0 siblings, 0 replies; 243+ messages in thread
From: Jesse Barnes @ 2009-02-07 23:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Friday, February 6, 2009 7:05 pm Benjamin Herrenschmidt wrote:
> On Fri, 2009-02-06 at 14:45 -0800, Jesse Barnes wrote:
> > + if (Base <= 1024*1024) {
> > + /* Try legacy_mem (may not be available or implemented) */
> > + if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
> > + addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED,
> > fd, Base); + close(fd);
> > + if (addr && addr != MAP_FAILED)
> > + return addr;
> > + }
> > }
> > - return addr;
> > +
> > + /* Fall back to old method if legacy_mem fails or Base >= 1M */
> > + return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
> > PCIIOC_MMAP_IS_MEM); }
>
> I don't like the fallback if legacy_mem exists and returns an error,
> that's an indication that legacy memory is -not- available and thus
> whatever 'fallback' X will try (supposedly using /dev/mem) will be
> horribly broken and will probably end up scribbling all over system
> memory :-)
Yeah, but unless we fix all the callers (and possibly their callers), not
falling back will keep X from starting...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 3:05 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-07 3:05 UTC (permalink / raw)
To: Jesse Barnes
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Fri, 2009-02-06 at 14:45 -0800, Jesse Barnes wrote:
> + if (Base <= 1024*1024) {
> + /* Try legacy_mem (may not be available or implemented) */
> + if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
> + addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
> + close(fd);
> + if (addr && addr != MAP_FAILED)
> + return addr;
> + }
> }
> - return addr;
> +
> + /* Fall back to old method if legacy_mem fails or Base >= 1M */
> + return linuxMapPci(ScreenNum, Flags, dev, Base, Size, PCIIOC_MMAP_IS_MEM);
> }
I don't like the fallback if legacy_mem exists and returns an error,
that's an indication that legacy memory is -not- available and thus
whatever 'fallback' X will try (supposedly using /dev/mem) will be
horribly broken and will probably end up scribbling all over system
memory :-)
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 3:05 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-07 3:05 UTC (permalink / raw)
To: Jesse Barnes
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Fri, 2009-02-06 at 14:45 -0800, Jesse Barnes wrote:
> + if (Base <= 1024*1024) {
> + /* Try legacy_mem (may not be available or implemented) */
> + if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
> + addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
> + close(fd);
> + if (addr && addr != MAP_FAILED)
> + return addr;
> + }
> }
> - return addr;
> +
> + /* Fall back to old method if legacy_mem fails or Base >= 1M */
> + return linuxMapPci(ScreenNum, Flags, dev, Base, Size, PCIIOC_MMAP_IS_MEM);
> }
I don't like the fallback if legacy_mem exists and returns an error,
that's an indication that legacy memory is -not- available and thus
whatever 'fallback' X will try (supposedly using /dev/mem) will be
horribly broken and will probably end up scribbling all over system
memory :-)
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 2:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-07 2:51 UTC (permalink / raw)
To: Hugh Dickins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
> I still don't understand the point of this legacy_mem file at all,
> and why X should want to mmap it, if it works so well when it's
> thus divorced from reality. But I won't worry my pretty little
> head over it any further - please don't waste your time trying
> to explain it to me!
VGA memory hole :-) ie, text mode & fonts
Ben.
> Thanks,
> Hugh
>
> >
> > Index: linux-work/arch/powerpc/kernel/pci-common.c
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/kernel/pci-common.c 2009-02-06 16:23:36.000000000 +1100
> > +++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.000000000 +1100
> > @@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
> > (unsigned long long)(offset + size - 1));
> >
> > if (mmap_state == pci_mmap_mem) {
> > - if ((offset + size) > hose->isa_mem_size)
> > - return -ENXIO;
> > + /* Hack alert !
> > + *
> > + * Because X is lame and can fail starting if it gets an error trying
> > + * to mmap legacy_mem (instead of just moving on without legacy memory
> > + * access) we fake it here by giving it anonymous memory, effectively
> > + * behaving just like /dev/zero
> > + */
> > + if ((offset + size) > hose->isa_mem_size) {
> > + printk(KERN_DEBUG
> > + "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n",
> > + current->comm, current->pid, pci_domain_nr(bus), bus->number);
> > + if (vma->vm_flags & VM_SHARED)
> > + return shmem_zero_setup(vma);
> > + return 0;
> > + }
> > offset += hose->isa_mem_phys;
> > } else {
> > unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 2:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-07 2:51 UTC (permalink / raw)
To: Hugh Dickins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
> I still don't understand the point of this legacy_mem file at all,
> and why X should want to mmap it, if it works so well when it's
> thus divorced from reality. But I won't worry my pretty little
> head over it any further - please don't waste your time trying
> to explain it to me!
VGA memory hole :-) ie, text mode & fonts
Ben.
> Thanks,
> Hugh
>
> >
> > Index: linux-work/arch/powerpc/kernel/pci-common.c
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/kernel/pci-common.c 2009-02-06 16:23:36.000000000 +1100
> > +++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.000000000 +1100
> > @@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
> > (unsigned long long)(offset + size - 1));
> >
> > if (mmap_state == pci_mmap_mem) {
> > - if ((offset + size) > hose->isa_mem_size)
> > - return -ENXIO;
> > + /* Hack alert !
> > + *
> > + * Because X is lame and can fail starting if it gets an error trying
> > + * to mmap legacy_mem (instead of just moving on without legacy memory
> > + * access) we fake it here by giving it anonymous memory, effectively
> > + * behaving just like /dev/zero
> > + */
> > + if ((offset + size) > hose->isa_mem_size) {
> > + printk(KERN_DEBUG
> > + "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n",
> > + current->comm, current->pid, pci_domain_nr(bus), bus->number);
> > + if (vma->vm_flags & VM_SHARED)
> > + return shmem_zero_setup(vma);
> > + return 0;
> > + }
> > offset += hose->isa_mem_phys;
> > } else {
> > unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-07 0:50 ` Hugh Dickins
(?)
@ 2009-02-07 1:47 ` Jesse Barnes
-1 siblings, 0 replies; 243+ messages in thread
From: Jesse Barnes @ 2009-02-07 1:47 UTC (permalink / raw)
To: Hugh Dickins
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Friday, February 6, 2009 4:50 pm Hugh Dickins wrote:
> On Fri, 6 Feb 2009, Jesse Barnes wrote:
> > Yeah that should work. I always hated this code (well most of X
> > actually); we could probably clean up the logic a little. If this works
> > I'll send it out to the Xorg list for review.
>
> Yes, thanks for restructuring it, I was rather itching to do so.
>
> With the one small change below which I think you'll approve,
> your patch works for me on the G5 - but I've not tested it on
> other (x86) machines which were already working.
Heh, yeah thanks. Ok I'll get it into X.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 0:50 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-07 0:50 UTC (permalink / raw)
To: Jesse Barnes
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Fri, 6 Feb 2009, Jesse Barnes wrote:
>
> Yeah that should work. I always hated this code (well most of X actually); we
> could probably clean up the logic a little. If this works I'll send it
> out to the Xorg list for review.
Yes, thanks for restructuring it, I was rather itching to do so.
With the one small change below which I think you'll approve,
your patch works for me on the G5 - but I've not tested it on
other (x86) machines which were already working.
Hugh
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
> diff --git a/hw/xfree86/os-support/bus/linuxPci.c b/hw/xfree86/os-support/bus/linuxPci.c
> index 263fd8f..fa0fc0a 100644
> --- a/hw/xfree86/os-support/bus/linuxPci.c
> +++ b/hw/xfree86/os-support/bus/linuxPci.c
> @@ -471,23 +471,18 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct pci_device *dev,
> int fd = -1;
> pointer addr;
>
> - /*
> - * We use /proc/bus/pci on non-legacy addresses or if the Linux sysfs
> - * legacy_mem interface is unavailable.
> - */
> - if ((Base > 1024*1024) || ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0))
> - return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
> - PCIIOC_MMAP_IS_MEM);
> - else
> - addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
> -
> - if (fd >= 0)
> - close(fd);
> - if (addr == NULL || addr == MAP_FAILED) {
> - perror("mmap failure");
> - FatalError("xf86MapDomainMem(): mmap() failure\n");
> + if (Base <= 1024*1024) {
> + /* Try legacy_mem (may not be available or implemented) */
> + if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
>=
> + addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
> + close(fd);
> + if (addr && addr != MAP_FAILED)
> + return addr;
> + }
> }
> - return addr;
> +
> + /* Fall back to old method if legacy_mem fails or Base >= 1M */
> + return linuxMapPci(ScreenNum, Flags, dev, Base, Size, PCIIOC_MMAP_IS_MEM);
> }
>
> /**
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-07 0:50 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-07 0:50 UTC (permalink / raw)
To: Jesse Barnes
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Fri, 6 Feb 2009, Jesse Barnes wrote:
>
> Yeah that should work. I always hated this code (well most of X actually); we
> could probably clean up the logic a little. If this works I'll send it
> out to the Xorg list for review.
Yes, thanks for restructuring it, I was rather itching to do so.
With the one small change below which I think you'll approve,
your patch works for me on the G5 - but I've not tested it on
other (x86) machines which were already working.
Hugh
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>
> diff --git a/hw/xfree86/os-support/bus/linuxPci.c b/hw/xfree86/os-support/bus/linuxPci.c
> index 263fd8f..fa0fc0a 100644
> --- a/hw/xfree86/os-support/bus/linuxPci.c
> +++ b/hw/xfree86/os-support/bus/linuxPci.c
> @@ -471,23 +471,18 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct pci_device *dev,
> int fd = -1;
> pointer addr;
>
> - /*
> - * We use /proc/bus/pci on non-legacy addresses or if the Linux sysfs
> - * legacy_mem interface is unavailable.
> - */
> - if ((Base > 1024*1024) || ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0))
> - return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
> - PCIIOC_MMAP_IS_MEM);
> - else
> - addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
> -
> - if (fd >= 0)
> - close(fd);
> - if (addr == NULL || addr == MAP_FAILED) {
> - perror("mmap failure");
> - FatalError("xf86MapDomainMem(): mmap() failure\n");
> + if (Base <= 1024*1024) {
> + /* Try legacy_mem (may not be available or implemented) */
> + if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
>=
> + addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
> + close(fd);
> + if (addr && addr != MAP_FAILED)
> + return addr;
> + }
> }
> - return addr;
> +
> + /* Fall back to old method if legacy_mem fails or Base >= 1M */
> + return linuxMapPci(ScreenNum, Flags, dev, Base, Size, PCIIOC_MMAP_IS_MEM);
> }
>
> /**
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 22:45 ` Jesse Barnes
0 siblings, 0 replies; 243+ messages in thread
From: Jesse Barnes @ 2009-02-06 22:45 UTC (permalink / raw)
To: Hugh Dickins
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Friday, February 6, 2009 2:17 pm Hugh Dickins wrote:
> On Fri, 6 Feb 2009, Jesse Barnes wrote:
> > Hugh, did you get a chance to try my X patch (w/o Ben's patch applied)?
> > If it also works, we should apply it to X too, if only to make porting to
> > future platforms a little easier.
>
> I have tried it now: I'm sorry to say it does not work, fails with
> (WW) xf86MapDomainMem(): mmap() failure: No such device or address
>
> Fatal server error:
> AddScreen/ScreenInit failed for driver 0
>
> The "mmap() failure" line is of course the one you're intentionally
> showing, but the AddScreen/ScreenInit one is not what you want.
> Presumably it demands something other than a NULL addr returned,
> but I haven't followed that up at all.
>
> I have tried the obvious patch below, which reverts to the original
> code if the mmap fails: this works, but presumably negates much of
> what you intended to achieve with legacy_mem.
>
> Easy for me to try something else, fire away.
>
> Hugh
>
> --- a/hw/xfree86/os-support/bus/linuxPci.c
> +++ b/hw/xfree86/os-support/bus/linuxPci.c
> @@ -501,8 +501,10 @@ xf86MapDomainMemory(int ScreenNum, int F
> if (fd >= 0)
> close(fd);
> if (addr == NULL || addr == MAP_FAILED) {
> - perror("mmap failure");
> - FatalError("xf86MapDomainMem(): mmap() failure\n");
> + xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
> + strerror(errno));
> + return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
> + PCIIOC_MMAP_IS_MEM);
> }
> return addr;
> }
Yeah that should work. I always hated this code (well most of X actually); we
could probably clean up the logic a little. If this works I'll send it
out to the Xorg list for review.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/hw/xfree86/os-support/bus/linuxPci.c b/hw/xfree86/os-support/bus/linuxPci.c
index 263fd8f..fa0fc0a 100644
--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -471,23 +471,18 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct pci_device *dev,
int fd = -1;
pointer addr;
- /*
- * We use /proc/bus/pci on non-legacy addresses or if the Linux sysfs
- * legacy_mem interface is unavailable.
- */
- if ((Base > 1024*1024) || ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0))
- return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
- PCIIOC_MMAP_IS_MEM);
- else
- addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
-
- if (fd >= 0)
- close(fd);
- if (addr == NULL || addr == MAP_FAILED) {
- perror("mmap failure");
- FatalError("xf86MapDomainMem(): mmap() failure\n");
+ if (Base <= 1024*1024) {
+ /* Try legacy_mem (may not be available or implemented) */
+ if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
+ addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
+ close(fd);
+ if (addr && addr != MAP_FAILED)
+ return addr;
+ }
}
- return addr;
+
+ /* Fall back to old method if legacy_mem fails or Base >= 1M */
+ return linuxMapPci(ScreenNum, Flags, dev, Base, Size, PCIIOC_MMAP_IS_MEM);
}
/**
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 22:45 ` Jesse Barnes
0 siblings, 0 replies; 243+ messages in thread
From: Jesse Barnes @ 2009-02-06 22:45 UTC (permalink / raw)
To: Hugh Dickins
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Friday, February 6, 2009 2:17 pm Hugh Dickins wrote:
> On Fri, 6 Feb 2009, Jesse Barnes wrote:
> > Hugh, did you get a chance to try my X patch (w/o Ben's patch applied)?
> > If it also works, we should apply it to X too, if only to make porting to
> > future platforms a little easier.
>
> I have tried it now: I'm sorry to say it does not work, fails with
> (WW) xf86MapDomainMem(): mmap() failure: No such device or address
>
> Fatal server error:
> AddScreen/ScreenInit failed for driver 0
>
> The "mmap() failure" line is of course the one you're intentionally
> showing, but the AddScreen/ScreenInit one is not what you want.
> Presumably it demands something other than a NULL addr returned,
> but I haven't followed that up at all.
>
> I have tried the obvious patch below, which reverts to the original
> code if the mmap fails: this works, but presumably negates much of
> what you intended to achieve with legacy_mem.
>
> Easy for me to try something else, fire away.
>
> Hugh
>
> --- a/hw/xfree86/os-support/bus/linuxPci.c
> +++ b/hw/xfree86/os-support/bus/linuxPci.c
> @@ -501,8 +501,10 @@ xf86MapDomainMemory(int ScreenNum, int F
> if (fd >= 0)
> close(fd);
> if (addr == NULL || addr == MAP_FAILED) {
> - perror("mmap failure");
> - FatalError("xf86MapDomainMem(): mmap() failure\n");
> + xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
> + strerror(errno));
> + return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
> + PCIIOC_MMAP_IS_MEM);
> }
> return addr;
> }
Yeah that should work. I always hated this code (well most of X actually); we
could probably clean up the logic a little. If this works I'll send it
out to the Xorg list for review.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/hw/xfree86/os-support/bus/linuxPci.c b/hw/xfree86/os-support/bus/linuxPci.c
index 263fd8f..fa0fc0a 100644
--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -471,23 +471,18 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct pci_device *dev,
int fd = -1;
pointer addr;
- /*
- * We use /proc/bus/pci on non-legacy addresses or if the Linux sysfs
- * legacy_mem interface is unavailable.
- */
- if ((Base > 1024*1024) || ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0))
- return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
- PCIIOC_MMAP_IS_MEM);
- else
- addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
-
- if (fd >= 0)
- close(fd);
- if (addr == NULL || addr == MAP_FAILED) {
- perror("mmap failure");
- FatalError("xf86MapDomainMem(): mmap() failure\n");
+ if (Base <= 1024*1024) {
+ /* Try legacy_mem (may not be available or implemented) */
+ if ((fd = linuxOpenLegacy(dev, "legacy_mem")) < 0) {
+ addr = mmap(NULL, Size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, Base);
+ close(fd);
+ if (addr && addr != MAP_FAILED)
+ return addr;
+ }
}
- return addr;
+
+ /* Fall back to old method if legacy_mem fails or Base >= 1M */
+ return linuxMapPci(ScreenNum, Flags, dev, Base, Size, PCIIOC_MMAP_IS_MEM);
}
/**
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 22:17 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-06 22:17 UTC (permalink / raw)
To: Jesse Barnes
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Fri, 6 Feb 2009, Jesse Barnes wrote:
>
> Hugh, did you get a chance to try my X patch (w/o Ben's patch applied)? If it
> also works, we should apply it to X too, if only to make porting to future
> platforms a little easier.
I have tried it now: I'm sorry to say it does not work, fails with
(WW) xf86MapDomainMem(): mmap() failure: No such device or address
Fatal server error:
AddScreen/ScreenInit failed for driver 0
The "mmap() failure" line is of course the one you're intentionally
showing, but the AddScreen/ScreenInit one is not what you want.
Presumably it demands something other than a NULL addr returned,
but I haven't followed that up at all.
I have tried the obvious patch below, which reverts to the original
code if the mmap fails: this works, but presumably negates much of
what you intended to achieve with legacy_mem.
Easy for me to try something else, fire away.
Hugh
--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -501,8 +501,10 @@ xf86MapDomainMemory(int ScreenNum, int F
if (fd >= 0)
close(fd);
if (addr == NULL || addr == MAP_FAILED) {
- perror("mmap failure");
- FatalError("xf86MapDomainMem(): mmap() failure\n");
+ xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
+ strerror(errno));
+ return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
+ PCIIOC_MMAP_IS_MEM);
}
return addr;
}
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 22:17 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-06 22:17 UTC (permalink / raw)
To: Jesse Barnes
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Fri, 6 Feb 2009, Jesse Barnes wrote:
>
> Hugh, did you get a chance to try my X patch (w/o Ben's patch applied)? If it
> also works, we should apply it to X too, if only to make porting to future
> platforms a little easier.
I have tried it now: I'm sorry to say it does not work, fails with
(WW) xf86MapDomainMem(): mmap() failure: No such device or address
Fatal server error:
AddScreen/ScreenInit failed for driver 0
The "mmap() failure" line is of course the one you're intentionally
showing, but the AddScreen/ScreenInit one is not what you want.
Presumably it demands something other than a NULL addr returned,
but I haven't followed that up at all.
I have tried the obvious patch below, which reverts to the original
code if the mmap fails: this works, but presumably negates much of
what you intended to achieve with legacy_mem.
Easy for me to try something else, fire away.
Hugh
--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -501,8 +501,10 @@ xf86MapDomainMemory(int ScreenNum, int F
if (fd >= 0)
close(fd);
if (addr == NULL || addr == MAP_FAILED) {
- perror("mmap failure");
- FatalError("xf86MapDomainMem(): mmap() failure\n");
+ xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
+ strerror(errno));
+ return linuxMapPci(ScreenNum, Flags, dev, Base, Size,
+ PCIIOC_MMAP_IS_MEM);
}
return addr;
}
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-06 12:56 ` Hugh Dickins
(?)
@ 2009-02-06 16:49 ` Jesse Barnes
2009-02-06 22:17 ` Hugh Dickins
-1 siblings, 1 reply; 243+ messages in thread
From: Jesse Barnes @ 2009-02-06 16:49 UTC (permalink / raw)
To: Hugh Dickins
Cc: Benjamin Herrenschmidt, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List
On Friday, February 6, 2009 4:56 am Hugh Dickins wrote:
> On Fri, 6 Feb 2009, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-02-05 at 14:33 -0800, Jesse Barnes wrote:
> > > One option there would be to provide the file but just use anonymous
> > > memory to back it. X will happily think it's messing with legacy VGA
> > > memory, but it shouldn't matter that it's not actually affecting hw.
> >
> > What about this (untested) patch ?
> >
> > powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
> >
> > The new legacy_mem file in sysfs is causing problems with X on machines
> > that don't support legacy memory access. The way I initially implemented
> > it, we would fail with -ENXIO when trying to mmap it, thus exposing to
> > X that we do support the API but there is no legacy memory.
> >
> > Unfortunately, X poor error handling is causing it to fail to start when
> > it gets this error.
> >
> > This implements a workaround hack that instead maps anonymous memory
> > instead (using shmem if VM_SHARED is set, just like /dev/zero does).
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
>
> Beautiful idea, works very nicely for me.
> Put a dummy in the baby's mouth to stop it crying.
>
> I still don't understand the point of this legacy_mem file at all,
> and why X should want to mmap it, if it works so well when it's
> thus divorced from reality. But I won't worry my pretty little
> head over it any further - please don't waste your time trying
> to explain it to me!
Hugh, did you get a chance to try my X patch (w/o Ben's patch applied)? If it
also works, we should apply it to X too, if only to make porting to future
platforms a little easier.
Since you probably don't want to know, you can skip this paragraph as it
describes the motivation behind the legacy_mem file. :) The motivation for
it was to support machines with multihead video card configurations, but
which could also support multiple legacy port I/O and memory spaces (e.g. on
a per PCI domain basis). It allows X to run option ROMs on multiple devices
simultaneously, and can also help with hardware that can't route legacy space
from a given host bus to arbitrary system addresses. When we put this in
initially, Ben knew there were some platforms where legacy memory simply
wasn't available, but we figured that shouldn't be a problem, since X didn't
really *need* that space to function (most ROMs just put splash screens
there). Unfortunately in the interim, X made the lack of an mmap'able
legacy_mem file into a fatal error.
In the past, doing Linux bringup on a platform with a complex I/O topology
(sparc, ia64, alpha, etc.) usually meant doing X bring up as well, often by
adding new interfaces or hacks to X. With the legacy_mem and io files,
there's a chance that X won't have to be modified at bring up time, so in
that sense the APIs are a step forward. However that also means your
platform has to support the APIs in a way consistent with how X uses them, as
you discovered. :)
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-06 5:40 ` Benjamin Herrenschmidt
@ 2009-02-06 12:56 ` Hugh Dickins
-1 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-06 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Fri, 6 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-05 at 14:33 -0800, Jesse Barnes wrote:
>
> > One option there would be to provide the file but just use anonymous memory to
> > back it. X will happily think it's messing with legacy VGA memory, but it
> > shouldn't matter that it's not actually affecting hw.
>
> What about this (untested) patch ?
>
> powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
>
> The new legacy_mem file in sysfs is causing problems with X on machines
> that don't support legacy memory access. The way I initially implemented
> it, we would fail with -ENXIO when trying to mmap it, thus exposing to
> X that we do support the API but there is no legacy memory.
>
> Unfortunately, X poor error handling is causing it to fail to start when
> it gets this error.
>
> This implements a workaround hack that instead maps anonymous memory
> instead (using shmem if VM_SHARED is set, just like /dev/zero does).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
Beautiful idea, works very nicely for me.
Put a dummy in the baby's mouth to stop it crying.
I still don't understand the point of this legacy_mem file at all,
and why X should want to mmap it, if it works so well when it's
thus divorced from reality. But I won't worry my pretty little
head over it any further - please don't waste your time trying
to explain it to me!
Thanks,
Hugh
>
> Index: linux-work/arch/powerpc/kernel/pci-common.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci-common.c 2009-02-06 16:23:36.000000000 +1100
> +++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.000000000 +1100
> @@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
> (unsigned long long)(offset + size - 1));
>
> if (mmap_state == pci_mmap_mem) {
> - if ((offset + size) > hose->isa_mem_size)
> - return -ENXIO;
> + /* Hack alert !
> + *
> + * Because X is lame and can fail starting if it gets an error trying
> + * to mmap legacy_mem (instead of just moving on without legacy memory
> + * access) we fake it here by giving it anonymous memory, effectively
> + * behaving just like /dev/zero
> + */
> + if ((offset + size) > hose->isa_mem_size) {
> + printk(KERN_DEBUG
> + "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n",
> + current->comm, current->pid, pci_domain_nr(bus), bus->number);
> + if (vma->vm_flags & VM_SHARED)
> + return shmem_zero_setup(vma);
> + return 0;
> + }
> offset += hose->isa_mem_phys;
> } else {
> unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 12:56 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-06 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Fri, 6 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-05 at 14:33 -0800, Jesse Barnes wrote:
>
> > One option there would be to provide the file but just use anonymous memory to
> > back it. X will happily think it's messing with legacy VGA memory, but it
> > shouldn't matter that it's not actually affecting hw.
>
> What about this (untested) patch ?
>
> powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
>
> The new legacy_mem file in sysfs is causing problems with X on machines
> that don't support legacy memory access. The way I initially implemented
> it, we would fail with -ENXIO when trying to mmap it, thus exposing to
> X that we do support the API but there is no legacy memory.
>
> Unfortunately, X poor error handling is causing it to fail to start when
> it gets this error.
>
> This implements a workaround hack that instead maps anonymous memory
> instead (using shmem if VM_SHARED is set, just like /dev/zero does).
>
> Signed-off-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> ---
Beautiful idea, works very nicely for me.
Put a dummy in the baby's mouth to stop it crying.
I still don't understand the point of this legacy_mem file at all,
and why X should want to mmap it, if it works so well when it's
thus divorced from reality. But I won't worry my pretty little
head over it any further - please don't waste your time trying
to explain it to me!
Thanks,
Hugh
>
> Index: linux-work/arch/powerpc/kernel/pci-common.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci-common.c 2009-02-06 16:23:36.000000000 +1100
> +++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.000000000 +1100
> @@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
> (unsigned long long)(offset + size - 1));
>
> if (mmap_state == pci_mmap_mem) {
> - if ((offset + size) > hose->isa_mem_size)
> - return -ENXIO;
> + /* Hack alert !
> + *
> + * Because X is lame and can fail starting if it gets an error trying
> + * to mmap legacy_mem (instead of just moving on without legacy memory
> + * access) we fake it here by giving it anonymous memory, effectively
> + * behaving just like /dev/zero
> + */
> + if ((offset + size) > hose->isa_mem_size) {
> + printk(KERN_DEBUG
> + "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n",
> + current->comm, current->pid, pci_domain_nr(bus), bus->number);
> + if (vma->vm_flags & VM_SHARED)
> + return shmem_zero_setup(vma);
> + return 0;
> + }
> offset += hose->isa_mem_phys;
> } else {
> unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 6:01 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-06 6:01 UTC (permalink / raw)
To: Dave Airlie
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
> I think the correct answer is the ugly one, try again.
Well... it's a fairly recent damage in X which is why I was somewhat
hoping that it wasn't too widespread it couldn't be contained
before the kernel got butchered :-)
But I'll just stick anonymous memory in there instead, it should be
trivial enough.
> Add a new legacy_mem interface that works cleanly, update X to use it,
> leave the old
> broken one broken as it for older X to use.
:-)
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 6:01 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-06 6:01 UTC (permalink / raw)
To: Dave Airlie
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
> I think the correct answer is the ugly one, try again.
Well... it's a fairly recent damage in X which is why I was somewhat
hoping that it wasn't too widespread it couldn't be contained
before the kernel got butchered :-)
But I'll just stick anonymous memory in there instead, it should be
trivial enough.
> Add a new legacy_mem interface that works cleanly, update X to use it,
> leave the old
> broken one broken as it for older X to use.
:-)
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 5:40 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-06 5:40 UTC (permalink / raw)
To: Hugh Dickins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Thu, 2009-02-05 at 14:33 -0800, Jesse Barnes wrote:
> One option there would be to provide the file but just use anonymous memory to
> back it. X will happily think it's messing with legacy VGA memory, but it
> shouldn't matter that it's not actually affecting hw.
What about this (untested) patch ?
powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
The new legacy_mem file in sysfs is causing problems with X on machines
that don't support legacy memory access. The way I initially implemented
it, we would fail with -ENXIO when trying to mmap it, thus exposing to
X that we do support the API but there is no legacy memory.
Unfortunately, X poor error handling is causing it to fail to start when
it gets this error.
This implements a workaround hack that instead maps anonymous memory
instead (using shmem if VM_SHARED is set, just like /dev/zero does).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/arch/powerpc/kernel/pci-common.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci-common.c 2009-02-06 16:23:36.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.000000000 +1100
@@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
(unsigned long long)(offset + size - 1));
if (mmap_state == pci_mmap_mem) {
- if ((offset + size) > hose->isa_mem_size)
- return -ENXIO;
+ /* Hack alert !
+ *
+ * Because X is lame and can fail starting if it gets an error trying
+ * to mmap legacy_mem (instead of just moving on without legacy memory
+ * access) we fake it here by giving it anonymous memory, effectively
+ * behaving just like /dev/zero
+ */
+ if ((offset + size) > hose->isa_mem_size) {
+ printk(KERN_DEBUG
+ "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n",
+ current->comm, current->pid, pci_domain_nr(bus), bus->number);
+ if (vma->vm_flags & VM_SHARED)
+ return shmem_zero_setup(vma);
+ return 0;
+ }
offset += hose->isa_mem_phys;
} else {
unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-06 5:40 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-06 5:40 UTC (permalink / raw)
To: Hugh Dickins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Thu, 2009-02-05 at 14:33 -0800, Jesse Barnes wrote:
> One option there would be to provide the file but just use anonymous memory to
> back it. X will happily think it's messing with legacy VGA memory, but it
> shouldn't matter that it's not actually affecting hw.
What about this (untested) patch ?
powerpc/pci: mmap anonymous memory when legacy_mem doesn't exist
The new legacy_mem file in sysfs is causing problems with X on machines
that don't support legacy memory access. The way I initially implemented
it, we would fail with -ENXIO when trying to mmap it, thus exposing to
X that we do support the API but there is no legacy memory.
Unfortunately, X poor error handling is causing it to fail to start when
it gets this error.
This implements a workaround hack that instead maps anonymous memory
instead (using shmem if VM_SHARED is set, just like /dev/zero does).
Signed-off-by: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
---
Index: linux-work/arch/powerpc/kernel/pci-common.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/pci-common.c 2009-02-06 16:23:36.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2009-02-06 16:30:32.000000000 +1100
@@ -561,8 +561,21 @@ int pci_mmap_legacy_page_range(struct pc
(unsigned long long)(offset + size - 1));
if (mmap_state == pci_mmap_mem) {
- if ((offset + size) > hose->isa_mem_size)
- return -ENXIO;
+ /* Hack alert !
+ *
+ * Because X is lame and can fail starting if it gets an error trying
+ * to mmap legacy_mem (instead of just moving on without legacy memory
+ * access) we fake it here by giving it anonymous memory, effectively
+ * behaving just like /dev/zero
+ */
+ if ((offset + size) > hose->isa_mem_size) {
+ printk(KERN_DEBUG
+ "Process %s (pid:%d) mapped non-existing PCI legacy memory for 0%04x:%02x\n",
+ current->comm, current->pid, pci_domain_nr(bus), bus->number);
+ if (vma->vm_flags & VM_SHARED)
+ return shmem_zero_setup(vma);
+ return 0;
+ }
offset += hose->isa_mem_phys;
} else {
unsigned long io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-05 23:57 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-05 23:57 UTC (permalink / raw)
To: Jesse Barnes
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
> No, sorry, but I just took a look and as long as the various callers can
> handle it (haven't checked), this patch would work.
>
> > The second problem is that if I just don't expose the legacy_mem file,
> > then X has no way to know whether the kernel doesn't support the
> > interface or whether the HW doesn't support legacy memory access. So X
> > will fallback to whacking /dev/mem which is even more bogus. At least
> > that's what I remember from last I looked at that part of X code.
> >
> > It should be a trivial fix on X side tho.
>
> One option there would be to provide the file but just use anonymous memory to
> back it. X will happily think it's messing with legacy VGA memory, but it
> shouldn't matter that it's not actually affecting hw.
That might be the best approach ... I'll have a look.
Ben.
> diff --git a/hw/xfree86/os-support/bus/linuxPci.c
> b/hw/xfree86/os-support/bus/li
> index 263fd8f..5d2da32 100644
> --- a/hw/xfree86/os-support/bus/linuxPci.c
> +++ b/hw/xfree86/os-support/bus/linuxPci.c
> @@ -484,8 +484,9 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct
> pci_dev
> if (fd >= 0)
> close(fd);
> if (addr == NULL || addr == MAP_FAILED) {
> - perror("mmap failure");
> - FatalError("xf86MapDomainMem(): mmap() failure\n");
> + xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
> + strerror(errno));
> + return NULL;
> }
> return addr;
> }
>
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-05 23:57 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-05 23:57 UTC (permalink / raw)
To: Jesse Barnes
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
> No, sorry, but I just took a look and as long as the various callers can
> handle it (haven't checked), this patch would work.
>
> > The second problem is that if I just don't expose the legacy_mem file,
> > then X has no way to know whether the kernel doesn't support the
> > interface or whether the HW doesn't support legacy memory access. So X
> > will fallback to whacking /dev/mem which is even more bogus. At least
> > that's what I remember from last I looked at that part of X code.
> >
> > It should be a trivial fix on X side tho.
>
> One option there would be to provide the file but just use anonymous memory to
> back it. X will happily think it's messing with legacy VGA memory, but it
> shouldn't matter that it's not actually affecting hw.
That might be the best approach ... I'll have a look.
Ben.
> diff --git a/hw/xfree86/os-support/bus/linuxPci.c
> b/hw/xfree86/os-support/bus/li
> index 263fd8f..5d2da32 100644
> --- a/hw/xfree86/os-support/bus/linuxPci.c
> +++ b/hw/xfree86/os-support/bus/linuxPci.c
> @@ -484,8 +484,9 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct
> pci_dev
> if (fd >= 0)
> close(fd);
> if (addr == NULL || addr == MAP_FAILED) {
> - perror("mmap failure");
> - FatalError("xf86MapDomainMem(): mmap() failure\n");
> + xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
> + strerror(errno));
> + return NULL;
> }
> return addr;
> }
>
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-05 21:05 ` Benjamin Herrenschmidt
` (2 preceding siblings ...)
(?)
@ 2009-02-05 22:33 ` Jesse Barnes
2009-02-05 23:57 ` Benjamin Herrenschmidt
2009-02-06 5:40 ` Benjamin Herrenschmidt
-1 siblings, 2 replies; 243+ messages in thread
From: Jesse Barnes @ 2009-02-05 22:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List
On Thursday, February 5, 2009 1:05 pm Benjamin Herrenschmidt wrote:
> > Is it a really a bug in X, or a misunderstanding between X and
> > the kernel as to what existence of the legacy_mem file implies?
> >
> > I may have got this quite wrong, but to me it appears that X assumes
> > that existence of the legacy_mem file implies that it will be useful;
> > whereas the kernel thinks it can make the legacy_mem file available,
> > even if it cannot be used for mmapping mem - which is its sole purpose?
> >
> > What if pci_create_legacy_files() were to call some new verification
> > routine, and only create the legacy_mem file if it would be usable?
> > (But perhaps that cannot be known at the time it needs to be created.)
>
> Well, first X should certainly not -fail- to launch if it fails to map
> legacy memory, which is generally not useful anyway. That's where the
> bug is. Jesse, did you have a chance to fix that yet or should I give it
> a go ?
No, sorry, but I just took a look and as long as the various callers can
handle it (haven't checked), this patch would work.
> The second problem is that if I just don't expose the legacy_mem file,
> then X has no way to know whether the kernel doesn't support the
> interface or whether the HW doesn't support legacy memory access. So X
> will fallback to whacking /dev/mem which is even more bogus. At least
> that's what I remember from last I looked at that part of X code.
>
> It should be a trivial fix on X side tho.
One option there would be to provide the file but just use anonymous memory to
back it. X will happily think it's messing with legacy VGA memory, but it
shouldn't matter that it's not actually affecting hw.
diff --git a/hw/xfree86/os-support/bus/linuxPci.c
b/hw/xfree86/os-support/bus/li
index 263fd8f..5d2da32 100644
--- a/hw/xfree86/os-support/bus/linuxPci.c
+++ b/hw/xfree86/os-support/bus/linuxPci.c
@@ -484,8 +484,9 @@ xf86MapDomainMemory(int ScreenNum, int Flags, struct
pci_dev
if (fd >= 0)
close(fd);
if (addr == NULL || addr == MAP_FAILED) {
- perror("mmap failure");
- FatalError("xf86MapDomainMem(): mmap() failure\n");
+ xf86Msg(X_WARNING, "xf86MapDomainMem(): mmap() failure: %s\n",
+ strerror(errno));
+ return NULL;
}
return addr;
}
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply related [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-05 21:05 ` Benjamin Herrenschmidt
@ 2009-02-05 21:45 ` Dave Airlie
-1 siblings, 0 replies; 243+ messages in thread
From: Dave Airlie @ 2009-02-05 21:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Fri, Feb 6, 2009 at 7:05 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
>> Is it a really a bug in X, or a misunderstanding between X and
>> the kernel as to what existence of the legacy_mem file implies?
>>
>> I may have got this quite wrong, but to me it appears that X assumes
>> that existence of the legacy_mem file implies that it will be useful;
>> whereas the kernel thinks it can make the legacy_mem file available,
>> even if it cannot be used for mmapping mem - which is its sole purpose?
>>
>> What if pci_create_legacy_files() were to call some new verification
>> routine, and only create the legacy_mem file if it would be usable?
>> (But perhaps that cannot be known at the time it needs to be created.)
>
> Well, first X should certainly not -fail- to launch if it fails to map
> legacy memory, which is generally not useful anyway. That's where the
> bug is. Jesse, did you have a chance to fix that yet or should I give it
> a go ?
>
> The second problem is that if I just don't expose the legacy_mem file,
> then X has no way to know whether the kernel doesn't support the
> interface or whether the HW doesn't support legacy memory access. So X
> will fallback to whacking /dev/mem which is even more bogus. At least
> that's what I remember from last I looked at that part of X code.
>
> It should be a trivial fix on X side tho.
I think the correct answer is the ugly one, try again.
Add a new legacy_mem interface that works cleanly, update X to use it,
leave the old
broken one broken as it for older X to use.
Dave.
>
> Cheers,
> Ben.
>
>
> --
> 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/
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-05 21:45 ` Dave Airlie
0 siblings, 0 replies; 243+ messages in thread
From: Dave Airlie @ 2009-02-05 21:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Hugh Dickins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Fri, Feb 6, 2009 at 7:05 AM, Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
>
>> Is it a really a bug in X, or a misunderstanding between X and
>> the kernel as to what existence of the legacy_mem file implies?
>>
>> I may have got this quite wrong, but to me it appears that X assumes
>> that existence of the legacy_mem file implies that it will be useful;
>> whereas the kernel thinks it can make the legacy_mem file available,
>> even if it cannot be used for mmapping mem - which is its sole purpose?
>>
>> What if pci_create_legacy_files() were to call some new verification
>> routine, and only create the legacy_mem file if it would be usable?
>> (But perhaps that cannot be known at the time it needs to be created.)
>
> Well, first X should certainly not -fail- to launch if it fails to map
> legacy memory, which is generally not useful anyway. That's where the
> bug is. Jesse, did you have a chance to fix that yet or should I give it
> a go ?
>
> The second problem is that if I just don't expose the legacy_mem file,
> then X has no way to know whether the kernel doesn't support the
> interface or whether the HW doesn't support legacy memory access. So X
> will fallback to whacking /dev/mem which is even more bogus. At least
> that's what I remember from last I looked at that part of X code.
>
> It should be a trivial fix on X side tho.
I think the correct answer is the ugly one, try again.
Add a new legacy_mem interface that works cleanly, update X to use it,
leave the old
broken one broken as it for older X to use.
Dave.
>
> Cheers,
> Ben.
>
>
> --
> 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/
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-05 21:05 ` Benjamin Herrenschmidt
@ 2009-02-05 21:20 ` Hugh Dickins
-1 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-05 21:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Fri, 6 Feb 2009, Benjamin Herrenschmidt wrote:
>
> It should be a trivial fix on X side tho.
It will be unusual to require users of a new kernel to install a new X.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-05 21:20 ` Hugh Dickins
0 siblings, 0 replies; 243+ messages in thread
From: Hugh Dickins @ 2009-02-05 21:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Fri, 6 Feb 2009, Benjamin Herrenschmidt wrote:
>
> It should be a trivial fix on X side tho.
It will be unusual to require users of a new kernel to install a new X.
Hugh
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-05 21:05 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-05 21:05 UTC (permalink / raw)
To: Hugh Dickins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
> Is it a really a bug in X, or a misunderstanding between X and
> the kernel as to what existence of the legacy_mem file implies?
>
> I may have got this quite wrong, but to me it appears that X assumes
> that existence of the legacy_mem file implies that it will be useful;
> whereas the kernel thinks it can make the legacy_mem file available,
> even if it cannot be used for mmapping mem - which is its sole purpose?
>
> What if pci_create_legacy_files() were to call some new verification
> routine, and only create the legacy_mem file if it would be usable?
> (But perhaps that cannot be known at the time it needs to be created.)
Well, first X should certainly not -fail- to launch if it fails to map
legacy memory, which is generally not useful anyway. That's where the
bug is. Jesse, did you have a chance to fix that yet or should I give it
a go ?
The second problem is that if I just don't expose the legacy_mem file,
then X has no way to know whether the kernel doesn't support the
interface or whether the HW doesn't support legacy memory access. So X
will fallback to whacking /dev/mem which is even more bogus. At least
that's what I remember from last I looked at that part of X code.
It should be a trivial fix on X side tho.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-05 21:05 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-05 21:05 UTC (permalink / raw)
To: Hugh Dickins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
> Is it a really a bug in X, or a misunderstanding between X and
> the kernel as to what existence of the legacy_mem file implies?
>
> I may have got this quite wrong, but to me it appears that X assumes
> that existence of the legacy_mem file implies that it will be useful;
> whereas the kernel thinks it can make the legacy_mem file available,
> even if it cannot be used for mmapping mem - which is its sole purpose?
>
> What if pci_create_legacy_files() were to call some new verification
> routine, and only create the legacy_mem file if it would be usable?
> (But perhaps that cannot be known at the time it needs to be created.)
Well, first X should certainly not -fail- to launch if it fails to map
legacy memory, which is generally not useful anyway. That's where the
bug is. Jesse, did you have a chance to fix that yet or should I give it
a go ?
The second problem is that if I just don't expose the legacy_mem file,
then X has no way to know whether the kernel doesn't support the
interface or whether the HW doesn't support legacy memory access. So X
will fallback to whacking /dev/mem which is even more bogus. At least
that's what I remember from last I looked at that part of X code.
It should be a trivial fix on X side tho.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-04 23:48 ` Benjamin Herrenschmidt
(?)
@ 2009-02-05 17:23 ` Hugh Dickins
2009-02-05 21:05 ` Benjamin Herrenschmidt
-1 siblings, 1 reply; 243+ messages in thread
From: Hugh Dickins @ 2009-02-05 17:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Jesse Barnes
On Thu, 5 Feb 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-02-04 at 11:24 +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
>
> I still don't know what's the best way to handle that one... the bug is
> in X and I don't see a way to work around it without removing support
> for legacy memory access from the kernel :-( Or doing it in a way that
> doesn't allow userspace to differenciate between the kernel not
> supporting it vs. the HW not supporting it, causing X to fallback to
> even more broken crap.
Is it a really a bug in X, or a misunderstanding between X and
the kernel as to what existence of the legacy_mem file implies?
I may have got this quite wrong, but to me it appears that X assumes
that existence of the legacy_mem file implies that it will be useful;
whereas the kernel thinks it can make the legacy_mem file available,
even if it cannot be used for mmapping mem - which is its sole purpose?
What if pci_create_legacy_files() were to call some new verification
routine, and only create the legacy_mem file if it would be usable?
(But perhaps that cannot be known at the time it needs to be created.)
Hugh
>
> I'll try to find out the extent of the X problem and whether that's
> fixable in a way that can hit distros.
>
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
> > Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
> > Submitter : Hugh Dickins <hugh@veritas.com>
> > Date : 2009-01-21 21:12 (15 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
> > References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
> > Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-04 10:24 ` Rafael J. Wysocki
@ 2009-02-04 23:48 ` Benjamin Herrenschmidt
-1 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-04 23:48 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Hugh Dickins,
Jesse Barnes
On Wed, 2009-02-04 at 11:24 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
I still don't know what's the best way to handle that one... the bug is
in X and I don't see a way to work around it without removing support
for legacy memory access from the kernel :-( Or doing it in a way that
doesn't allow userspace to differenciate between the kernel not
supporting it vs. the HW not supporting it, causing X to fallback to
even more broken crap.
I'll try to find out the extent of the X problem and whether that's
fixable in a way that can hit distros.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
> Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
> Submitter : Hugh Dickins <hugh@veritas.com>
> Date : 2009-01-21 21:12 (15 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
> References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
> Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-04 23:48 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 243+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-04 23:48 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Hugh Dickins,
Jesse Barnes
On Wed, 2009-02-04 at 11:24 +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
I still don't know what's the best way to handle that one... the bug is
in X and I don't see a way to work around it without removing support
for legacy memory access from the kernel :-( Or doing it in a way that
doesn't allow userspace to differenciate between the kernel not
supporting it vs. the HW not supporting it, causing X to fallback to
even more broken crap.
I'll try to find out the extent of the X problem and whether that's
fixable in a way that can hit distros.
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
> Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
> Submitter : Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
> Date : 2009-01-21 21:12 (15 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
> References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
> Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-04 10:21 2.6.29-rc3-git6: " Rafael J. Wysocki
@ 2009-02-04 10:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-04 10:24 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Hugh Dickins, Jesse Barnes
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh@veritas.com>
Date : 2009-01-21 21:12 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
* [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-04 10:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 243+ messages in thread
From: Rafael J. Wysocki @ 2009-02-04 10:24 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Hugh Dickins, Jesse Barnes
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Date : 2009-01-21 21:12 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
^ permalink raw reply [flat|nested] 243+ messages in thread
end of thread, other threads:[~2009-02-22 20:47 UTC | newest]
Thread overview: 243+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
2009-02-08 19:06 ` [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29? Rafael J. Wysocki
2009-02-08 19:06 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12441] Xorg can't use dri on radeon X1950 AGP Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12419] possible circular locking dependency on i915 dma Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12418] Repeated ioctl(4, 0x40046445, ..) loop in glxgears Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12491] i915 lockdep warning Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12444] X hangs following switch from radeonfb console - Bisected Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12490] ath5k related kernel panic in 2.6.29-rc1 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12497] new barrier warnings " Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12494] Sony backlight regression from 2.6.28 to 29-rc Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12496] swsusp cannot find resume device (sometimes) Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 0:38 ` Arjan van de Ven
2009-02-09 0:38 ` Arjan van de Ven
2009-02-09 2:27 ` Greg KH
2009-02-09 2:27 ` Greg KH
2009-02-09 23:46 ` Rafael J. Wysocki
2009-02-09 23:46 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12501] build bug in eeepc-laptop.c Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12502] pipe_read oops on sh Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 22:12 ` Ingo Molnar
2009-02-08 22:12 ` Ingo Molnar
2009-02-09 0:40 ` Rafael J. Wysocki
2009-02-09 0:40 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12499] Problem with using bluetooth adaper connected to usb port Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12571] Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc* Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 23:38 ` Mikael Pettersson
2009-02-08 23:38 ` Mikael Pettersson
2009-02-09 0:39 ` Rafael J. Wysocki
2009-02-09 0:39 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12510] 2.6.29-rc2 dies on startup Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12551] end_request: I/O error, dev cciss/c0d0, sector 87435720 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12574] possible circular locking dependency detected Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 13:59 ` Michael S. Tsirkin
2009-02-09 13:59 ` Michael S. Tsirkin
2009-02-10 22:37 ` Michael S. Tsirkin
2009-02-10 22:37 ` Michael S. Tsirkin
2009-02-10 22:41 ` Eric Anholt
2009-02-10 22:41 ` Eric Anholt
2009-02-11 7:10 ` Thomas Hellström
2009-02-11 7:10 ` Thomas Hellström
2009-02-08 19:21 ` [Bug #12600] i915 lockdep warning Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 1:12 ` Roland Dreier
2009-02-09 1:12 ` Roland Dreier
2009-02-09 17:21 ` Bob Copeland
2009-02-09 17:21 ` Bob Copeland
2009-02-08 19:21 ` [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-10 16:28 ` Jan Kara
2009-02-10 16:28 ` Jan Kara
2009-02-12 1:47 ` Nick Piggin
2009-02-12 1:47 ` Nick Piggin
2009-02-12 2:02 ` Linus Torvalds
2009-02-12 2:02 ` Linus Torvalds
2009-02-12 3:34 ` Nick Piggin
2009-02-12 3:34 ` Nick Piggin
2009-02-12 14:32 ` Jan Kara
2009-02-12 14:32 ` Jan Kara
2009-02-14 14:29 ` Theodore Tso
2009-02-14 14:29 ` Theodore Tso
2009-02-14 19:53 ` Rafael J. Wysocki
2009-02-14 19:53 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12610] sync-Regression in 2.6.28.2? Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12606] fb_mmap: circular locking dependency on hibernation Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 22:00 ` Andrea Righi
2009-02-08 22:00 ` Andrea Righi
2009-02-08 22:06 ` Rafael J. Wysocki
2009-02-08 22:06 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 10:24 ` Hugh Dickins
2009-02-09 10:24 ` Hugh Dickins
2009-02-08 19:21 ` [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 10:25 ` Hugh Dickins
2009-02-09 10:25 ` Hugh Dickins
2009-02-08 19:21 ` [Bug #12615] boot hangs while bringing up gianfar ethernet Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12617] unable to compile e100 firmware into kernel Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12613] [Suspend regression][DRM, RADEON] Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 22:07 ` etienne
2009-02-08 22:07 ` etienne
2009-02-08 22:11 ` Rafael J. Wysocki
2009-02-08 22:11 ` Rafael J. Wysocki
2009-02-09 2:26 ` Dave Airlie
2009-02-09 2:26 ` Dave Airlie
2009-02-09 18:08 ` etienne
2009-02-09 18:08 ` etienne
2009-02-09 19:31 ` etienne
2009-02-09 19:31 ` etienne
2009-02-09 5:50 ` Soeren Sonnenburg
2009-02-09 5:50 ` Soeren Sonnenburg
2009-02-08 19:21 ` [Bug #12650] Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12618] hackbench [pthread mode] regression with 2.6.29-rc3 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12649] Early crash " Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12656] iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 4:23 ` Herbert Xu
2009-02-09 4:23 ` Herbert Xu
2009-02-14 22:35 ` Rafael J. Wysocki
2009-02-14 22:35 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12660] Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12659] Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022) Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12662] linux 2.6.29-rc3 kernel failure with mptsas Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 10:17 ` wixor
2009-02-09 10:17 ` wixor
2009-02-14 22:39 ` Rafael J. Wysocki
2009-02-14 22:39 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12666] Build failure with latest -git: btrfs on ppc64 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 21:53 ` Kyle McMartin
2009-02-08 21:53 ` Kyle McMartin
2009-02-08 22:08 ` Rafael J. Wysocki
2009-02-10 20:00 ` Chuck Ebbert
2009-02-10 20:00 ` Chuck Ebbert
2009-02-08 19:21 ` [Bug #12668] USB flash disk surprise disconnect Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12663] Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended) Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 7:53 ` Paul Collins
2009-02-09 7:53 ` Paul Collins
2009-02-09 9:18 ` Ingo Molnar
2009-02-09 9:18 ` Ingo Molnar
2009-02-14 22:42 ` Rafael J. Wysocki
2009-02-14 22:42 ` Rafael J. Wysocki
2009-02-16 7:17 ` Paul Collins
2009-02-16 7:17 ` Paul Collins
2009-02-16 9:10 ` Benjamin Herrenschmidt
2009-02-16 9:10 ` Benjamin Herrenschmidt
2009-02-16 10:47 ` Paul Collins
2009-02-16 10:47 ` Paul Collins
2009-02-19 8:27 ` Paul Collins
2009-02-19 8:27 ` Paul Collins
2009-02-19 8:38 ` Benjamin Herrenschmidt
2009-02-19 8:38 ` Benjamin Herrenschmidt
2009-02-19 13:00 ` Rafael J. Wysocki
2009-02-19 13:00 ` Rafael J. Wysocki
2009-02-19 21:47 ` Benjamin Herrenschmidt
2009-02-19 21:47 ` Benjamin Herrenschmidt
2009-02-19 22:08 ` Rafael J. Wysocki
2009-02-19 22:08 ` Rafael J. Wysocki
2009-02-19 20:17 ` Thomas Gleixner
2009-02-19 20:17 ` Thomas Gleixner
2009-02-19 21:23 ` Rafael J. Wysocki
2009-02-19 21:23 ` Rafael J. Wysocki
2009-02-19 21:51 ` Benjamin Herrenschmidt
2009-02-19 21:51 ` Benjamin Herrenschmidt
2009-02-22 19:31 ` Thomas Gleixner
2009-02-22 19:31 ` Thomas Gleixner
2009-02-22 20:46 ` Benjamin Herrenschmidt
2009-02-22 20:46 ` Benjamin Herrenschmidt
2009-02-09 10:32 ` Thomas Gleixner
2009-02-09 10:32 ` Thomas Gleixner
2009-02-08 19:21 ` [Bug #12671] uvc_status_cleanup(): undefined reference to `input_unregister_device' Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` [Bug #12669] 2.6.28.4 regression: mmap fails if mlockall used Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-09 10:32 ` Hugh Dickins
2009-02-09 10:32 ` Hugh Dickins
2009-02-08 19:21 ` [Bug #12670] BUG: unable to handle kernel paging request at pin_to_kill+0x21 Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 21:55 ` 2.6.29-rc4: Reported regressions from 2.6.28 Linus Torvalds
2009-02-08 21:55 ` Linus Torvalds
2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-02-08 22:04 ` Rafael J. Wysocki
2009-02-08 22:04 ` Rafael J. Wysocki
2009-02-08 21:57 ` [linux-pm] " Alan Stern
2009-02-09 0:43 ` Rafael J. Wysocki
2009-02-09 7:36 ` Stefan Richter
2009-02-09 7:36 ` Stefan Richter
-- strict thread matches above, loose matches on Subject: below --
2009-02-04 10:21 2.6.29-rc3-git6: " Rafael J. Wysocki
2009-02-04 10:24 ` [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression Rafael J. Wysocki
2009-02-04 10:24 ` Rafael J. Wysocki
2009-02-04 23:48 ` Benjamin Herrenschmidt
2009-02-04 23:48 ` Benjamin Herrenschmidt
2009-02-05 17:23 ` Hugh Dickins
2009-02-05 21:05 ` Benjamin Herrenschmidt
2009-02-05 21:05 ` Benjamin Herrenschmidt
2009-02-05 21:20 ` Hugh Dickins
2009-02-05 21:20 ` Hugh Dickins
2009-02-05 21:45 ` Dave Airlie
2009-02-05 21:45 ` Dave Airlie
2009-02-06 6:01 ` Benjamin Herrenschmidt
2009-02-06 6:01 ` Benjamin Herrenschmidt
2009-02-05 22:33 ` Jesse Barnes
2009-02-05 23:57 ` Benjamin Herrenschmidt
2009-02-05 23:57 ` Benjamin Herrenschmidt
2009-02-06 5:40 ` Benjamin Herrenschmidt
2009-02-06 5:40 ` Benjamin Herrenschmidt
2009-02-06 12:56 ` Hugh Dickins
2009-02-06 12:56 ` Hugh Dickins
2009-02-06 16:49 ` Jesse Barnes
2009-02-06 22:17 ` Hugh Dickins
2009-02-06 22:17 ` Hugh Dickins
2009-02-06 22:45 ` Jesse Barnes
2009-02-06 22:45 ` Jesse Barnes
2009-02-07 0:50 ` Hugh Dickins
2009-02-07 0:50 ` Hugh Dickins
2009-02-07 1:47 ` Jesse Barnes
2009-02-07 3:05 ` Benjamin Herrenschmidt
2009-02-07 3:05 ` Benjamin Herrenschmidt
2009-02-07 23:15 ` Jesse Barnes
2009-02-07 23:15 ` Jesse Barnes
2009-02-07 2:51 ` Benjamin Herrenschmidt
2009-02-07 2:51 ` Benjamin Herrenschmidt
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.