2.6.29-rc3-git6: Reported regressions from 2.6.28

2.6.29-rc3-git6: Reported regressions from 2.6.28

[Rafael J. Wysocki]

[NOTES:
 * Sorry for the delay, I had to take care of my own bugs first.
 * Some of the bugs below are fixed, but I wasn't able to track the fixes down.
 * There probably are some duplicates (mostly in the DRI area), but I wasn't
   100% sure.]

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-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=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 (4 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>


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 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=123341764915181&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12616
Subject		: boot hang: async vs. kexec
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2009-01-29 13:15 (7 days old)
References	: http://lkml.org/lkml/2009/1/29/359


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 (7 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 (8 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=12611
Subject		: kernel BUG at kernel/cgroup.c:398!
Submitter	: Bharata B Rao <bharata@linux.vnet.ibm.com>
Date		: 2009-01-28 15:49 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=123315721707796&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 (9 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 (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>


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 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=123308162731408&w=4


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 (6 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=12602
Subject		: CRED changes causing setuid failures
Submitter	: David Smith <dsmith@redhat.com>
Date		: 2009-01-29 21:35 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d84f4f992cbd76e8f39c488cf0c5d123843923b1
References	: http://marc.info/?l=linux-kernel&m=123326501813668&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12601
Subject		: virt-manager broken on 2.6.29-rc2
Submitter	: Stephen Hemminger <shemminger@vyatta.com>
Date		: 2009-01-29 5:21 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123320655819589&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 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123188898423532&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12599
Subject		: dri /dev node disappeared with 2.6.29-rc1
Submitter	: Norbert Preining <preining@logic.at>
Date		: 2009-01-15 13:42 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=123202701026647&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12591
Subject		: NULL pointer dereference in blk_queue_io_stat
Submitter	: Petr Vandrovec <vandrove@vc.cvut.cz>
Date		: 2009-01-31 23:58 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc58ba9468d94d62c56ab9b47173583ec140b165
Handled-By	: Jens Axboe <jens.axboe@oracle.com>


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 (7 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 (7 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 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12518
Subject		: BUG: using smp_processor_id() in preemptible [00000000] code:  dellWirelessCtl/...
Submitter	: Alex Riesen <fork0@users.sf.net>
Date		: 2009-01-21 14:21 (15 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12511
Subject		: WARNING: at drivers/dma/dmaengine.c:352
Submitter	: Ingo Molnar <mingo@elte.hu>
Date		: 2009-01-19 21:31 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=123240070614443&w=4
Handled-By	: Dan Williams <dan.j.williams@intel.com>


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 (17 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 (19 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=12506
Subject		: Undefined symbols when CONFIG_MFD_PCF50633 is enabled
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-01-17 10:56 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=123218991104592&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12505
Subject		: 2.6.29-rc1 Firefox crashing on page load
Submitter	: Justin Madru <jdm64@gawab.com>
Date		: 2009-01-16 20:56 (20 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
References	: http://marc.info/?l=linux-kernel&m=123213941914274&w=4
Handled-By	: Justin P. Mattock <justinmattock@gmail.com>


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 (21 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 (21 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 (22 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 (23 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 (24 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 (17 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=12491
Subject		: i915 lockdep warning
Submitter	: Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date		: 2009-01-13 23:17 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123188898423532&w=4


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 (24 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 (23 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=12441
Subject		: Xorg can't use dri on radeon X1950 AGP
Submitter	: Daniel Vetter <daniel@ffwll.ch>
Date		: 2009-01-13 05:20 (23 days old)


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 (28 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 (29 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=12417
Subject		: glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"
Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
Date		: 2009-01-06 18:46 (30 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5899329b19100c0b82dc78e9b21ed8b920c9ffb3
References	: http://marc.info/?l=linux-kernel&m=123126782822696&w=4
Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
		  Ingo Molnar <mingo@elte.hu>


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 (31 days old)
References	: http://marc.info/?l=linux-wireless&m=123115178019082&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 (31 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=12621
Subject		: Resume broken on iBook
Submitter	: Andreas Schwab <schwab@suse.de>
Date		: 2009-02-01 16:54 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aa8c6c93747f7b55fa11e1624fec8ca33763a805
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
		  Benjamin Herrenschmidt <benh@kernel.crashing.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=20085&action=view


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 (13 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>
Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12605
Subject		: Suspend regression, hang after matroxfb
Submitter	: Eric Sesterhenn <snakebyte@gmx.de>
Date		: 2009-01-29 12:58 (7 days old)
References	: http://thread.gmane.org/gmane.linux.power-management.general/12640
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://marc.info/?l=linux-kernel&m=123335902122029&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12598
Subject		: tg3 dead after resume
Submitter	: Parag Warudkar <parag.lkml@gmail.com>
Date		: 2009-01-29 0:14 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123318968501524&w=4
Handled-By	: Linus Torvalds <torvalds@linux-foundation.org>
		  Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://marc.info/?l=linux-kernel&m=123365342301877&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12538
Subject		: xfs_fsr fails on 2.6.29-rc kernels
Submitter	: Paul Martin <pm@debian.org>
Date		: 2009-01-25 13:02 (11 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=743bb4650da9e2595d6cedd01c680b5b9398c74a
Handled-By	: Eric Sandeen <sandeen@sandeen.net>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=19986&action=view


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12509
Subject		: lockdep report. fb_mmap vs sys_mmap2
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2009-01-17 18:19 (19 days old)
References	: http://lkml.org/lkml/2009/1/17/176
Handled-By	: Andrea Righi <righi.andrea@gmail.com>
Patch		: http://marc.info/?l=linux-kernel&m=123231032115956&w=4


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 (27 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=12495
Subject		: thinkpad problems during resume
Submitter	: Christian Borntraeger <borntraeger@de.ibm.com>
Date		: 2009-01-17 15:48 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e39ad415ac15116df213dfa2aa2a4f1b0857af9c
References	: http://marc.info/?l=linux-kernel&m=123220746125479&w=4
		  http://marc.info/?l=linux-kernel&m=123170361827197&w=4
Handled-By	: Mike Travis <travis@sgi.com>
Patch		: http://lkml.org/lkml/2009/1/16/375
		  http://lkml.org/lkml/2009/1/16/376
		  http://lkml.org/lkml/2009/1/16/378


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12493
Subject		: ACPI related kernel panic when booting 2.6.29-rc2
Submitter	: Peter Klotz <peter.klotz@aon.at>
Date		: 2009-01-17 20:47 (19 days old)
References	: http://marc.info/?l=linux-acpi&m=123222565017047&w=4
Handled-By	: Alexey Starikovskiy <aystarik@gmail.com>
		  Tero Roponen <tero.roponen@gmail.com>
Patch		: http://marc.info/?l=linux-acpi&m=123223261225680&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12427
Subject		: cpumask change causes sparc build bustage
Submitter	: David Miller <davem@davemloft.net>
Date		: 2009-01-11 8:31 (25 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=588235bb53f2c215f0d4b08fd30b461fedc3338e
References	: http://marc.info/?l=linux-kernel&m=123166268013838&w=4
Handled-By	: David Miller <davem@davemloft.net>
Patch		: http://marc.info/?l=linux-kernel&m=123167571525706&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12416
Subject		: Recent change to kernel spikes out ccache/distcc
Submitter	: Theodore Ts'o <tytso@mit.edu>
Date		: 2009-01-06 15:15 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123125495000603&w=4
Patch		: http://lkml.org/lkml/2009/1/20/78


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12400
Subject		: git-latest: kernel oops in IOMMU setup
Submitter	: Dirk Hohndel <hohndel@infradead.org>
Date		: 2009-01-08 20:05 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=123144520124853&w=4
Handled-By	: Dirk Hohndel <hohndel@infradead.org>
Patch		: http://marc.info/?l=linux-kernel&m=123152033725557&w=4


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

[Bug #12400] git-latest: kernel oops in IOMMU setup

[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=12400
Subject		: git-latest: kernel oops in IOMMU setup
Submitter	: Dirk Hohndel <hohndel@infradead.org>
Date		: 2009-01-08 20:05 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=123144520124853&w=4
Handled-By	: Dirk Hohndel <hohndel@infradead.org>
Patch		: http://marc.info/?l=linux-kernel&m=123152033725557&w=4

[Bug #12416] Recent change to kernel spikes out ccache/distcc

[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=12416
Subject		: Recent change to kernel spikes out ccache/distcc
Submitter	: Theodore Ts'o <tytso@mit.edu>
Date		: 2009-01-06 15:15 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=123125495000603&w=4
Patch		: http://lkml.org/lkml/2009/1/20/78

[Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689

[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=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 (31 days old)
References	: http://marc.info/?l=linux-wireless&m=123115178019082&w=4

[Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[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=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 (31 days old)
References	: http://marc.info/?l=linux-kernel&m=123112882127823&w=4

[Bug #12418] Repeated ioctl(4, 0x40046445, ..) loop in glxgears

[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=12418
Subject		: Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Date		: 2009-01-07 22:43 (29 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 #12417] glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"

[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=12417
Subject		: glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"
Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
Date		: 2009-01-06 18:46 (30 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5899329b19100c0b82dc78e9b21ed8b920c9ffb3
References	: http://marc.info/?l=linux-kernel&m=123126782822696&w=4
Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
		  Ingo Molnar <mingo@elte.hu>

[Bug #12419] possible circular locking dependency on i915 dma

[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=12419
Subject		: possible circular locking dependency on i915 dma
Submitter	: Wang Chen <wangchen@cn.fujitsu.com>
Date		: 2009-01-08 14:11 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=123142399720125&w=4

[Bug #12427] cpumask change causes sparc build bustage

[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=12427
Subject		: cpumask change causes sparc build bustage
Submitter	: David Miller <davem@davemloft.net>
Date		: 2009-01-11 8:31 (25 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=588235bb53f2c215f0d4b08fd30b461fedc3338e
References	: http://marc.info/?l=linux-kernel&m=123166268013838&w=4
Handled-By	: David Miller <davem@davemloft.net>
Patch		: http://marc.info/?l=linux-kernel&m=123167571525706&w=4

[Bug #12490] ath5k related kernel panic in 2.6.29-rc1

[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=12490
Subject		: ath5k related kernel panic in 2.6.29-rc1
Submitter	: Sergey S. Kostyliov <rathamahata@gmail.com>
Date		: 2009-01-12 7:38 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By	: Bob Copeland <me@bobcopeland.com>

[Bug #12441] Xorg can't use dri on radeon X1950 AGP

[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=12441
Subject		: Xorg can't use dri on radeon X1950 AGP
Submitter	: Daniel Vetter <daniel@ffwll.ch>
Date		: 2009-01-13 05:20 (23 days old)

[Bug #12491] i915 lockdep warning

[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=12491
Subject		: i915 lockdep warning
Submitter	: Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date		: 2009-01-13 23:17 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123188898423532&w=4

[Bug #12444] X hangs following switch from radeonfb console - Bisected

[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=12444
Subject		: X hangs following switch from radeonfb console - Bisected
Submitter	: Graham Murray <graham@gmurray.org.uk>
Date		: 2009-01-13 14:03 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a

[Bug #12494] Sony backlight regression from 2.6.28 to 29-rc

[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=12494
Subject		: Sony backlight regression from 2.6.28 to 29-rc
Submitter	: Norbert Preining <preining@logic.at>
Date		: 2009-01-19 8:14 (17 days old)
References	: http://marc.info/?l=linux-acpi&m=123235286829512&w=4
Handled-By	: Mattia Dongili <malattia@linux.it>

[Bug #12495] thinkpad problems during resume

[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=12495
Subject		: thinkpad problems during resume
Submitter	: Christian Borntraeger <borntraeger@de.ibm.com>
Date		: 2009-01-17 15:48 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e39ad415ac15116df213dfa2aa2a4f1b0857af9c
References	: http://marc.info/?l=linux-kernel&m=123220746125479&w=4
		  http://marc.info/?l=linux-kernel&m=123170361827197&w=4
Handled-By	: Mike Travis <travis@sgi.com>
Patch		: http://lkml.org/lkml/2009/1/16/375
		  http://lkml.org/lkml/2009/1/16/376
		  http://lkml.org/lkml/2009/1/16/378

[Bug #12496] swsusp cannot find resume device (sometimes)

[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 (27 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 #12493] ACPI related kernel panic when booting 2.6.29-rc2

[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=12493
Subject		: ACPI related kernel panic when booting 2.6.29-rc2
Submitter	: Peter Klotz <peter.klotz@aon.at>
Date		: 2009-01-17 20:47 (19 days old)
References	: http://marc.info/?l=linux-acpi&m=123222565017047&w=4
Handled-By	: Alexey Starikovskiy <aystarik@gmail.com>
		  Tero Roponen <tero.roponen@gmail.com>
Patch		: http://marc.info/?l=linux-acpi&m=123223261225680&w=4

[Bug #12499] Problem with using bluetooth adaper connected to usb port

[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=12499
Subject		: Problem with using bluetooth adaper connected to usb port
Submitter	: Maciej Rutecki <maciej.rutecki@gmail.com>
Date		: 2009-01-13 18:34 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123187185426236&w=4

[Bug #12497] new barrier warnings in 2.6.29-rc1

[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=12497
Subject		: new barrier warnings in 2.6.29-rc1
Submitter	: Christoph Hellwig <hch@lst.de>
Date		: 2009-01-12 15:46 (24 days old)
References	: http://marc.info/?l=linux-kernel&m=123177528217154&w=4
Handled-By	: Jens Axboe <jens.axboe@oracle.com>

[Bug #12501] build bug in eeepc-laptop.c

[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=12501
Subject		: build bug in eeepc-laptop.c
Submitter	: Ingo Molnar <mingo@elte.hu>
Date		: 2009-01-14 17:25 (22 days old)
References	: http://lkml.org/lkml/2009/1/14/315

[Bug #12502] pipe_read oops on sh

[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=12502
Subject		: pipe_read oops on sh
Submitter	: Adrian McMenamin <lkmladrian@gmail.com>
Date		: 2009-01-15 9:48 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=123201298005600&w=4

[Bug #12503] [slab corruption] BUG key_jar: Poison overwritten

[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=12503
Subject		: [slab corruption] BUG key_jar: Poison overwritten
Submitter	: Ingo Molnar <mingo@elte.hu>
Date		: 2009-01-15 18:16 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=123204353425825&w=4
Handled-By	: David Howells <dhowells@redhat.com>

[Bug #12505] 2.6.29-rc1 Firefox crashing on page load

[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=12505
Subject		: 2.6.29-rc1 Firefox crashing on page load
Submitter	: Justin Madru <jdm64@gawab.com>
Date		: 2009-01-16 20:56 (20 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
References	: http://marc.info/?l=linux-kernel&m=123213941914274&w=4
Handled-By	: Justin P. Mattock <justinmattock@gmail.com>

[Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3

[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=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 (19 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 #12509] lockdep report. fb_mmap vs sys_mmap2

[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=12509
Subject		: lockdep report. fb_mmap vs sys_mmap2
Submitter	: Dave Jones <davej@redhat.com>
Date		: 2009-01-17 18:19 (19 days old)
References	: http://lkml.org/lkml/2009/1/17/176
Handled-By	: Andrea Righi <righi.andrea@gmail.com>
Patch		: http://marc.info/?l=linux-kernel&m=123231032115956&w=4

[Bug #12506] Undefined symbols when CONFIG_MFD_PCF50633 is enabled

[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=12506
Subject		: Undefined symbols when CONFIG_MFD_PCF50633 is enabled
Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
Date		: 2009-01-17 10:56 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=123218991104592&w=4

[Bug #12510] 2.6.29-rc2 dies on startup

[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=12510
Subject		: 2.6.29-rc2 dies on startup
Submitter	: Ferenc Wagner <wferi@niif.hu>
Date		: 2009-01-19 12:53 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=123236969321703&w=4

[Bug #12518] BUG: using smp_processor_id() in preemptible [00000000] code: dellWirelessCtl/...

[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=12518
Subject		: BUG: using smp_processor_id() in preemptible [00000000] code:  dellWirelessCtl/...
Submitter	: Alex Riesen <fork0@users.sf.net>
Date		: 2009-01-21 14:21 (15 days old)

[Bug #12511] WARNING: at drivers/dma/dmaengine.c:352

[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=12511
Subject		: WARNING: at drivers/dma/dmaengine.c:352
Submitter	: Ingo Molnar <mingo@elte.hu>
Date		: 2009-01-19 21:31 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=123240070614443&w=4
Handled-By	: Dan Williams <dan.j.williams@intel.com>

[Bug #12538] xfs_fsr fails on 2.6.29-rc kernels

[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=12538
Subject		: xfs_fsr fails on 2.6.29-rc kernels
Submitter	: Paul Martin <pm@debian.org>
Date		: 2009-01-25 13:02 (11 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=743bb4650da9e2595d6cedd01c680b5b9398c74a
Handled-By	: Eric Sandeen <sandeen@sandeen.net>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=19986&action=view

[Bug #12551] end_request: I/O error, dev cciss/c0d0, sector 87435720

[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=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 (9 days old)

[Bug #12571] Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*

[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=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 (7 days old)

[Bug #12574] possible circular locking dependency detected

[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=12574
Subject		: possible circular locking dependency detected
Submitter	: Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date		: 2009-01-29 11:35 (7 days old)

[Bug #12591] NULL pointer dereference in blk_queue_io_stat

[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=12591
Subject		: NULL pointer dereference in blk_queue_io_stat
Submitter	: Petr Vandrovec <vandrove@vc.cvut.cz>
Date		: 2009-01-31 23:58 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc58ba9468d94d62c56ab9b47173583ec140b165
Handled-By	: Jens Axboe <jens.axboe@oracle.com>

[Bug #12598] tg3 dead after resume

[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=12598
Subject		: tg3 dead after resume
Submitter	: Parag Warudkar <parag.lkml@gmail.com>
Date		: 2009-01-29 0:14 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123318968501524&w=4
Handled-By	: Linus Torvalds <torvalds@linux-foundation.org>
		  Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://marc.info/?l=linux-kernel&m=123365342301877&w=4

[Bug #12600] i915 lockdep warning

[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=12600
Subject		: i915 lockdep warning
Submitter	: Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date		: 2009-01-13 23:17 (23 days old)
References	: http://marc.info/?l=linux-kernel&m=123188898423532&w=4

[Bug #12599] dri /dev node disappeared with 2.6.29-rc1

[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=12599
Subject		: dri /dev node disappeared with 2.6.29-rc1
Submitter	: Norbert Preining <preining@logic.at>
Date		: 2009-01-15 13:42 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=123202701026647&w=4

[Bug #12601] virt-manager broken on 2.6.29-rc2

[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=12601
Subject		: virt-manager broken on 2.6.29-rc2
Submitter	: Stephen Hemminger <shemminger@vyatta.com>
Date		: 2009-01-29 5:21 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123320655819589&w=4

[Bug #12602] CRED changes causing setuid failures

[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=12602
Subject		: CRED changes causing setuid failures
Submitter	: David Smith <dsmith@redhat.com>
Date		: 2009-01-29 21:35 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d84f4f992cbd76e8f39c488cf0c5d123843923b1
References	: http://marc.info/?l=linux-kernel&m=123326501813668&w=4

[Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB

[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=12604
Subject		: Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
Submitter	: Jan Kara <jack@suse.cz>
Date		: 2009-01-30 1:23 (6 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 #12606] fb_mmap: circular locking dependency on hibernation

[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=12606
Subject		: fb_mmap: circular locking dependency on hibernation
Submitter	: Andrey Borzenkov <arvidjaar@mail.ru>
Date		: 2009-01-27 18:37 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=123308162731408&w=4

[Bug #12605] Suspend regression, hang after matroxfb

[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=12605
Subject		: Suspend regression, hang after matroxfb
Submitter	: Eric Sesterhenn <snakebyte@gmx.de>
Date		: 2009-01-29 12:58 (7 days old)
References	: http://thread.gmane.org/gmane.linux.power-management.general/12640
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
Patch		: http://marc.info/?l=linux-kernel&m=123335902122029&w=4

[Bug #12611] kernel BUG at kernel/cgroup.c:398!

[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=12611
Subject		: kernel BUG at kernel/cgroup.c:398!
Submitter	: Bharata B Rao <bharata@linux.vnet.ibm.com>
Date		: 2009-01-28 15:49 (8 days old)
References	: http://marc.info/?l=linux-kernel&m=123315721707796&w=4

[Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

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

[Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[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=12609
Subject		: v2.6.29-rc2 libata sff 32bit PIO regression
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2009-01-23 23:52 (13 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>
Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2

[Bug #12610] sync-Regression in 2.6.28.2?

[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=12610
Subject		: sync-Regression in 2.6.28.2?
Submitter	: Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date		: 2009-01-27 9:35 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=123304977706620&w=4

[Bug #12613] [Suspend regression][DRM, RADEON]

[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=12613
Subject		: [Suspend regression][DRM, RADEON]
Submitter	: etienne <etienne.basset@numericable.fr>
Date		: 2009-01-28 22:00 (8 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 #12616] boot hang: async vs. kexec

[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=12616
Subject		: boot hang: async vs. kexec
Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
Date		: 2009-01-29 13:15 (7 days old)
References	: http://lkml.org/lkml/2009/1/29/359

[Bug #12615] boot hangs while bringing up gianfar ethernet

[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=12615
Subject		: boot hangs while bringing up gianfar ethernet
Submitter	: Ira Snyder <iws@ovro.caltech.edu>
Date		: 2009-01-29 19:41 (7 days old)
References	: http://marc.info/?l=linux-kernel&m=123325817201665&w=4

[Bug #12617] unable to compile e100 firmware into kernel

[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=12617
Subject		: unable to compile e100 firmware into kernel
Submitter	: Andrey Borzenkov <arvidjaar@mail.ru>
Date		: 2009-01-31 15:59 (5 days old)
References	: http://marc.info/?l=linux-kernel&m=123341764915181&w=4

[Bug #12621] Resume broken on iBook

[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=12621
Subject		: Resume broken on iBook
Submitter	: Andreas Schwab <schwab@suse.de>
Date		: 2009-02-01 16:54 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aa8c6c93747f7b55fa11e1624fec8ca33763a805
Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
		  Benjamin Herrenschmidt <benh@kernel.crashing.org>
Patch		: http://bugzilla.kernel.org/attachment.cgi?id=20085&action=view

[Bug #12618] hackbench [pthread mode] regression with 2.6.29-rc3

[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=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 (4 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>

Re: [Bug #12591] NULL pointer dereference in blk_queue_io_stat

[Jens Axboe]

On Wed, Feb 04 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=12591
> Subject		: NULL pointer dereference in blk_queue_io_stat
> Submitter	: Petr Vandrovec <vandrove@vc.cvut.cz>
> Date		: 2009-01-31 23:58 (5 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc58ba9468d94d62c56ab9b47173583ec140b165
> Handled-By	: Jens Axboe <jens.axboe@oracle.com>

This one is already fixed in -git by commit
fb8ec18c316d869271137c97320dbfd2def56569.

-- 
Jens Axboe

Re: [Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689

[Christian Borntraeger]

Am Wednesday 04 February 2009 11:23:55 schrieb 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=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 (31 days old)
> References	: http://marc.info/?l=linux-wireless&m=123115178019082&w=4

Patch is available but not yet upstream:
http://marc.info/?l=linux-wireless&m=123316414222201&w=2 

Re: [Bug #12495] thinkpad problems during resume

[Christian Borntraeger]

Am Wednesday 04 February 2009 11:23:58 schrieb 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=12495
> Subject		: thinkpad problems during resume
> Submitter	: Christian Borntraeger <borntraeger@de.ibm.com>
> Date		: 2009-01-17 15:48 (19 days old)
> First-Bad-Commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
>=e39ad415ac15116df213dfa2aa2a4f1b0857af9c References	:
> http://marc.info/?l=linux-kernel&m=123220746125479&w=4
> http://marc.info/?l=linux-kernel&m=123170361827197&w=4
> Handled-By	: Mike Travis <travis@sgi.com>
> Patch		: http://lkml.org/lkml/2009/1/16/375
> 		  http://lkml.org/lkml/2009/1/16/376
> 		  http://lkml.org/lkml/2009/1/16/378

Fixed upstream. 

Re: [Bug #12417] glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"

[Ingo Molnar]

* 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=12417
> Subject		: glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"
> Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
> Date		: 2009-01-06 18:46 (30 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5899329b19100c0b82dc78e9b21ed8b920c9ffb3
> References	: http://marc.info/?l=linux-kernel&m=123126782822696&w=4
> Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
> 		  Ingo Molnar <mingo@elte.hu>
> 

this should be fixed in latest -git. Alexey, can you confirm?

	Ingo

Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation

[Andrey Borzenkov]

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

On 4 of February 2009 13:24:06 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 (9 days old)
> References	: http://marc.info/?l=linux-kernel&m=123308162731408&w=4

for me it is fixed with
http://marc.info/?l=linux-kernel&m=123365581406194&w=2 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Bug #12505] 2.6.29-rc1 Firefox crashing on page load

[Justin Mattock]

On Wed, Feb 4, 2009 at 2:24 AM, 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=12505
> Subject         : 2.6.29-rc1 Firefox crashing on page load
> Submitter       : Justin Madru <jdm64@gawab.com>
> Date            : 2009-01-16 20:56 (20 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
> References      : http://marc.info/?l=linux-kernel&m=123213941914274&w=4
> Handled-By      : Justin P. Mattock <justinmattock@gmail.com>
>
>
>

Well the hardest for this, was to reproduce
the error.(never did). I guess it can be taken
of if there was a patch for the fix, and the patch
made it into the main tree. but if this  is a firefox
issue, then a report needs to be filed with them.
so overall my answer is "I don't know."
:^)

regards;
-- 
Justin P. Mattock

Re: [Bug #12518] BUG: using smp_processor_id() in preemptible [00000000] code: dellWirelessCtl/...

[Alex Riesen]

2009/2/4 Rafael J. Wysocki <rjw@sisk.pl>:
> 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 confirm the problem fixed with the patch in the bugs discussion.

>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12518
> Subject         : BUG: using smp_processor_id() in preemptible [00000000] code:  dellWirelessCtl/...
> Submitter       : Alex Riesen <fork0@users.sf.net>
> Date            : 2009-01-21 14:21 (15 days old)
>

Re: [Bug #12417] glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"

[Alexey Fisher]

Ingo Molnar schrieb:
> * 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=12417
>> Subject		: glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"
>> Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
>> Date		: 2009-01-06 18:46 (30 days old)
>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5899329b19100c0b82dc78e9b21ed8b920c9ffb3
>> References	: http://marc.info/?l=linux-kernel&m=123126782822696&w=4
>> Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
>> 		  Ingo Molnar <mingo@elte.hu>
>>
> 
> this should be fixed in latest -git. Alexey, can you confirm?
> 
> 	Ingo

I confirm it. It working  great with latest git 2.6.29-rc3-00495-gdcf6a79.
	Alexey

Re: [Bug #12511] WARNING: at drivers/dma/dmaengine.c:352

[Dan Williams]

On Wed, Feb 4, 2009 at 3:24 AM, 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).
>

This should be resolved as of commit 83436a05 "dmaengine: kill some
dubious WARN_ONCEs"

Thanks,
Dan

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Linus Torvalds]

On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12599
> Subject		: dri /dev node disappeared with 2.6.29-rc1
> Submitter	: Norbert Preining <preining@logic.at>
> Date		: 2009-01-15 13:42 (21 days old)
> References	: http://marc.info/?l=linux-kernel&m=123202701026647&w=4

I think this one is simply that Intel DRI now requires CONFIG_FB.

So make sure that you say yes to the CONFIG_FB question (easiest fix: just 
edit the .config file and change the line "# CONFIG_FB is not set" to 
"CONFIG_FB=y" and do "make oldconfig" - I realize that people think that 
graphical config front-ends are simpler, but often just editing the file 
is the quickest way).

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12591
> Subject		: NULL pointer dereference in blk_queue_io_stat
> Submitter	: Petr Vandrovec <vandrove@vc.cvut.cz>
> Date		: 2009-01-31 23:58 (5 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc58ba9468d94d62c56ab9b47173583ec140b165
> Handled-By	: Jens Axboe <jens.axboe@oracle.com>

I think this one is fixed by commit fb8ec18c316d8.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12511
> Subject		: WARNING: at drivers/dma/dmaengine.c:352
> Submitter	: Ingo Molnar <mingo@elte.hu>
> Date		: 2009-01-19 21:31 (17 days old)
> References	: http://marc.info/?l=linux-kernel&m=123240070614443&w=4
> Handled-By	: Dan Williams <dan.j.williams@intel.com>

This warning just got removed as bogus.

Commit 83436a0560e9ef8af2f0796264dde4bed1415359

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12506
> Subject		: Undefined symbols when CONFIG_MFD_PCF50633 is enabled
> Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
> Date		: 2009-01-17 10:56 (19 days old)
> References	: http://marc.info/?l=linux-kernel&m=123218991104592&w=4

Commit 9e6f8ed7c3a303d37eb119847dd3029701e37e28

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12505
> Subject		: 2.6.29-rc1 Firefox crashing on page load
> Submitter	: Justin Madru <jdm64@gawab.com>
> Date		: 2009-01-16 20:56 (20 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
> References	: http://marc.info/?l=linux-kernel&m=123213941914274&w=4
> Handled-By	: Justin P. Mattock <justinmattock@gmail.com>

Heh. That commit you point to is very innocuous.

Commit 4217458dafaa57d8e26a46f5d05ab8c53cf64191 is a pure cleanup, and it 
_does_ make the code look nicer, but while it looks lik a total no-op, it 
actually has a very subtle behavioural change: it makes gcc think that it 
owns the whole argument stack. Which is _not_ true of 'asmlinkage' 
functions, but we've never been able to tell gcc to keep its grubby hands 
off our stack.

So I suspect that gcc inlines the function and then creates a function 
call that re-uses the "struct pt_regs" on the stack as the argument area 
too. Which corrupts the "pt_regs", and then we return to user space with 
some random register contents.

So I think we need to just revert it. Ingo, Hiroshi?

				Linus

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12505
> > Subject		: 2.6.29-rc1 Firefox crashing on page load
> > Submitter	: Justin Madru <jdm64@gawab.com>
> > Date		: 2009-01-16 20:56 (20 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
> > References	: http://marc.info/?l=linux-kernel&m=123213941914274&w=4
> > Handled-By	: Justin P. Mattock <justinmattock@gmail.com>
> 
> Heh. That commit you point to is very innocuous.
> 
> Commit 4217458dafaa57d8e26a46f5d05ab8c53cf64191 is a pure cleanup, and it 
> _does_ make the code look nicer, but while it looks lik a total no-op, it 
> actually has a very subtle behavioural change: it makes gcc think that it 
> owns the whole argument stack. Which is _not_ true of 'asmlinkage' 
> functions, but we've never been able to tell gcc to keep its grubby hands 
> off our stack.
> 
> So I suspect that gcc inlines the function and then creates a function 
> call that re-uses the "struct pt_regs" on the stack as the argument area 
> too. Which corrupts the "pt_regs", and then we return to user space with 
> some random register contents.

yes - i tracked it down back then, just the regression entry didnt get 
updated.

> So I think we need to just revert it. Ingo, Hiroshi?

should be fixed upstream by:

 552b8aa: Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"

the revert commit is below with explaination - also with a Tested-by tag. 
The revert is not a pure revert - it also adds a comment to preserve this 
circumstance cleanly.

We first had a few fruitless attempts to annotate it in some clear fashion 
(the existing tailcall-avoidance macros we have didnt suit this case) - then 
went for the revert because none of the variants that told gcc not to screw 
up actually made the code better than it was originally.

	Ingo

-------------->
>From 552b8aa4d1edcc1c764ff6f61a7686347a2d1827 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Tue, 20 Jan 2009 09:31:49 +0100
Subject: [PATCH] Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"

This reverts commit 4217458dafaa57d8e26a46f5d05ab8c53cf64191.

Justin Madru bisected this commit, it was causing weird Firefox
crashes.

The reason is that GCC mis-optimizes (re-uses) the on-stack parameters of
the calling frame, which corrupts the syscall return pt_regs state and
thus corrupts user-space register state.

So we go back to the slightly less clean but more optimization-safe
method of getting to pt_regs. Also add a comment to explain this.

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

Reported-and-bisected-by: Justin Madru <jdm64@gawab.com>
Tested-by: Justin Madru <jdm64@gawab.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/include/asm/syscalls.h |    2 +-
 arch/x86/kernel/signal.c        |   11 +++++++++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/syscalls.h b/arch/x86/include/asm/syscalls.h
index 9c6797c..c0b0bda 100644
--- a/arch/x86/include/asm/syscalls.h
+++ b/arch/x86/include/asm/syscalls.h
@@ -40,7 +40,7 @@ asmlinkage int sys_sigaction(int, const struct old_sigaction __user *,
 			     struct old_sigaction __user *);
 asmlinkage int sys_sigaltstack(unsigned long);
 asmlinkage unsigned long sys_sigreturn(unsigned long);
-asmlinkage int sys_rt_sigreturn(struct pt_regs);
+asmlinkage int sys_rt_sigreturn(unsigned long);
 
 /* kernel/ioport.c */
 asmlinkage long sys_iopl(unsigned long);
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 89bb766..df0587f 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -632,9 +632,16 @@ badframe:
 }
 
 #ifdef CONFIG_X86_32
-asmlinkage int sys_rt_sigreturn(struct pt_regs regs)
+/*
+ * Note: do not pass in pt_regs directly as with tail-call optimization
+ * GCC will incorrectly stomp on the caller's frame and corrupt user-space
+ * register state:
+ */
+asmlinkage int sys_rt_sigreturn(unsigned long __unused)
 {
-	return do_rt_sigreturn(&regs);
+	struct pt_regs *regs = (struct pt_regs *)&__unused;
+
+	return do_rt_sigreturn(regs);
 }
 #else /* !CONFIG_X86_32 */
 asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)

Re: [Bug #12417] glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"

[Ingo Molnar]

* Alexey Fisher <bug-track@fisher-privat.net> wrote:

> Ingo Molnar schrieb:
>> * 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=12417
>>> Subject		: glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"
>>> Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
>>> Date		: 2009-01-06 18:46 (30 days old)
>>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5899329b19100c0b82dc78e9b21ed8b920c9ffb3
>>> References	: http://marc.info/?l=linux-kernel&m=123126782822696&w=4
>>> Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
>>> 		  Ingo Molnar <mingo@elte.hu>
>>>
>>
>> this should be fixed in latest -git. Alexey, can you confirm?
>>
>> 	Ingo
>
> I confirm it. It working  great with latest git 2.6.29-rc3-00495-gdcf6a79.

Thanks for the testing!

	Ingo

Re: [Bug #12505] 2.6.29-rc1 Firefox crashing on page load

[Ingo Molnar]

* Justin Mattock <justinmattock@gmail.com> wrote:

> On Wed, Feb 4, 2009 at 2:24 AM, 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=12505
> > Subject         : 2.6.29-rc1 Firefox crashing on page load
> > Submitter       : Justin Madru <jdm64@gawab.com>
> > Date            : 2009-01-16 20:56 (20 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
> > References      : http://marc.info/?l=linux-kernel&m=123213941914274&w=4
> > Handled-By      : Justin P. Mattock <justinmattock@gmail.com>
> >
> >
> >
> 
> Well the hardest for this, was to reproduce
> the error.(never did). I guess it can be taken
> of if there was a patch for the fix, and the patch
> made it into the main tree. but if this  is a firefox
> issue, then a report needs to be filed with them.
> so overall my answer is "I don't know."
> :^)

the error is spurious because gcc randomly stomps on user register state so 
the effects can be rather random and unpredictable.

The fix:

 552b8aa: Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"

was included in -rc2 already, so please test latest -git whether you can see 
any such troubles.

	Ingo

Re: [Bug #12616] boot hang: async vs. kexec

[Randy Dunlap]

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=12616
> Subject		: boot hang: async vs. kexec
> Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> Date		: 2009-01-29 13:15 (7 days old)
> References	: http://lkml.org/lkml/2009/1/29/359

Please reject this for now.  I'll keep debugging/working on it
and see if any fixes are needed.

Thanks,
-- 
~Randy

Re: [Bug #12615] boot hangs while bringing up gianfar ethernet

[Ira Snyder]

On Wed, Feb 04, 2009 at 11:24:08AM +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=12615
> Subject		: boot hangs while bringing up gianfar ethernet
> Submitter	: Ira Snyder <iws@ovro.caltech.edu>
> Date		: 2009-01-29 19:41 (7 days old)
> References	: http://marc.info/?l=linux-kernel&m=123325817201665&w=4
> 
> 

Tested this morning with Linux version 2.6.29-rc3-00563-g37f752c, and I
still see the same behavior.

Thanks,
Ira

Re: [Bug #12602] CRED changes causing setuid failures

[David Smith]

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=12602
> Subject		: CRED changes causing setuid failures
> Submitter	: David Smith <dsmith@redhat.com>
> Date		: 2009-01-29 21:35 (7 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d84f4f992cbd76e8f39c488cf0c5d123843923b1
> References	: http://marc.info/?l=linux-kernel&m=123326501813668&w=4

I've verified this still exists in 2.6.29-rc3.

(git describe says I'm at v2.6.29-rc3-495-gdcf6a79)

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Norbert Preining]

On Mi, 04 Feb 2009, Linus Torvalds wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12599
> > Subject		: dri /dev node disappeared with 2.6.29-rc1
> > Submitter	: Norbert Preining <preining@logic.at>
> > Date		: 2009-01-15 13:42 (21 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123202701026647&w=4
> 
> I think this one is simply that Intel DRI now requires CONFIG_FB.

Right. I mentioned that in another bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=12494

> So make sure that you say yes to the CONFIG_FB question (easiest fix: just 
> edit the .config file and change the line "# CONFIG_FB is not set" to 
> "CONFIG_FB=y" and do "make oldconfig" - I realize that people think that 
> graphical config front-ends are simpler, but often just editing the file 
> is the quickest way).

The problem is that if you have a configuration under 2.6.28 without
CONFIG_FB and just call make oldconfig, or even make config and don't
know that you loose the DRM. And I was using make oldconfig (there is a
graphical config?? ;-))

There is that other bug 12494 mentioned, namely due to the disappearance
of DRM the brightness adjustment on my vaio z11 stopped working.

So maybe there should be a select FB or so under the CONFIG_DRM option
(not that I actually can program Kconfig).

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
PITLOCHRY (n.)
The background gurgling noise heard in Wimby Bars caused by people
trying to get the last bubbles out of their milkshakes by slurping
loudly through their straws.
			--- Douglas Adams, The Meaning of Liff

Re: [Bug #12505] 2.6.29-rc1 Firefox crashing on page load

[Justin Mattock]

On Wed, Feb 4, 2009 at 4:46 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Justin Mattock <justinmattock@gmail.com> wrote:
>
>> On Wed, Feb 4, 2009 at 2:24 AM, 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=12505
>> > Subject         : 2.6.29-rc1 Firefox crashing on page load
>> > Submitter       : Justin Madru <jdm64@gawab.com>
>> > Date            : 2009-01-16 20:56 (20 days old)
>> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
>> > References      : http://marc.info/?l=linux-kernel&m=123213941914274&w=4
>> > Handled-By      : Justin P. Mattock <justinmattock@gmail.com>
>> >
>> >
>> >
>>
>> Well the hardest for this, was to reproduce
>> the error.(never did). I guess it can be taken
>> of if there was a patch for the fix, and the patch
>> made it into the main tree. but if this  is a firefox
>> issue, then a report needs to be filed with them.
>> so overall my answer is "I don't know."
>> :^)
>
> the error is spurious because gcc randomly stomps on user register state so
> the effects can be rather random and unpredictable.
>
> The fix:
>
>  552b8aa: Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"
>
> was included in -rc2 already, so please test latest -git whether you can see
> any such troubles.
>
>        Ingo
>

Sure I'll test it.
I'm just in the process of compiling libc.
which looks like I'll be here for a while.

-- 
Justin P. Mattock

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Linus Torvalds]

On Wed, 4 Feb 2009, Norbert Preining wrote:
> 
> The problem is that if you have a configuration under 2.6.28 without
> CONFIG_FB and just call make oldconfig, or even make config and don't
> know that you loose the DRM. And I was using make oldconfig (there is a
> graphical config?? ;-))

Sure. It's inconvenient, no question about that. I asked the i915 people 
to look into not requiring CONFIG_FB, and I hope they will, but my point 
is that I don't think we can consider "small one-time inconvenience" to be 
a "regression".

> So maybe there should be a select FB or so under the CONFIG_DRM option
> (not that I actually can program Kconfig).

CONFIG_FB is one of the things that _could_ be selected for (it doesn't 
depend on anything else that I know about), so just changing the "depends 
on FB" into a "select FB" may get rid of the issue - but it would not 
actually fix your problem, since your CONFIG_DRM_I915 has already been set 
to 'n' by now - so you'd _still_ have to enable it by hand again.

So the upside is not very big - people who have custom configs are the 
often the same people who try -rc1's, so they've already hit this.

			Linus

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Norbert Preining]

On Mi, 04 Feb 2009, Linus Torvalds wrote:
> is that I don't think we can consider "small one-time inconvenience" to be 
> a "regression".

Agreed.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
EAST WITTERING (n.)
The same as west wittering (q.v.) only it's you they've trying to get
away from.
			--- Douglas Adams, The Meaning of Liff

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 4 Feb 2009, Norbert Preining wrote:
> > 
> > The problem is that if you have a configuration under 2.6.28 without 
> > CONFIG_FB and just call make oldconfig, or even make config and don't 
> > know that you loose the DRM. And I was using make oldconfig (there is a 
> > graphical config?? ;-))
> 
> Sure. It's inconvenient, no question about that. I asked the i915 people 
> to look into not requiring CONFIG_FB, and I hope they will, but my point 
> is that I don't think we can consider "small one-time inconvenience" to be 
> a "regression".

if you mean that as a general principle, there's four very real downsides in 
my opinion.

Firstly, we could have done better (and still can do better), via various 
easy and non-intrusive measures:

   - We could add a runtime warning:

      for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
      that there's no DRM because CONFIG_FB is not selected and oldconfig 
      loses the I915 setting silently - placed in a key DRM ioctl, would 
      have gone a long way addressing the issue. Testers do notice kernel 
      warnings that pop up when their X gets slow. (This approach might also 
      have the added bonus of warning folks who enable the wrong driver for 
      the hardware.)

   - Or we could add a more thoughtful Kconfig migration:

      Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
      DRM_I915 as a non-interactive migration helper: if set, it 
      auto-selects both FB and DRM_I915_FB.

      While CONFIG_FB is an interactive Kconfig option so a select can be 
      dangerous to a correct dependency tree, it seems safe to do in this 
      specific case because it seems to be a rather leaf entry with no 
      dependencies.

Sure, upgrading systems and following development is never easy and well 
structured brains are in heavy demand in any case - but we should really 
engineer things so that people spend time on reporting _real_ regressions - 
and not waste their time and energy on self-inflicted wounds.

The four very real downsides are:

1) I dont think it's honest to make an artificial distinction between a 
   user-visible bug that can be fixed via a one-time tweak to a .config, and 
   a user-visible bug that can be fixed via a one-time upgrade to a fixed 
   kernel.

   As far as the tester is involved the two are largely the same, and both 
   were caused by this shiny new 'upstream kernel' thing they just tested.

   Yes, to us developers there's a fundamental difference because one is a
   fix in the code the other is a change in the environment - but the user
   really doesnt make that distinction - both are largely black boxes to
   them.

   Also, it can actually get _worse_ than a regression: if it gets declared
   a feature/annoyance and no action is taken - then it's an unfixed bug and
   that's far worse than even the painful memory of a fixed bug.

2) Furthermore, many testers dont touch early -rcs because they know they
   have rough edges. So it's a linearly ongoing cost beyond -rc1.

3) It's not the individual small annoyances that matter but the sheer sum of 
   of such annoyances when migrating from one kernel to another. I still
   struggle with some of such issues myself when testing back to some old 
   kernel and keep wasting time on it - again and again. Keeping oldconfig 
   compatibility is really a prime-type quality of Linux kernel testing i 
   think.

   Especially a casual tester will be discouraged by such an experience:
   and more so if it's clearly avoidable via a few trivial tweaks - and the 
   tester senses this 'ease of fix' intuitively and gets a "not a bug" 
   pushback.

4) Also, some maintainers are using every excuse they can find to not have 
   to keep 'make oldconfig' compatibility. That is not because they
   are lazy, embarrased and defensive or evil, but it is a natural reaction: 
   they only see the small trivial annoyance they intruduce themselves - 
   which is in a code area and usecase they are prominently familiar with, 
   so they cannot personally relate to the trouble that users go through if 
   they hit such issues.

   But the thing is, we've got dozens and dozens of critical subsystems, and 
   if each one does just a single such stupid looking tiny thing in a kernel 
   cycle it mounts up to a real force. The sheer size of Linux is a real 
   multiplicator factor here IMO. The moment Linus condones it the precedent 
   is set and everyone will just say "others do it too every now and then 
   and Linus doesnt mind so buzz off".

In my experience the sum of such small stupid careless migration annoyances 
during upgrades snowballs way too much in practice, and it has become the 
main vector along which we lose good testers - so i am never shy to flame 
folks if they introduce such issues ;-) YMMV.

</soapbox ;) >

	Ingo

Re: [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[Jeff Chua]

On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 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 (31 days old)
> References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4

Latest linux git pull seems to behave slightly better. Restarting the
interface a few times fixes the problem 70% of the time. The rest of
the time, it can't associate with the AP.

Jeff.

Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3

[Benjamin Herrenschmidt]

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

Can you check if it's still broken ?

59b608c2c33feacc8be281ec3ba9ca2a3a5cb9a7 might have fixed it...

Cheers,
Ben.

> 
> 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 (19 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>
> 

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Bron Gondwana]

On Wed, Feb 04, 2009 at 07:56:06PM +0100, Ingo Molnar wrote:
>    [...] it is a natural reaction: 
>    they only see the small trivial annoyance they intruduce themselves - 
>    which is in a code area and usecase they are prominently familiar with, 
>    so they cannot personally relate to the trouble that users go through if 
>    they hit such issues.

Amen.  Preach it.  I spent quite a while just a week ago arguing that
every semi-loaded machine out there using epoll should not require the
admin to discover that their previously happy software stack was
suddenly hitting an artificially tiny per-user instances count.

Luckily I was able to find multiple blog posts and mailing list archives
with people who had literally spent _days_ tracking down why things had
broken for them when they upgraded to a new -stable kernel.

You really do have to assume that your users don't have time for this
shit.  Anything that really can't DTRT automatically needs to be covered
with plenty of easy to follow instructions on how to fix the problem -
because for someone unfamiliar with that area of the system it really 
does take enormous effort to track down what's changed.

Bron.

Re: [Bug #12613] [Suspend regression][DRM, RADEON]

[etienne]

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 (8 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 is still here with today's git
regards
Etienne

Re: [Bug #12491] i915 lockdep warning

[Roland Dreier]

 > 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 (23 days old)
 > References	: http://marc.info/?l=linux-kernel&m=123188898423532&w=4

Looking at the code, it seems that the issue is that the DRM
struct_mutex must be taken inside mmap_sem (because struct_mutex is
taken in drm_vm_open(), which is called with mmap_sem already held), but
i915_gem_execbuffer() does a copy_to_user() while holding struct_mutex,
and if this copy faults, then the VM tries to acquire mmap_sem -- ie
lockdep identifies correctly a potential AB/BA deadlock.

I don't pretend to fully understand the DRM or GEM, but a possible fix
is below -- would be worth it to test and review, and get into 2.6.29 if
it is a correct fix:

---
i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()

Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
(which is called with mmap_sem already held) takes dev->struct_mutex.
So this is a potential AB-BA deadlock.

The way that i915_gem_execbuffer() triggers a page fault is by doing
copy_to_user() when returning new buffer offsets back to userspace;
however there is no reason to hold the struct_mutex when doing this
copy, since what is being copied is a private array anyway.  So we can
fix the potential deadlock (and get rid of the lockdep warning) by
simply moving the copy_to_user() outside of where struct_mutex is held.

This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.

Reported-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
 drivers/gpu/drm/i915/i915_gem.c |   21 ++++++++++++---------
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index debad5c..23aad8c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2610,15 +2610,6 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
 
 	i915_verify_inactive(dev, __FILE__, __LINE__);
 
-	/* Copy the new buffer offsets back to the user's exec list. */
-	ret = copy_to_user((struct drm_i915_relocation_entry __user *)
-			   (uintptr_t) args->buffers_ptr,
-			   exec_list,
-			   sizeof(*exec_list) * args->buffer_count);
-	if (ret)
-		DRM_ERROR("failed to copy %d exec entries "
-			  "back to user (%d)\n",
-			   args->buffer_count, ret);
 err:
 	for (i = 0; i < pinned; i++)
 		i915_gem_object_unpin(object_list[i]);
@@ -2628,6 +2619,18 @@ err:
 
 	mutex_unlock(&dev->struct_mutex);
 
+	if (!ret) {
+		/* Copy the new buffer offsets back to the user's exec list. */
+		ret = copy_to_user((struct drm_i915_relocation_entry __user *)
+				   (uintptr_t) args->buffers_ptr,
+				   exec_list,
+				   sizeof(*exec_list) * args->buffer_count);
+		if (ret)
+			DRM_ERROR("failed to copy %d exec entries "
+				  "back to user (%d)\n",
+				  args->buffer_count, ret);
+	}
+
 pre_mutex_err:
 	drm_free(object_list, sizeof(*object_list) * args->buffer_count,
 		 DRM_MEM_DRIVER);

Re: [Bug #12601] virt-manager broken on 2.6.29-rc2

[Stephen Hemminger]

On Wed,  4 Feb 2009 11:24:04 +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=12601
> Subject		: virt-manager broken on 2.6.29-rc2
> Submitter	: Stephen Hemminger <shemminger@vyatta.com>
> Date		: 2009-01-29 5:21 (7 days old)
> References	: http://marc.info/?l=linux-kernel&m=123320655819589&w=4
> 
> 

This was in linux-next and already fixed.

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

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

Re: [Bug #12598] tg3 dead after resume

[Parag Warudkar]

On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12598
> Subject		: tg3 dead after resume
> Submitter	: Parag Warudkar <parag.lkml@gmail.com>
> Date		: 2009-01-29 0:14 (7 days old)
> References	: http://marc.info/?l=linux-kernel&m=123318968501524&w=4
> Handled-By	: Linus Torvalds <torvalds@linux-foundation.org>
> 		  Rafael J. Wysocki <rjw@sisk.pl>
> Patch		: http://marc.info/?l=linux-kernel&m=123365342301877&w=4

OK to close - haven't checked if the patch made it to Linus' tree, 
assuming yes.

Parag

Re: [Bug #12417] glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Ingo Molnar wrote:
> 
> * Alexey Fisher <bug-track@fisher-privat.net> wrote:
> 
> > Ingo Molnar schrieb:
> >> * 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=12417
> >>> Subject		: glx performance drop with: "x86: PAT: implement track/untrack of pfnmap regions for x86 - v3"
> >>> Submitter	: Alexey Fisher <bug-track@fisher-privat.net>
> >>> Date		: 2009-01-06 18:46 (30 days old)
> >>> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5899329b19100c0b82dc78e9b21ed8b920c9ffb3
> >>> References	: http://marc.info/?l=linux-kernel&m=123126782822696&w=4
> >>> Handled-By	: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
> >>> 		  Ingo Molnar <mingo@elte.hu>
> >>>
> >>
> >> this should be fixed in latest -git. Alexey, can you confirm?
> >>
> >> 	Ingo
> >
> > I confirm it. It working  great with latest git 2.6.29-rc3-00495-gdcf6a79.
> 
> Thanks for the testing!

Closed.

Thanks,
Rafael

Re: [Bug #12611] kernel BUG at kernel/cgroup.c:398!

[Li Zefan]

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=12611
> Subject		: kernel BUG at kernel/cgroup.c:398!
> Submitter	: Bharata B Rao <bharata@linux.vnet.ibm.com>
> Date		: 2009-01-28 15:49 (8 days old)
> References	: http://marc.info/?l=linux-kernel&m=123315721707796&w=4
> 

It has been fixed by the following commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=839ec5452ebfd5905b9c69b20ceb640903a8ea1a

Re: [Bug #12491] i915 lockdep warning

[Rafael J. Wysocki]

[Adding CCs.]

On Wednesday 04 February 2009, Roland Dreier wrote:
>  > 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 (23 days old)
>  > References	: http://marc.info/?l=linux-kernel&m=123188898423532&w=4
> 
> Looking at the code, it seems that the issue is that the DRM
> struct_mutex must be taken inside mmap_sem (because struct_mutex is
> taken in drm_vm_open(), which is called with mmap_sem already held), but
> i915_gem_execbuffer() does a copy_to_user() while holding struct_mutex,
> and if this copy faults, then the VM tries to acquire mmap_sem -- ie
> lockdep identifies correctly a potential AB/BA deadlock.
> 
> I don't pretend to fully understand the DRM or GEM, but a possible fix
> is below -- would be worth it to test and review, and get into 2.6.29 if
> it is a correct fix:
> 
> ---
> i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()
> 
> Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
> takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
> (which is called with mmap_sem already held) takes dev->struct_mutex.
> So this is a potential AB-BA deadlock.
> 
> The way that i915_gem_execbuffer() triggers a page fault is by doing
> copy_to_user() when returning new buffer offsets back to userspace;
> however there is no reason to hold the struct_mutex when doing this
> copy, since what is being copied is a private array anyway.  So we can
> fix the potential deadlock (and get rid of the lockdep warning) by
> simply moving the copy_to_user() outside of where struct_mutex is held.
> 
> This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.
> 
> Reported-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c |   21 ++++++++++++---------
>  1 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index debad5c..23aad8c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2610,15 +2610,6 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
>  
>  	i915_verify_inactive(dev, __FILE__, __LINE__);
>  
> -	/* Copy the new buffer offsets back to the user's exec list. */
> -	ret = copy_to_user((struct drm_i915_relocation_entry __user *)
> -			   (uintptr_t) args->buffers_ptr,
> -			   exec_list,
> -			   sizeof(*exec_list) * args->buffer_count);
> -	if (ret)
> -		DRM_ERROR("failed to copy %d exec entries "
> -			  "back to user (%d)\n",
> -			   args->buffer_count, ret);
>  err:
>  	for (i = 0; i < pinned; i++)
>  		i915_gem_object_unpin(object_list[i]);
> @@ -2628,6 +2619,18 @@ err:
>  
>  	mutex_unlock(&dev->struct_mutex);
>  
> +	if (!ret) {
> +		/* Copy the new buffer offsets back to the user's exec list. */
> +		ret = copy_to_user((struct drm_i915_relocation_entry __user *)
> +				   (uintptr_t) args->buffers_ptr,
> +				   exec_list,
> +				   sizeof(*exec_list) * args->buffer_count);
> +		if (ret)
> +			DRM_ERROR("failed to copy %d exec entries "
> +				  "back to user (%d)\n",
> +				  args->buffer_count, ret);
> +	}
> +
>  pre_mutex_err:
>  	drm_free(object_list, sizeof(*object_list) * args->buffer_count,
>  		 DRM_MEM_DRIVER);
> --

Re: [Bug #12598] tg3 dead after resume

[Jesse Barnes]

On Wednesday, February 4, 2009 4:43 pm Parag Warudkar wrote:
> On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12598
> > Subject		: tg3 dead after resume
> > Submitter	: Parag Warudkar <parag.lkml@gmail.com>
> > Date		: 2009-01-29 0:14 (7 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123318968501524&w=4
> > Handled-By	: Linus Torvalds <torvalds@linux-foundation.org>
> > 		  Rafael J. Wysocki <rjw@sisk.pl>
> > Patch		: http://marc.info/?l=linux-kernel&m=123365342301877&w=4
>
> OK to close - haven't checked if the patch made it to Linus' tree,
> assuming yes.

It's on its way.  Just applied it to my for-linus branch.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Ingo Molnar]

(Cc:-ed Davide)

* Bron Gondwana <brong@fastmail.fm> wrote:

> On Wed, Feb 04, 2009 at 07:56:06PM +0100, Ingo Molnar wrote:
> >    [...] it is a natural reaction: 
> >    they only see the small trivial annoyance they intruduce themselves - 
> >    which is in a code area and usecase they are prominently familiar with, 
> >    so they cannot personally relate to the trouble that users go through if 
> >    they hit such issues.
> 
> Amen.  Preach it.  I spent quite a while just a week ago arguing that 
> every semi-loaded machine out there using epoll should not require the 
> admin to discover that their previously happy software stack was suddenly 
> hitting an artificially tiny per-user instances count.
> 
> Luckily I was able to find multiple blog posts and mailing list archives 
> with people who had literally spent _days_ tracking down why things had 
> broken for them when they upgraded to a new -stable kernel.
> 
> You really do have to assume that your users don't have time for this 
> shit.  Anything that really can't DTRT automatically needs to be covered 
> with plenty of easy to follow instructions on how to fix the problem - 
> because for someone unfamiliar with that area of the system it really does 
> take enormous effort to track down what's changed.

do you know which commit that was (or which exact tunable default value it 
is about) and whether we could restore the old default safely, and whether 
there's some reasonable minium must-have value that still works well in 
practice?

With Moore's law still alive and kicking there's normally no reason to 
narrow defaults - if then they get increased or get changed to some 
auto-size-to-hw-capabilities dynamic method.

Upstream defaults usually get narrowed only for really good reasons and 
often the reason is DoS and security and a specific testcase that kills a 
default box with a too large default. Sometimes they get narrowed spuriously 
and then we can fix things reasonably.

	Ingo

Re: [Bug #12505] 2.6.29-rc1 Firefox crashing on page load

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Justin Mattock wrote:
> On Wed, Feb 4, 2009 at 4:46 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Justin Mattock <justinmattock@gmail.com> wrote:
> >
> >> On Wed, Feb 4, 2009 at 2:24 AM, 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=12505
> >> > Subject         : 2.6.29-rc1 Firefox crashing on page load
> >> > Submitter       : Justin Madru <jdm64@gawab.com>
> >> > Date            : 2009-01-16 20:56 (20 days old)
> >> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
> >> > References      : http://marc.info/?l=linux-kernel&m=123213941914274&w=4
> >> > Handled-By      : Justin P. Mattock <justinmattock@gmail.com>
> >> >
> >> >
> >> >
> >>
> >> Well the hardest for this, was to reproduce
> >> the error.(never did). I guess it can be taken
> >> of if there was a patch for the fix, and the patch
> >> made it into the main tree. but if this  is a firefox
> >> issue, then a report needs to be filed with them.
> >> so overall my answer is "I don't know."
> >> :^)
> >
> > the error is spurious because gcc randomly stomps on user register state so
> > the effects can be rather random and unpredictable.
> >
> > The fix:
> >
> >  552b8aa: Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"
> >
> > was included in -rc2 already, so please test latest -git whether you can see
> > any such troubles.
> >
> >        Ingo
> >
> 
> Sure I'll test it.
> I'm just in the process of compiling libc.
> which looks like I'll be here for a while.

I've closed the bug as hopefully fixed.

Thanks,
Rafael

Re: [Bug #12511] WARNING: at drivers/dma/dmaengine.c:352

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Dan Williams wrote:
> On Wed, Feb 4, 2009 at 3:24 AM, 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).
> >
> 
> This should be resolved as of commit 83436a05 "dmaengine: kill some
> dubious WARN_ONCEs"

Thanks, closed.

Rafael

Re: [Bug #12602] CRED changes causing setuid failures

[Rafael J. Wysocki]

On Wednesday 04 February 2009, David Smith 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=12602
> > Subject		: CRED changes causing setuid failures
> > Submitter	: David Smith <dsmith@redhat.com>
> > Date		: 2009-01-29 21:35 (7 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d84f4f992cbd76e8f39c488cf0c5d123843923b1
> > References	: http://marc.info/?l=linux-kernel&m=123326501813668&w=4
> 
> I've verified this still exists in 2.6.29-rc3.
> 
> (git describe says I'm at v2.6.29-rc3-495-gdcf6a79)

Thanks for the update.

Rafael

Re: [Bug #12613] [Suspend regression][DRM, RADEON]

[Rafael J. Wysocki]

On Wednesday 04 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 (8 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 is still here with today's git

Thanks for the update.

Rafael

Re: [Bug #12591] NULL pointer dereference in blk_queue_io_stat

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Jens Axboe wrote:
> On Wed, Feb 04 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=12591
> > Subject		: NULL pointer dereference in blk_queue_io_stat
> > Submitter	: Petr Vandrovec <vandrove@vc.cvut.cz>
> > Date		: 2009-01-31 23:58 (5 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc58ba9468d94d62c56ab9b47173583ec140b165
> > Handled-By	: Jens Axboe <jens.axboe@oracle.com>
> 
> This one is already fixed in -git by commit
> fb8ec18c316d869271137c97320dbfd2def56569.

Thanks, closed.

Rafael

Re: [Bug #12615] boot hangs while bringing up gianfar ethernet

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Ira Snyder wrote:
> On Wed, Feb 04, 2009 at 11:24:08AM +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=12615
> > Subject		: boot hangs while bringing up gianfar ethernet
> > Submitter	: Ira Snyder <iws@ovro.caltech.edu>
> > Date		: 2009-01-29 19:41 (7 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123325817201665&w=4
> > 
> > 
> 
> Tested this morning with Linux version 2.6.29-rc3-00563-g37f752c, and I
> still see the same behavior.

Thanks for the update.

Rafael

Re: [Bug #12601] virt-manager broken on 2.6.29-rc2

[Rafael J. Wysocki]

On Thursday 05 February 2009, Stephen Hemminger wrote:
> On Wed,  4 Feb 2009 11:24:04 +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=12601
> > Subject		: virt-manager broken on 2.6.29-rc2
> > Submitter	: Stephen Hemminger <shemminger@vyatta.com>
> > Date		: 2009-01-29 5:21 (7 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123320655819589&w=4
> > 
> > 
> 
> This was in linux-next and already fixed.

Thanks, closed.

Rafael

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Bron Gondwana]

On Thu, Feb 05, 2009 at 02:08:11AM +0100, Ingo Molnar wrote:
> 
> (Cc:-ed Davide)

eep

> * Bron Gondwana <brong@fastmail.fm> wrote:
> 
> > On Wed, Feb 04, 2009 at 07:56:06PM +0100, Ingo Molnar wrote:
> > >    [...] it is a natural reaction: 
> > >    they only see the small trivial annoyance they intruduce themselves - 
> > >    which is in a code area and usecase they are prominently familiar with, 
> > >    so they cannot personally relate to the trouble that users go through if 
> > >    they hit such issues.
> > 
> > Amen.  Preach it.  I spent quite a while just a week ago arguing that 
> > every semi-loaded machine out there using epoll should not require the 
> > admin to discover that their previously happy software stack was suddenly 
> > hitting an artificially tiny per-user instances count.
> > 
> > Luckily I was able to find multiple blog posts and mailing list archives 
> > with people who had literally spent _days_ tracking down why things had 
> > broken for them when they upgraded to a new -stable kernel.
> > 
> > You really do have to assume that your users don't have time for this 
> > shit.  Anything that really can't DTRT automatically needs to be covered 
> > with plenty of easy to follow instructions on how to fix the problem - 
> > because for someone unfamiliar with that area of the system it really does 
> > take enormous effort to track down what's changed.
> 
> do you know which commit that was (or which exact tunable default value it 
> is about) and whether we could restore the old default safely, and whether 
> there's some reasonable minium must-have value that still works well in 
> practice?

Oh, it got sorted out eventually, but not without a whole lot of debate
about how it wasn't that hard (per individual).  Let's not stir this one
up again :)  We've resolved it to everyone's satisfaction.

It's the more abstract "I understand the issue and it's easy for me 
to set a sane config for my environment" being extended to everyone 
having to understand yet another bloody tunable.

And I'm somewhat guilty of it myself with Cyrus.  You run into the
thorny issue of: there's (a) the sane choice, (b) the backwards
compatible choice.  Every new site should be running (a), but you
don't want to ship a new stable version with (a) as the default
because it will break everything and people will need to figure out
what your stupid little change was and why it broke them.  Especially
if the underlying issue doesn't actually bother their config.

I tend to side with defaulting to (b), and the basic config file on
our of our imap servers just keeps getting longer.
 
> With Moore's law still alive and kicking there's normally no reason to 
> narrow defaults - if then they get increased or get changed to some 
> auto-size-to-hw-capabilities dynamic method.

It was an N^2 issue.  I appreciate the DoS risk it solved, just that
the solution was a stab in the dark, and it wound up hitting a lot
more people than expected (who knew that most epoll users create one
watcher per process, but still create lots of processes as well,
obviously not many people until it was shown to affect at least
postfix, apache and java.  Quite the collection!)

> Upstream defaults usually get narrowed only for really good reasons and 
> often the reason is DoS and security and a specific testcase that kills a 
> default box with a too large default. Sometimes they get narrowed spuriously 
> and then we can fix things reasonably.

Yeah.  It's a pain - especially since more fine-grained tracking to
distinguish between a DoS and a reasonable user comes with its own costs
(see companies that expect you to track your time in 5 minute
increments, and act all surprised when half of everyone's time
comes back coded as "filling in the stupid timesheets")

Bron.

Re: [Bug #12616] boot hang: async vs. kexec

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Randy Dunlap 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=12616
> > Subject		: boot hang: async vs. kexec
> > Submitter	: Randy Dunlap <randy.dunlap@oracle.com>
> > Date		: 2009-01-29 13:15 (7 days old)
> > References	: http://lkml.org/lkml/2009/1/29/359
> 
> Please reject this for now.  I'll keep debugging/working on it
> and see if any fixes are needed.

Done.

Thanks,
Rafael

Re: [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Jeff Chua wrote:
> On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > 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 (31 days old)
> > References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> 
> Latest linux git pull seems to behave slightly better. Restarting the
> interface a few times fixes the problem 70% of the time. The rest of
> the time, it can't associate with the AP.

Thanks for the update, there is a patch for you to test at
http://bugzilla.kernel.org/show_bug.cgi?id=12414#c3

Rafael

Re: [Bug #12505] 2.6.29-rc1 Firefox crashing on page load

[Justin Mattock]

On Wed, Feb 4, 2009 at 5:08 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday 04 February 2009, Justin Mattock wrote:
>> On Wed, Feb 4, 2009 at 4:46 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> >
>> > * Justin Mattock <justinmattock@gmail.com> wrote:
>> >
>> >> On Wed, Feb 4, 2009 at 2:24 AM, 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=12505
>> >> > Subject         : 2.6.29-rc1 Firefox crashing on page load
>> >> > Submitter       : Justin Madru <jdm64@gawab.com>
>> >> > Date            : 2009-01-16 20:56 (20 days old)
>> >> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4217458dafaa57d8e26a46f5d05ab8c53cf64191
>> >> > References      : http://marc.info/?l=linux-kernel&m=123213941914274&w=4
>> >> > Handled-By      : Justin P. Mattock <justinmattock@gmail.com>
>> >> >
>> >> >
>> >> >
>> >>
>> >> Well the hardest for this, was to reproduce
>> >> the error.(never did). I guess it can be taken
>> >> of if there was a patch for the fix, and the patch
>> >> made it into the main tree. but if this  is a firefox
>> >> issue, then a report needs to be filed with them.
>> >> so overall my answer is "I don't know."
>> >> :^)
>> >
>> > the error is spurious because gcc randomly stomps on user register state so
>> > the effects can be rather random and unpredictable.
>> >
>> > The fix:
>> >
>> >  552b8aa: Revert "x86: signal: change type of paramter for sys_rt_sigreturn()"
>> >
>> > was included in -rc2 already, so please test latest -git whether you can see
>> > any such troubles.
>> >
>> >        Ingo
>> >
>>
>> Sure I'll test it.
>> I'm just in the process of compiling libc.
>> which looks like I'll be here for a while.
>
> I've closed the bug as hopefully fixed.
>
> Thanks,
> Rafael
>

Cool,

-- 
Justin P. Mattock

Re: [Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Christian Borntraeger wrote:
> Am Wednesday 04 February 2009 11:23:55 schrieb 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=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 (31 days old)
> > References	: http://marc.info/?l=linux-wireless&m=123115178019082&w=4
> 
> Patch is available but not yet upstream:
> http://marc.info/?l=linux-wireless&m=123316414222201&w=2 

Thanks, I've updated the bug entry.

Rafael

Re: [Bug #12495] thinkpad problems during resume

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Christian Borntraeger wrote:
> Am Wednesday 04 February 2009 11:23:58 schrieb 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=12495
> > Subject		: thinkpad problems during resume
> > Submitter	: Christian Borntraeger <borntraeger@de.ibm.com>
> > Date		: 2009-01-17 15:48 (19 days old)
> > First-Bad-Commit:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
> >=e39ad415ac15116df213dfa2aa2a4f1b0857af9c References	:
> > http://marc.info/?l=linux-kernel&m=123220746125479&w=4
> > http://marc.info/?l=linux-kernel&m=123170361827197&w=4
> > Handled-By	: Mike Travis <travis@sgi.com>
> > Patch		: http://lkml.org/lkml/2009/1/16/375
> > 		  http://lkml.org/lkml/2009/1/16/376
> > 		  http://lkml.org/lkml/2009/1/16/378
> 
> Fixed upstream. 

Thanks, closed.

Rafael

Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Andrey Borzenkov wrote:
> On 4 of February 2009 13:24:06 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 (9 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> 
> for me it is fixed with
> http://marc.info/?l=linux-kernel&m=123365581406194&w=2 

Thanks, I've updated the bug entry.

Rafael

Re: [Bug #12611] kernel BUG at kernel/cgroup.c:398!

[Rafael J. Wysocki]

On Thursday 05 February 2009, Li Zefan 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=12611
> > Subject		: kernel BUG at kernel/cgroup.c:398!
> > Submitter	: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > Date		: 2009-01-28 15:49 (8 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123315721707796&w=4
> > 
> 
> It has been fixed by the following commit:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=839ec5452ebfd5905b9c69b20ceb640903a8ea1a

Already closed.

Thanks,
Rafael

Re: [Bug #12416] Recent change to kernel spikes out ccache/distcc

[Theodore Tso]

On Wed, Feb 04, 2009 at 11:23:55AM +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=12416
> Subject		: Recent change to kernel spikes out ccache/distcc
> Submitter	: Theodore Ts'o <tytso@mit.edu>
> Date		: 2009-01-06 15:15 (30 days old)
> References	: http://marc.info/?l=linux-kernel&m=123125495000603&w=4
> Patch		: http://lkml.org/lkml/2009/1/20/78

This can be closed; Sam reverted the necessary patch the relevent
commits in 2ea03891, which is in Linus's tree.

Rafael, I've closed the bug in the Kernel Bugzilla for your convenience.

Thanks,

	     	    	       	   	  	   - Ted

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Linus Torvalds wrote:
> 
> On Wed, 4 Feb 2009, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12599
> > Subject		: dri /dev node disappeared with 2.6.29-rc1
> > Submitter	: Norbert Preining <preining@logic.at>
> > Date		: 2009-01-15 13:42 (21 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123202701026647&w=4
> 
> I think this one is simply that Intel DRI now requires CONFIG_FB.
> 
> So make sure that you say yes to the CONFIG_FB question (easiest fix: just 
> edit the .config file and change the line "# CONFIG_FB is not set" to 
> "CONFIG_FB=y" and do "make oldconfig" - I realize that people think that 
> graphical config front-ends are simpler, but often just editing the file 
> is the quickest way).

Well, I always have doubts whether to list such things or not and I usually
end up deciding that listing is probably better than not listing.

I think I'll close this one, it's got enough attention IMO.

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12591
> > Subject		: NULL pointer dereference in blk_queue_io_stat
> > Submitter	: Petr Vandrovec <vandrove@vc.cvut.cz>
> > Date		: 2009-01-31 23:58 (5 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bc58ba9468d94d62c56ab9b47173583ec140b165
> > Handled-By	: Jens Axboe <jens.axboe@oracle.com>
> 
> I think this one is fixed by commit fb8ec18c316d8.

Closed.

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12511
> > Subject		: WARNING: at drivers/dma/dmaengine.c:352
> > Submitter	: Ingo Molnar <mingo@elte.hu>
> > Date		: 2009-01-19 21:31 (17 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123240070614443&w=4
> > Handled-By	: Dan Williams <dan.j.williams@intel.com>
> 
> This warning just got removed as bogus.
> 
> Commit 83436a0560e9ef8af2f0796264dde4bed1415359

Closed.
 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12506
> > Subject		: Undefined symbols when CONFIG_MFD_PCF50633 is enabled
> > Submitter	: Ozan Çağlayan <ozan@pardus.org.tr>
> > Date		: 2009-01-17 10:56 (19 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123218991104592&w=4
> 
> Commit 9e6f8ed7c3a303d37eb119847dd3029701e37e28

Closed.

Thanks,
Rafael

Re: [Bug #12416] Recent change to kernel spikes out ccache/distcc

[Rafael J. Wysocki]

On Thursday 05 February 2009, Theodore Tso wrote:
> On Wed, Feb 04, 2009 at 11:23:55AM +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=12416
> > Subject		: Recent change to kernel spikes out ccache/distcc
> > Submitter	: Theodore Ts'o <tytso@mit.edu>
> > Date		: 2009-01-06 15:15 (30 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123125495000603&w=4
> > Patch		: http://lkml.org/lkml/2009/1/20/78
> 
> This can be closed; Sam reverted the necessary patch the relevent
> commits in 2ea03891, which is in Linus's tree.
> 
> Rafael, I've closed the bug in the Kernel Bugzilla for your convenience.

Great, thanks a lot!

Best,
Rafael

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Eric Anholt]

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

On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Wed, 4 Feb 2009, Norbert Preining wrote:
> > > 
> > > The problem is that if you have a configuration under 2.6.28 without 
> > > CONFIG_FB and just call make oldconfig, or even make config and don't 
> > > know that you loose the DRM. And I was using make oldconfig (there is a 
> > > graphical config?? ;-))
> > 
> > Sure. It's inconvenient, no question about that. I asked the i915 people 
> > to look into not requiring CONFIG_FB, and I hope they will, but my point 
> > is that I don't think we can consider "small one-time inconvenience" to be 
> > a "regression".
> 
> if you mean that as a general principle, there's four very real downsides in 
> my opinion.
> 
> Firstly, we could have done better (and still can do better), via various 
> easy and non-intrusive measures:
> 
>    - We could add a runtime warning:
> 
>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
>       loses the I915 setting silently - placed in a key DRM ioctl, would 
>       have gone a long way addressing the issue. Testers do notice kernel 
>       warnings that pop up when their X gets slow. (This approach might also 
>       have the added bonus of warning folks who enable the wrong driver for 
>       the hardware.)
> 
>    - Or we could add a more thoughtful Kconfig migration:
> 
>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
>       DRM_I915 as a non-interactive migration helper: if set, it 
>       auto-selects both FB and DRM_I915_FB.
> 
>       While CONFIG_FB is an interactive Kconfig option so a select can be 
>       dangerous to a correct dependency tree, it seems safe to do in this 
>       specific case because it seems to be a rather leaf entry with no 
>       dependencies.

I tried select FB.  It's the right thing to do.  It doesn't work.  I
posted to the mailing list two weeks ago about the insane dependency
chain that kbuild comes up with and fails on when we do this, and got
silence.

Believe me, I hate this inconvenience to users even more than each of
you do, because I get to deal with the reports.  But I haven't had the
time to sit down and figure out what drugs kbuild is on, or even how to
work around it (despite IRC help from a few other kernel guys).

The alternative I can see is to ifdef the code for something that will
be on by default and which stable userland will require in 6 months.
That seems wrong.

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

Re: [Bug #12605] Suspend regression, hang after matroxfb

[Eric Sesterhenn]

* 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=12605
> Subject		: Suspend regression, hang after matroxfb
> Submitter	: Eric Sesterhenn <snakebyte@gmx.de>
> Date		: 2009-01-29 12:58 (7 days old)
> References	: http://thread.gmane.org/gmane.linux.power-management.general/12640
> Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
> Patch		: http://marc.info/?l=linux-kernel&m=123335902122029&w=4

with todays -git I still get the same error, I have seen that some of 
your PM patches got applied, seems the one I need wasnt one of them.

Greetings, Eric

Re: [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[Jeff Chua]

On Thu, Feb 5, 2009 at 9:37 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday 04 February 2009, Jeff Chua wrote:
>> On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > 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 (31 days old)
>> > References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
>>
>> Latest linux git pull seems to behave slightly better. Restarting the
>> interface a few times fixes the problem 70% of the time. The rest of
>> the time, it can't associate with the AP.
>
> Thanks for the update, there is a patch for you to test at
> http://bugzilla.kernel.org/show_bug.cgi?id=12414#c3

Ok, will try that patch next weekend when I get home.

Thanks for the patch.

Jeff.

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Norbert Preining]

On Mi, 04 Feb 2009, Eric Anholt wrote:
> I tried select FB.  It's the right thing to do.  It doesn't work.  I
> posted to the mailing list two weeks ago about the insane dependency
> chain that kbuild comes up with and fails on when we do this, and got
> silence.

Right, I agree that I have tried to do it myself, and it was impossible
when:
- editing .config by hand removing any *FB* and *DRM* related stuff
- calling make oldconfig
in all cases DRM was disabled.

I managed only to activate it by hand-editing .config and there putting
by hand
	CONFIG_something=y
(don't remember which it was) and after that the make oldconfig did
actually select everything I need.

So, that seems to be a Kconfig bug.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
KINGSTON BAGPUISE (n.)
A forty-year-old sixteen-stone man trying to commit suicide by
jogging.
			--- Douglas Adams, The Meaning of Liff

Re: [Bug #12605] Suspend regression, hang after matroxfb

[Rafael J. Wysocki]

On Thursday 05 February 2009, Eric Sesterhenn 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=12605
> > Subject		: Suspend regression, hang after matroxfb
> > Submitter	: Eric Sesterhenn <snakebyte@gmx.de>
> > Date		: 2009-01-29 12:58 (7 days old)
> > References	: http://thread.gmane.org/gmane.linux.power-management.general/12640
> > Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
> > Patch		: http://marc.info/?l=linux-kernel&m=123335902122029&w=4
> 
> with todays -git I still get the same error, I have seen that some of 
> your PM patches got applied, seems the one I need wasnt one of them.

No, it's not been merged yet.

Thanks,
Rafael

[PATCH] drm, i915: select framebuffer support automatically

[Ingo Molnar]

* Eric Anholt <eric@anholt.net> wrote:

> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > 
> > > On Wed, 4 Feb 2009, Norbert Preining wrote:
> > > > 
> > > > The problem is that if you have a configuration under 2.6.28 without 
> > > > CONFIG_FB and just call make oldconfig, or even make config and don't 
> > > > know that you loose the DRM. And I was using make oldconfig (there is a 
> > > > graphical config?? ;-))
> > > 
> > > Sure. It's inconvenient, no question about that. I asked the i915 people 
> > > to look into not requiring CONFIG_FB, and I hope they will, but my point 
> > > is that I don't think we can consider "small one-time inconvenience" to be 
> > > a "regression".
> > 
> > if you mean that as a general principle, there's four very real downsides in 
> > my opinion.
> > 
> > Firstly, we could have done better (and still can do better), via various 
> > easy and non-intrusive measures:
> > 
> >    - We could add a runtime warning:
> > 
> >       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
> >       that there's no DRM because CONFIG_FB is not selected and oldconfig 
> >       loses the I915 setting silently - placed in a key DRM ioctl, would 
> >       have gone a long way addressing the issue. Testers do notice kernel 
> >       warnings that pop up when their X gets slow. (This approach might also 
> >       have the added bonus of warning folks who enable the wrong driver for 
> >       the hardware.)
> > 
> >    - Or we could add a more thoughtful Kconfig migration:
> > 
> >       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
> >       DRM_I915 as a non-interactive migration helper: if set, it 
> >       auto-selects both FB and DRM_I915_FB.
> > 
> >       While CONFIG_FB is an interactive Kconfig option so a select can be 
> >       dangerous to a correct dependency tree, it seems safe to do in this 
> >       specific case because it seems to be a rather leaf entry with no 
> >       dependencies.
> 
> I tried select FB.  It's the right thing to do.  It doesn't work.  I
> posted to the mailing list two weeks ago about the insane dependency
> chain that kbuild comes up with and fails on when we do this, and got
> silence.

I mean the patch below.

I have tested it here it works fine and has no dependency problems, nor any 
build breakages on 32-bit or 64-bit x86. When you tried this you probably 
ran into the FB_I810 and FB_INTEL complication - this patch solves that too.

What do you think?

	Ingo

--------------->
>From ca835567dcb7c513a26a4396d86f12848e62de8d Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 5 Feb 2009 16:03:34 +0100
Subject: [PATCH] drm, i915: select framebuffer support automatically

Migration helper.

The i915 driver recently added a 'depends on FB' rule to its
Kconfig entry - which silently turns off DRM_I915 if someone
has a working config but no CONFIG_FB selected, and upgrades
to the latest upstream kernel.

Norbert Preining reported this problem:

   Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
   Subject     : dri /dev node disappeared with 2.6.29-rc1

So change it to "select FB", which auto-selects framebuffer
support. This way the driver keeps working, regardless of
whether FB was enabled before or not.

Kconfig select's of interactive options can be problematic to
dependencies and can cause build breakages - but in this case
it's safe because it's a leaf entry with no dependencies of its
own.

( There is some minor circular dependency fallout as FB_I810
  and FB_INTEL also used 'depends on FB' constructs - update
  those to "select FB" too. )

Reported-by: Norbert Preining <preining@logic.at>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/gpu/drm/Kconfig |    2 +-
 drivers/video/Kconfig   |    6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 5130b72..4be3acb 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -70,7 +70,7 @@ config DRM_I915
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
-	depends on FB
+	select FB
 	tristate "i915 driver"
 	help
 	  Choose this option if you have a system that has Intel 830M, 845G,
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index f026770..bf0af66 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1054,9 +1054,10 @@ config FB_RIVA_BACKLIGHT
 
 config FB_I810
 	tristate "Intel 810/815 support (EXPERIMENTAL)"
-	depends on FB && EXPERIMENTAL && PCI && X86_32
+	depends on EXPERIMENTAL && PCI && X86_32
 	select AGP
 	select AGP_INTEL
+	select FB
 	select FB_MODE_HELPERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
@@ -1119,7 +1120,8 @@ config FB_CARILLO_RANCH
 
 config FB_INTEL
 	tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support (EXPERIMENTAL)"
-	depends on FB && EXPERIMENTAL && PCI && X86
+	depends on EXPERIMENTAL && PCI && X86
+	select FB
 	select AGP
 	select AGP_INTEL
 	select FB_MODE_HELPERS

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Randy Dunlap]

Eric Anholt wrote:
> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>> On Wed, 4 Feb 2009, Norbert Preining wrote:
>>>> The problem is that if you have a configuration under 2.6.28 without 
>>>> CONFIG_FB and just call make oldconfig, or even make config and don't 
>>>> know that you loose the DRM. And I was using make oldconfig (there is a 
>>>> graphical config?? ;-))
>>> Sure. It's inconvenient, no question about that. I asked the i915 people 
>>> to look into not requiring CONFIG_FB, and I hope they will, but my point 
>>> is that I don't think we can consider "small one-time inconvenience" to be 
>>> a "regression".
>> if you mean that as a general principle, there's four very real downsides in 
>> my opinion.
>>
>> Firstly, we could have done better (and still can do better), via various 
>> easy and non-intrusive measures:
>>
>>    - We could add a runtime warning:
>>
>>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
>>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
>>       loses the I915 setting silently - placed in a key DRM ioctl, would 
>>       have gone a long way addressing the issue. Testers do notice kernel 
>>       warnings that pop up when their X gets slow. (This approach might also 
>>       have the added bonus of warning folks who enable the wrong driver for 
>>       the hardware.)
>>
>>    - Or we could add a more thoughtful Kconfig migration:
>>
>>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
>>       DRM_I915 as a non-interactive migration helper: if set, it 
>>       auto-selects both FB and DRM_I915_FB.
>>
>>       While CONFIG_FB is an interactive Kconfig option so a select can be 
>>       dangerous to a correct dependency tree, it seems safe to do in this 
>>       specific case because it seems to be a rather leaf entry with no 
>>       dependencies.
> 
> I tried select FB.  It's the right thing to do.  It doesn't work.  I
> posted to the mailing list two weeks ago about the insane dependency
> chain that kbuild comes up with and fails on when we do this, and got
> silence.

I tried what you had described in that email (from 2 weeks ago), got the
same results that you did, but kbuild does seem very confused (to me).

reference email from 2+ weeks ago:
  http://marc.info/?l=linux-kernel&m=123197341316461&w=2

Adding Sam to cc.

> Believe me, I hate this inconvenience to users even more than each of
> you do, because I get to deal with the reports.  But I haven't had the
> time to sit down and figure out what drugs kbuild is on, or even how to
> work around it (despite IRC help from a few other kernel guys).
> 
> The alternative I can see is to ifdef the code for something that will
> be on by default and which stable userland will require in 6 months.
> That seems wrong.
> 


-- 
~Randy

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Hugh Dickins]

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>

Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[Hugh Dickins]

On Wed, 4 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 (13 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>
> Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2

Yes, this does still need to be listed.  My initial patch for it was
not enough, but I think the three patches necessary have all now been
posted (though Sergei may rewrite mine).  I'm expecting Alan to gather
them together and send them in due course, but I believe he's occupied
with other stuff just at the moment.

Hugh

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> Eric Anholt wrote:
> > On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> >> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >>
> >>> On Wed, 4 Feb 2009, Norbert Preining wrote:
> >>>> The problem is that if you have a configuration under 2.6.28 without 
> >>>> CONFIG_FB and just call make oldconfig, or even make config and don't 
> >>>> know that you loose the DRM. And I was using make oldconfig (there is a 
> >>>> graphical config?? ;-))
> >>> Sure. It's inconvenient, no question about that. I asked the i915 people 
> >>> to look into not requiring CONFIG_FB, and I hope they will, but my point 
> >>> is that I don't think we can consider "small one-time inconvenience" to be 
> >>> a "regression".
> >> if you mean that as a general principle, there's four very real downsides in 
> >> my opinion.
> >>
> >> Firstly, we could have done better (and still can do better), via various 
> >> easy and non-intrusive measures:
> >>
> >>    - We could add a runtime warning:
> >>
> >>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
> >>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
> >>       loses the I915 setting silently - placed in a key DRM ioctl, would 
> >>       have gone a long way addressing the issue. Testers do notice kernel 
> >>       warnings that pop up when their X gets slow. (This approach might also 
> >>       have the added bonus of warning folks who enable the wrong driver for 
> >>       the hardware.)
> >>
> >>    - Or we could add a more thoughtful Kconfig migration:
> >>
> >>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
> >>       DRM_I915 as a non-interactive migration helper: if set, it 
> >>       auto-selects both FB and DRM_I915_FB.
> >>
> >>       While CONFIG_FB is an interactive Kconfig option so a select can be 
> >>       dangerous to a correct dependency tree, it seems safe to do in this 
> >>       specific case because it seems to be a rather leaf entry with no 
> >>       dependencies.
> > 
> > I tried select FB.  It's the right thing to do.  It doesn't work.  I
> > posted to the mailing list two weeks ago about the insane dependency
> > chain that kbuild comes up with and fails on when we do this, and got
> > silence.
> 
> I tried what you had described in that email (from 2 weeks ago), got the
> same results that you did, but kbuild does seem very confused (to me).
> 
> reference email from 2+ weeks ago:
>   http://marc.info/?l=linux-kernel&m=123197341316461&w=2
> 
> Adding Sam to cc.

Check the patch i posted in this thread earlier today, it solves this 
problem.

	Ingo

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Randy Dunlap]

Ingo Molnar wrote:
> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
>> Eric Anholt wrote:
>>> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
>>>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>>
>>>>> On Wed, 4 Feb 2009, Norbert Preining wrote:
>>>>>> The problem is that if you have a configuration under 2.6.28 without 
>>>>>> CONFIG_FB and just call make oldconfig, or even make config and don't 
>>>>>> know that you loose the DRM. And I was using make oldconfig (there is a 
>>>>>> graphical config?? ;-))
>>>>> Sure. It's inconvenient, no question about that. I asked the i915 people 
>>>>> to look into not requiring CONFIG_FB, and I hope they will, but my point 
>>>>> is that I don't think we can consider "small one-time inconvenience" to be 
>>>>> a "regression".
>>>> if you mean that as a general principle, there's four very real downsides in 
>>>> my opinion.
>>>>
>>>> Firstly, we could have done better (and still can do better), via various 
>>>> easy and non-intrusive measures:
>>>>
>>>>    - We could add a runtime warning:
>>>>
>>>>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
>>>>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
>>>>       loses the I915 setting silently - placed in a key DRM ioctl, would 
>>>>       have gone a long way addressing the issue. Testers do notice kernel 
>>>>       warnings that pop up when their X gets slow. (This approach might also 
>>>>       have the added bonus of warning folks who enable the wrong driver for 
>>>>       the hardware.)
>>>>
>>>>    - Or we could add a more thoughtful Kconfig migration:
>>>>
>>>>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
>>>>       DRM_I915 as a non-interactive migration helper: if set, it 
>>>>       auto-selects both FB and DRM_I915_FB.
>>>>
>>>>       While CONFIG_FB is an interactive Kconfig option so a select can be 
>>>>       dangerous to a correct dependency tree, it seems safe to do in this 
>>>>       specific case because it seems to be a rather leaf entry with no 
>>>>       dependencies.
>>> I tried select FB.  It's the right thing to do.  It doesn't work.  I
>>> posted to the mailing list two weeks ago about the insane dependency
>>> chain that kbuild comes up with and fails on when we do this, and got
>>> silence.
>> I tried what you had described in that email (from 2 weeks ago), got the
>> same results that you did, but kbuild does seem very confused (to me).
>>
>> reference email from 2+ weeks ago:
>>   http://marc.info/?l=linux-kernel&m=123197341316461&w=2
>>
>> Adding Sam to cc.
> 
> Check the patch i posted in this thread earlier today, it solves this 
> problem.

I saw it.  I'd rather kconfig be fixed instead, if possible.

-- 
~Randy

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> Ingo Molnar wrote:
> > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > 
> >> Eric Anholt wrote:
> >>> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> >>>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >>>>
> >>>>> On Wed, 4 Feb 2009, Norbert Preining wrote:
> >>>>>> The problem is that if you have a configuration under 2.6.28 without 
> >>>>>> CONFIG_FB and just call make oldconfig, or even make config and don't 
> >>>>>> know that you loose the DRM. And I was using make oldconfig (there is a 
> >>>>>> graphical config?? ;-))
> >>>>> Sure. It's inconvenient, no question about that. I asked the i915 people 
> >>>>> to look into not requiring CONFIG_FB, and I hope they will, but my point 
> >>>>> is that I don't think we can consider "small one-time inconvenience" to be 
> >>>>> a "regression".
> >>>> if you mean that as a general principle, there's four very real downsides in 
> >>>> my opinion.
> >>>>
> >>>> Firstly, we could have done better (and still can do better), via various 
> >>>> easy and non-intrusive measures:
> >>>>
> >>>>    - We could add a runtime warning:
> >>>>
> >>>>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
> >>>>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
> >>>>       loses the I915 setting silently - placed in a key DRM ioctl, would 
> >>>>       have gone a long way addressing the issue. Testers do notice kernel 
> >>>>       warnings that pop up when their X gets slow. (This approach might also 
> >>>>       have the added bonus of warning folks who enable the wrong driver for 
> >>>>       the hardware.)
> >>>>
> >>>>    - Or we could add a more thoughtful Kconfig migration:
> >>>>
> >>>>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
> >>>>       DRM_I915 as a non-interactive migration helper: if set, it 
> >>>>       auto-selects both FB and DRM_I915_FB.
> >>>>
> >>>>       While CONFIG_FB is an interactive Kconfig option so a select can be 
> >>>>       dangerous to a correct dependency tree, it seems safe to do in this 
> >>>>       specific case because it seems to be a rather leaf entry with no 
> >>>>       dependencies.
> >>> I tried select FB.  It's the right thing to do.  It doesn't work.  I
> >>> posted to the mailing list two weeks ago about the insane dependency
> >>> chain that kbuild comes up with and fails on when we do this, and got
> >>> silence.
> >> I tried what you had described in that email (from 2 weeks ago), got the
> >> same results that you did, but kbuild does seem very confused (to me).
> >>
> >> reference email from 2+ weeks ago:
> >>   http://marc.info/?l=linux-kernel&m=123197341316461&w=2
> >>
> >> Adding Sam to cc.
> > 
> > Check the patch i posted in this thread earlier today, it solves this 
> > problem.
> 
> I saw it.  I'd rather kconfig be fixed instead, if possible.

kconfig was not broken at all in this case. It detected a circular 
dependency and did its work well.

( kconfig is broken in some areas - for example its misfeature of not 
  propagating selects along dependency chains is annoying. It should at 
  minimum warn when it sees such partial selects. But this is not one of 
  those breakages. )

	Ingo

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Randy Dunlap]

Ingo Molnar wrote:
> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
>>>
>>>> Eric Anholt wrote:
>>>>> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
>>>>>> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>>>>
>>>>>>> On Wed, 4 Feb 2009, Norbert Preining wrote:
>>>>>>>> The problem is that if you have a configuration under 2.6.28 without 
>>>>>>>> CONFIG_FB and just call make oldconfig, or even make config and don't 
>>>>>>>> know that you loose the DRM. And I was using make oldconfig (there is a 
>>>>>>>> graphical config?? ;-))
>>>>>>> Sure. It's inconvenient, no question about that. I asked the i915 people 
>>>>>>> to look into not requiring CONFIG_FB, and I hope they will, but my point 
>>>>>>> is that I don't think we can consider "small one-time inconvenience" to be 
>>>>>>> a "regression".
>>>>>> if you mean that as a general principle, there's four very real downsides in 
>>>>>> my opinion.
>>>>>>
>>>>>> Firstly, we could have done better (and still can do better), via various 
>>>>>> easy and non-intrusive measures:
>>>>>>
>>>>>>    - We could add a runtime warning:
>>>>>>
>>>>>>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
>>>>>>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
>>>>>>       loses the I915 setting silently - placed in a key DRM ioctl, would 
>>>>>>       have gone a long way addressing the issue. Testers do notice kernel 
>>>>>>       warnings that pop up when their X gets slow. (This approach might also 
>>>>>>       have the added bonus of warning folks who enable the wrong driver for 
>>>>>>       the hardware.)
>>>>>>
>>>>>>    - Or we could add a more thoughtful Kconfig migration:
>>>>>>
>>>>>>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
>>>>>>       DRM_I915 as a non-interactive migration helper: if set, it 
>>>>>>       auto-selects both FB and DRM_I915_FB.
>>>>>>
>>>>>>       While CONFIG_FB is an interactive Kconfig option so a select can be 
>>>>>>       dangerous to a correct dependency tree, it seems safe to do in this 
>>>>>>       specific case because it seems to be a rather leaf entry with no 
>>>>>>       dependencies.
>>>>> I tried select FB.  It's the right thing to do.  It doesn't work.  I
>>>>> posted to the mailing list two weeks ago about the insane dependency
>>>>> chain that kbuild comes up with and fails on when we do this, and got
>>>>> silence.
>>>> I tried what you had described in that email (from 2 weeks ago), got the
>>>> same results that you did, but kbuild does seem very confused (to me).
>>>>
>>>> reference email from 2+ weeks ago:
>>>>   http://marc.info/?l=linux-kernel&m=123197341316461&w=2
>>>>
>>>> Adding Sam to cc.
>>> Check the patch i posted in this thread earlier today, it solves this 
>>> problem.
>> I saw it.  I'd rather kconfig be fixed instead, if possible.
> 
> kconfig was not broken at all in this case. It detected a circular 
> dependency and did its work well.

Maybe.  I haven't seen an explanation for the problems that Eric
reported 2+ weeks ago.

> ( kconfig is broken in some areas - for example its misfeature of not 
>   propagating selects along dependency chains is annoying. It should at 
>   minimum warn when it sees such partial selects. But this is not one of 
>   those breakages. )


-- 
~Randy

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@oracle.com> wrote:

> > kconfig was not broken at all in this case. It detected a circular 
> > dependency and did its work well.
> 
> Maybe.  I haven't seen an explanation for the problems that Eric reported 
> 2+ weeks ago.

The thing he reported 2 weeks ago is a straightforward recursive dependency 
bug in the config entries:

  drivers/gpu/drm/Kconfig:8:error: found recursive dependency:
   DRM -> <choice> -> DRM_I915 -> FB -> FB_I810 -> AGP -> DRM

this is the precise circular dependency problem that the I810_FB and 
INTEL_FB changes in my patch solve.

Give my patch a try :-)

	Ingo

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

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

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Hugh Dickins]

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

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Dave Airlie]

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

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Jesse Barnes]

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

Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[Rafael J. Wysocki]

On Thursday 05 February 2009, Hugh Dickins wrote:
> On Wed, 4 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 (13 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>
> > Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2
> 
> Yes, this does still need to be listed.  My initial patch for it was
> not enough, but I think the three patches necessary have all now been
> posted (though Sergei may rewrite mine).  I'm expecting Alan to gather
> them together and send them in due course, but I believe he's occupied
> with other stuff just at the moment.

Thanks for the update.

Rafael

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

> 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;
>  }
> 
> 

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

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;

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

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

Re: [Bug #12497] new barrier warnings in 2.6.29-rc1

[Christoph Hellwig]

On Wed, Feb 04, 2009 at 11:23:59AM +0100, Rafael J. Wysocki wrote:
> 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 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=123177528217154&w=4
> Handled-By	: Jens Axboe <jens.axboe@oracle.com>


We're now done to a single warning per mount instead of the previous
two:

[  485.307225] end_request: I/O error, dev vdb, sector 0
[  485.604639] Filesystem "vdb": Disabling barriers, trial barrier write failed
[  485.627352] XFS mounting filesystem vdb

but it's still around.

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Hugh Dickins]

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;

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Jesse Barnes]

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

Re: [Bug #12490] ath5k related kernel panic in 2.6.29-rc1

[Bob Copeland]

On Wed,  4 Feb 2009 11:23:57 +0100 (CET), 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=12490
> Subject		: ath5k related kernel panic in 2.6.29-rc1
> Submitter	: Sergey S. Kostyliov <rathamahata@gmail.com>
> Date		: 2009-01-12 7:38 (24 days old)
> References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
> Handled-By	: Bob Copeland <me@bobcopeland.com>

Yes, this should still be listed.  Seems there is corruption of the rate
indexes but I haven't found it yet.  Felix Fietkau added to CC in case
he has any thoughts.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3

[Mikael Pettersson]

Benjamin Herrenschmidt writes:
 > 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).
 > 
 > Can you check if it's still broken ?
 > 
 > 59b608c2c33feacc8be281ec3ba9ca2a3a5cb9a7 might have fixed it...
 > 
 > Cheers,
 > Ben.

Confirmed. Adding 59b608c2c33feacc8be281ec3ba9ca2a3a5cb9a7 to
2.6.29-rc3 makes it boot fine on my G3.

Thanks,

/Mikael

 > > 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 (19 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>

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Hugh Dickins]

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;
 }

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Jesse Barnes]

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);
 }
 
 /**

Re: [Bug #12491] i915 lockdep warning

[Roland Dreier]

 > i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()

Jesse, Eric, or anybody -- does this look correct to you?  This seems to
be triggering for several people, eg
https://bugzilla.redhat.com/show_bug.cgi?id=481687

 - R.

Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[Larry Finger]

Rafael J. Wysocki wrote:
> On Thursday 05 February 2009, Hugh Dickins wrote:
>> On Wed, 4 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 (13 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>
>>> Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2
>> Yes, this does still need to be listed.  My initial patch for it was
>> not enough, but I think the three patches necessary have all now been
>> posted (though Sergei may rewrite mine).  I'm expecting Alan to gather
>> them together and send them in due course, but I believe he's occupied
>> with other stuff just at the moment.

I still have the problem as of 2.6.29-rc3-00634-g9be260a

Larry

Re: [Bug #12491] i915 lockdep warning

[Jesse Barnes]

On Friday, February 6, 2009 2:46 pm Roland Dreier wrote:
>  > i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()
>
> Jesse, Eric, or anybody -- does this look correct to you?  This seems to
> be triggering for several people, eg
> https://bugzilla.redhat.com/show_bug.cgi?id=481687

Eric's been looking at this issue, and there's some discussion about it on the 
intel-gfx list, but I'm not sure what the latest is (Eric is travelling atm).

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #12490] ath5k related kernel panic in 2.6.29-rc1

[Rafael J. Wysocki]

On Friday 06 February 2009, Bob Copeland wrote:
> On Wed,  4 Feb 2009 11:23:57 +0100 (CET), 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=12490
> > Subject		: ath5k related kernel panic in 2.6.29-rc1
> > Submitter	: Sergey S. Kostyliov <rathamahata@gmail.com>
> > Date		: 2009-01-12 7:38 (24 days old)
> > References	: http://marc.info/?l=linux-kernel&m=123174591509586&w=4
> > Handled-By	: Bob Copeland <me@bobcopeland.com>
> 
> Yes, this should still be listed.  Seems there is corruption of the rate
> indexes but I haven't found it yet.  Felix Fietkau added to CC in case
> he has any thoughts.

Thanks for the update.

Rafael

Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[Rafael J. Wysocki]

On Saturday 07 February 2009, Larry Finger wrote:
> Rafael J. Wysocki wrote:
> > On Thursday 05 February 2009, Hugh Dickins wrote:
> >> On Wed, 4 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 (13 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>
> >>> Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2
> >> Yes, this does still need to be listed.  My initial patch for it was
> >> not enough, but I think the three patches necessary have all now been
> >> posted (though Sergei may rewrite mine).  I'm expecting Alan to gather
> >> them together and send them in due course, but I believe he's occupied
> >> with other stuff just at the moment.
> 
> I still have the problem as of 2.6.29-rc3-00634-g9be260a

Thanks for the updates.

Rafael

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Hugh Dickins]

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);
>  }
>  
>  /**

RE: [Bug #12491] i915 lockdep warning

[Brandeburg, Jesse]

Roland Dreier wrote:
>  > i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()
> 
> Jesse, Eric, or anybody -- does this look correct to you?  This seems
> to be triggering for several people, eg
> https://bugzilla.redhat.com/show_bug.cgi?id=481687
> 
>  - R.

I tested this on my 965 based system that showed the issue and it seemed resolved, at least no warnings in dmesg.  Lockdep was confirmed to still be enabled.

I can mark the bug fixed in korg bugzilla too.

Thank you Roland for looking into this, good work!

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Jesse Barnes]

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

Re: [Bug #12491] i915 lockdep warning

[Roland Dreier]

[intel-gfx CC added]

 > I tested this on my 965 based system that showed the issue and it seemed resolved, at least no warnings in dmesg.  Lockdep was confirmed to still be enabled.

 > I can mark the bug fixed in korg bugzilla too.

Probably we just want to add a comment saying the patch works -- the bug
should stay open until we get the fix upstream I guess.

 > Thank you Roland for looking into this, good work!

Thanks for testing!  Patch with updated changelog (including your
tested-by) below.  Jesse [Barnes] and/or Eric please review and apply:

---

i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()

Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
(which is called with mmap_sem already held) takes dev->struct_mutex.
So this is a potential AB-BA deadlock.

The way that i915_gem_execbuffer() triggers a page fault is by doing
copy_to_user() when returning new buffer offsets back to userspace;
however there is no reason to hold the struct_mutex when doing this
copy, since what is being copied is the contents of an array private to
i915_gem_execbuffer() anyway.  So we can fix the potential deadlock (and
get rid of the lockdep warning) by simply moving the copy_to_user()
outside of where struct_mutex is held.

This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.

Reported-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
 drivers/gpu/drm/i915/i915_gem.c |   21 ++++++++++++---------
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index debad5c..23aad8c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2610,15 +2610,6 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
 
 	i915_verify_inactive(dev, __FILE__, __LINE__);
 
-	/* Copy the new buffer offsets back to the user's exec list. */
-	ret = copy_to_user((struct drm_i915_relocation_entry __user *)
-			   (uintptr_t) args->buffers_ptr,
-			   exec_list,
-			   sizeof(*exec_list) * args->buffer_count);
-	if (ret)
-		DRM_ERROR("failed to copy %d exec entries "
-			  "back to user (%d)\n",
-			   args->buffer_count, ret);
 err:
 	for (i = 0; i < pinned; i++)
 		i915_gem_object_unpin(object_list[i]);
@@ -2628,6 +2619,18 @@ err:
 
 	mutex_unlock(&dev->struct_mutex);
 
+	if (!ret) {
+		/* Copy the new buffer offsets back to the user's exec list. */
+		ret = copy_to_user((struct drm_i915_relocation_entry __user *)
+				   (uintptr_t) args->buffers_ptr,
+				   exec_list,
+				   sizeof(*exec_list) * args->buffer_count);
+		if (ret)
+			DRM_ERROR("failed to copy %d exec entries "
+				  "back to user (%d)\n",
+				  args->buffer_count, ret);
+	}
+
 pre_mutex_err:
 	drm_free(object_list, sizeof(*object_list) * args->buffer_count,
 		 DRM_MEM_DRIVER);

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

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

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Benjamin Herrenschmidt]

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.

Re: [Bug #12491] i915 lockdep warning

[Rafael J. Wysocki]

On Saturday 07 February 2009, Roland Dreier wrote:
> [intel-gfx CC added]
> 
>  > I tested this on my 965 based system that showed the issue and it seemed resolved, at least no warnings in dmesg.  Lockdep was confirmed to still be enabled.
> 
>  > I can mark the bug fixed in korg bugzilla too.
> 
> Probably we just want to add a comment saying the patch works

Yes, I have already added this information to the bug entry.

> -- the bug should stay open until we get the fix upstream I guess.

Yes, the bug will be closed as soon as it's fixed upstream.

Thanks,
Rafael

Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression

[Jesse Barnes]

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

Re: [PATCH] drm, i915: select framebuffer support automatically

[Dave Airlie]

On Fri, Feb 6, 2009 at 2:56 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Eric Anholt <eric@anholt.net> wrote:
>
>> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
>> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> >
>> > > On Wed, 4 Feb 2009, Norbert Preining wrote:
>> > > >
>> > > > The problem is that if you have a configuration under 2.6.28 without
>> > > > CONFIG_FB and just call make oldconfig, or even make config and don't
>> > > > know that you loose the DRM. And I was using make oldconfig (there is a
>> > > > graphical config?? ;-))
>> > >
>> > > Sure. It's inconvenient, no question about that. I asked the i915 people
>> > > to look into not requiring CONFIG_FB, and I hope they will, but my point
>> > > is that I don't think we can consider "small one-time inconvenience" to be
>> > > a "regression".
>> >
>> > if you mean that as a general principle, there's four very real downsides in
>> > my opinion.
>> >
>> > Firstly, we could have done better (and still can do better), via various
>> > easy and non-intrusive measures:
>> >
>> >    - We could add a runtime warning:
>> >
>> >       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB")
>> >       that there's no DRM because CONFIG_FB is not selected and oldconfig
>> >       loses the I915 setting silently - placed in a key DRM ioctl, would
>> >       have gone a long way addressing the issue. Testers do notice kernel
>> >       warnings that pop up when their X gets slow. (This approach might also
>> >       have the added bonus of warning folks who enable the wrong driver for
>> >       the hardware.)

We can't actually do this, if you don't have a DRM driver for the hw,
you don't get any device node or ioctl
to play with. X just loads the module, if it doesn't exist X
complains, nothing we could do about it in the kernel
without adding some wierdass fake drm devices.

>> >
>> >    - Or we could add a more thoughtful Kconfig migration:
>> >
>> >       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
>> >       DRM_I915 as a non-interactive migration helper: if set, it
>> >       auto-selects both FB and DRM_I915_FB.
>> >
>> >       While CONFIG_FB is an interactive Kconfig option so a select can be
>> >       dangerous to a correct dependency tree, it seems safe to do in this
>> >       specific case because it seems to be a rather leaf entry with no
>> >       dependencies.

This is the correct answer, the only other option was to allow i915 to
build without modesetting
if FB isn't selected but Intel didn't want to go down that road.

>>
>> I tried select FB.  It's the right thing to do.  It doesn't work.  I
>> posted to the mailing list two weeks ago about the insane dependency
>> chain that kbuild comes up with and fails on when we do this, and got
>> silence.
>
> I mean the patch below.
>
> I have tested it here it works fine and has no dependency problems, nor any
> build breakages on 32-bit or 64-bit x86. When you tried this you probably
> ran into the FB_I810 and FB_INTEL complication - this patch solves that too.
>
> What do you think?
>
>        Ingo
>
> --------------->
> From ca835567dcb7c513a26a4396d86f12848e62de8d Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@elte.hu>
> Date: Thu, 5 Feb 2009 16:03:34 +0100
> Subject: [PATCH] drm, i915: select framebuffer support automatically
>
> Migration helper.
>
> The i915 driver recently added a 'depends on FB' rule to its
> Kconfig entry - which silently turns off DRM_I915 if someone
> has a working config but no CONFIG_FB selected, and upgrades
> to the latest upstream kernel.
>
> Norbert Preining reported this problem:
>
>   Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
>   Subject     : dri /dev node disappeared with 2.6.29-rc1
>
> So change it to "select FB", which auto-selects framebuffer
> support. This way the driver keeps working, regardless of
> whether FB was enabled before or not.
>
> Kconfig select's of interactive options can be problematic to
> dependencies and can cause build breakages - but in this case
> it's safe because it's a leaf entry with no dependencies of its
> own.
>
> ( There is some minor circular dependency fallout as FB_I810
>  and FB_INTEL also used 'depends on FB' constructs - update
>  those to "select FB" too. )
>
> Reported-by: Norbert Preining <preining@logic.at>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>

This looks like the best option to me so I'll suck this patch into my tree.

Thanks Ingo for solving the wierdass depends chain.

Dave.

> ---
>  drivers/gpu/drm/Kconfig |    2 +-
>  drivers/video/Kconfig   |    6 ++++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 5130b72..4be3acb 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -70,7 +70,7 @@ config DRM_I915
>        select FB_CFB_FILLRECT
>        select FB_CFB_COPYAREA
>        select FB_CFB_IMAGEBLIT
> -       depends on FB
> +       select FB
>        tristate "i915 driver"
>        help
>          Choose this option if you have a system that has Intel 830M, 845G,
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index f026770..bf0af66 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -1054,9 +1054,10 @@ config FB_RIVA_BACKLIGHT
>
>  config FB_I810
>        tristate "Intel 810/815 support (EXPERIMENTAL)"
> -       depends on FB && EXPERIMENTAL && PCI && X86_32
> +       depends on EXPERIMENTAL && PCI && X86_32
>        select AGP
>        select AGP_INTEL
> +       select FB
>        select FB_MODE_HELPERS
>        select FB_CFB_FILLRECT
>        select FB_CFB_COPYAREA
> @@ -1119,7 +1120,8 @@ config FB_CARILLO_RANCH
>
>  config FB_INTEL
>        tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM support (EXPERIMENTAL)"
> -       depends on FB && EXPERIMENTAL && PCI && X86
> +       depends on EXPERIMENTAL && PCI && X86
> +       select FB
>        select AGP
>        select AGP_INTEL
>        select FB_MODE_HELPERS
> --
> 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/
>

Re: [Bug #12605] Suspend regression, hang after matroxfb

[Eric Sesterhenn]

* Rafael J. Wysocki (rjw@sisk.pl) wrote:
> On Thursday 05 February 2009, Eric Sesterhenn 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=12605
> > > Subject		: Suspend regression, hang after matroxfb
> > > Submitter	: Eric Sesterhenn <snakebyte@gmx.de>
> > > Date		: 2009-01-29 12:58 (7 days old)
> > > References	: http://thread.gmane.org/gmane.linux.power-management.general/12640
> > > Handled-By	: Rafael J. Wysocki <rjw@sisk.pl>
> > > Patch		: http://marc.info/?l=linux-kernel&m=123335902122029&w=4
> > 
> > with todays -git I still get the same error, I have seen that some of 
> > your PM patches got applied, seems the one I need wasnt one of them.
> 
> No, it's not been merged yet.

This is fixed with todays -git. Thanks
A CC on the newer patches would have been nice, since I read the list
only via web archives, but i saw them floating by.

Greetings, Eric

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Eric Anholt]

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

On Thu, 2009-02-05 at 20:36 +0100, Ingo Molnar wrote:
> * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > > kconfig was not broken at all in this case. It detected a circular 
> > > dependency and did its work well.
> > 
> > Maybe.  I haven't seen an explanation for the problems that Eric reported 
> > 2+ weeks ago.
> 
> The thing he reported 2 weeks ago is a straightforward recursive dependency 
> bug in the config entries:
> 
>   drivers/gpu/drm/Kconfig:8:error: found recursive dependency:
>    DRM -> <choice> -> DRM_I915 -> FB -> FB_I810 -> AGP -> DRM
> 
> this is the precise circular dependency problem that the I810_FB and 
> INTEL_FB changes in my patch solve.

I think the problem is that when looking at
	select FB
or
	depends on FB
I see "this thing depends on FB.  If I said select, then instead of
asking the user to enable it before seeing the option, just enable the
option for them".  Even after seeing your patch, I still don't see why
the select means that AGP depends on DRM.

But big thanks for fixing it!

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

Re: [Bug #12491] i915 lockdep warning

[Eric Anholt]

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

On Fri, 2009-02-06 at 17:48 -0800, Roland Dreier wrote:
> [intel-gfx CC added]
> 
>  > I tested this on my 965 based system that showed the issue and it seemed resolved, at least no warnings in dmesg.  Lockdep was confirmed to still be enabled.
> 
>  > I can mark the bug fixed in korg bugzilla too.
> 
> Probably we just want to add a comment saying the patch works -- the bug
> should stay open until we get the fix upstream I guess.
> 
>  > Thank you Roland for looking into this, good work!
> 
> Thanks for testing!  Patch with updated changelog (including your
> tested-by) below.  Jesse [Barnes] and/or Eric please review and apply:
> 
> ---
> 
> i915: Fix potential AB-BA deadlock in i915_gem_execbuffer()
> 
> Lockdep warns that i915_gem_execbuffer() can trigger a page fault (which
> takes mmap_sem) while holding dev->struct_mutex, while drm_vm_open()
> (which is called with mmap_sem already held) takes dev->struct_mutex.
> So this is a potential AB-BA deadlock.
> 
> The way that i915_gem_execbuffer() triggers a page fault is by doing
> copy_to_user() when returning new buffer offsets back to userspace;
> however there is no reason to hold the struct_mutex when doing this
> copy, since what is being copied is the contents of an array private to
> i915_gem_execbuffer() anyway.  So we can fix the potential deadlock (and
> get rid of the lockdep warning) by simply moving the copy_to_user()
> outside of where struct_mutex is held.
> 
> This fixes <http://bugzilla.kernel.org/show_bug.cgi?id=12491>.
> 
> Reported-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Tested-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>

This only fixes 1 of the about 4 of this type of deadlock, but it looks
like a fine fix for that and I've put it in my tree.  Thanks!

(I'd been holding off on hitting the easy ones to figure out if we could
get the lock order the other way around.  It would be really nice if we
could have struct_mutex -> mmap_sem, but it looks like that's just not
going to happen.  pread and pwrite are going to be a mess.)

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

Re: [Bug #12491] i915 lockdep warning

[Roland Dreier]

 > This only fixes 1 of the about 4 of this type of deadlock, but it looks
 > like a fine fix for that and I've put it in my tree.  Thanks!

Heh, just fixing what I saw reported.  probably once this gets in the
harder reports will pop up because lockdep won't disable itself quite so
soon...

 - R.

Re: [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[Jeff Chua]

On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 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 (31 days old)
> References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4

I applied the patch
http://marc.info/?l=linux-wireless&m=123320213115108&w=2 and it seems
better now. One instant of not association out of 20 tries, but
reloading the modules seems to make it work again. So, let's just
close the case?


Here's part of the dmesg. Kernel is 2.6.29-rc5 with patch above applied.

wmaster0 (iwlagn): not using net_device_ops yet
phy0: Selected rate control algorithm 'iwl-agn-rs'
wlan0 (iwlagn): not using net_device_ops yet
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: irq 29 for MSI/MSI-X
iwlagn 0000:03:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn loaded firmware version 228.57.2.23
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
iwlagn: TX Power requested while scanning!
iwlagn: Error sending TX power (-11)
wlan0: authenticate with AP xxxxxxxxxxxxx
wlan0: authenticated
wlan0: associate with AP xxxxxxxxxxxxxx
wlan0: RX AssocResp from xxxxxxxxxxxxxx (capab=0x471 status=0 aid=24)
wlan0: associated


Thanks,
Jeff.

Re: [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[Jeff Chua]

On Sat, Feb 14, 2009 at 7:41 PM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> 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 (31 days old)
>> References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
>
> I applied the patch
> http://marc.info/?l=linux-wireless&m=123320213115108&w=2 and it seems
> better now. One instant of not association out of 20 tries, but
> reloading the modules seems to make it work again. So, let's just
> close the case?

I tested on another AP (WAG200G ), and this one, it's failing to
associate more often. And I noticed that when it does associate, I
don't get these two lines ...

iwlagn: TX Power requested while scanning!
iwlagn: Error sending TX power (-11)



Here's a good run ...

iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
iwlagn: Copyright(c) 2003-2008 Intel Corporation
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: setting latency timer to 64
iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
iwlagn: Tunable channels: 11 802.11bg, 13 802.11a channels
wmaster0 (iwlagn): not using net_device_ops yet
phy0: Selected rate control algorithm 'iwl-agn-rs'
wlan0 (iwlagn): not using net_device_ops yet
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: irq 28 for MSI/MSI-X
iwlagn 0000:03:00.0: firmware: requesting iwlwifi-4965-2.ucode
iwlagn loaded firmware version 228.57.2.23
Registered led device: iwl-phy0:radio
Registered led device: iwl-phy0:assoc
Registered led device: iwl-phy0:RX
Registered led device: iwl-phy0:TX
wlan0: authenticate with AP xxxxxxxxxxxxx
wlan0: authenticate with AP xxxxxxxxxxxxx
wlan0: authenticate with AP xxxxxxxxxxxxx
wlan0: authenticated
wlan0: associate with AP xxxxxxxxxxxx
wlan0: RX AssocResp from xxxxxxxxxxxx (capab=0x471 status=0 aid=1)
wlan0: associated



Thanks,
Jeff.

Re: [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?

[Rafael J. Wysocki]

On Saturday 14 February 2009, Jeff Chua wrote:
> On Sat, Feb 14, 2009 at 7:41 PM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > On Wed, Feb 4, 2009 at 6:23 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> 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 (31 days old)
> >> References      : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
> >
> > I applied the patch
> > http://marc.info/?l=linux-wireless&m=123320213115108&w=2 and it seems
> > better now. One instant of not association out of 20 tries, but
> > reloading the modules seems to make it work again. So, let's just
> > close the case?
> 
> I tested on another AP (WAG200G ), and this one, it's failing to
> associate more often. And I noticed that when it does associate, I
> don't get these two lines ...
> 
> iwlagn: TX Power requested while scanning!
> iwlagn: Error sending TX power (-11)
> 
> 
> 
> Here's a good run ...
> 
> iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27ks
> iwlagn: Copyright(c) 2003-2008 Intel Corporation
> iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> iwlagn 0000:03:00.0: setting latency timer to 64
> iwlagn: Detected Intel Wireless WiFi Link 4965AGN REV=0x4
> iwlagn: Tunable channels: 11 802.11bg, 13 802.11a channels
> wmaster0 (iwlagn): not using net_device_ops yet
> phy0: Selected rate control algorithm 'iwl-agn-rs'
> wlan0 (iwlagn): not using net_device_ops yet
> iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> iwlagn 0000:03:00.0: irq 28 for MSI/MSI-X
> iwlagn 0000:03:00.0: firmware: requesting iwlwifi-4965-2.ucode
> iwlagn loaded firmware version 228.57.2.23
> Registered led device: iwl-phy0:radio
> Registered led device: iwl-phy0:assoc
> Registered led device: iwl-phy0:RX
> Registered led device: iwl-phy0:TX
> wlan0: authenticate with AP xxxxxxxxxxxxx
> wlan0: authenticate with AP xxxxxxxxxxxxx
> wlan0: authenticate with AP xxxxxxxxxxxxx
> wlan0: authenticated
> wlan0: associate with AP xxxxxxxxxxxx
> wlan0: RX AssocResp from xxxxxxxxxxxx (capab=0x471 status=0 aid=1)
> wlan0: associated

Thanks for the updates.

Rafael

Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[Larry Finger]

Rafael J. Wysocki wrote:
> On Saturday 07 February 2009, Larry Finger wrote:
>> Rafael J. Wysocki wrote:
>>> On Thursday 05 February 2009, Hugh Dickins wrote:
>>>> On Wed, 4 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 (13 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>
>>>>> Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2
>>>> Yes, this does still need to be listed.  My initial patch for it was
>>>> not enough, but I think the three patches necessary have all now been
>>>> posted (though Sergei may rewrite mine).  I'm expecting Alan to gather
>>>> them together and send them in due course, but I believe he's occupied
>>>> with other stuff just at the moment.
>> I still have the problem as of 2.6.29-rc3-00634-g9be260a
> 

The problem was fixed as of 2.6.29-rc5-00168-gba95fd4 with commit d1b3525. At
least for my system, the regression is cleared.

Larry

Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression

[Rafael J. Wysocki]

On Monday 23 February 2009, Larry Finger wrote:
> Rafael J. Wysocki wrote:
> > On Saturday 07 February 2009, Larry Finger wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Thursday 05 February 2009, Hugh Dickins wrote:
> >>>> On Wed, 4 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 (13 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>
> >>>>> Patch		: http://marc.info/?l=linux-kernel&m=123254501314058&w=2
> >>>> Yes, this does still need to be listed.  My initial patch for it was
> >>>> not enough, but I think the three patches necessary have all now been
> >>>> posted (though Sergei may rewrite mine).  I'm expecting Alan to gather
> >>>> them together and send them in due course, but I believe he's occupied
> >>>> with other stuff just at the moment.
> >> I still have the problem as of 2.6.29-rc3-00634-g9be260a
> > 
> 
> The problem was fixed as of 2.6.29-rc5-00168-gba95fd4 with commit d1b3525. At
> least for my system, the regression is cleared.

It's already been closed, thanks for the confirmation.

Rafael

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Rafael J. Wysocki]

On Wednesday 04 February 2009, Damien Wyart wrote:
> Hello,
> 
> > 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.
> 
> I have not yet got any feedback on this regression I reported:
> http://marc.info/?l=linux-kernel&m=123307298514358&w=2
> which is easy to reproduce on my machines.

Added to the list of recent regressions.

Thanks,
Rafael

Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

[Damien Wyart]

Hello,

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

I have not yet got any feedback on this regression I reported:
http://marc.info/?l=linux-kernel&m=123307298514358&w=2
which is easy to reproduce on my machines.

-- 
Damien Wyart