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

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

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

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