2.6.33-rc6: Reported regressions from 2.6.32

2.6.33-rc6: Reported regressions from 2.6.32

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.32, 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.32, 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
  ----------------------------------------
  2010-02-01       85       26          21
  2010-01-24       75       29          23
  2010-01-10       55       33          21
  2009-12-29       36       34          27


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15202
Subject		: lockdep warning during elevator_switch
Submitter	: Hugh Dickins <hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org>
Date		: 2010-01-31 23:55 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126498212613051&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15200
Subject		: NFS problems in 2.6.33-rc6: Unknown error 526
Submitter	: J.A. Magallón <jamagallon-sh/6fXdz2Rs@public.gmane.org>
Date		: 2010-01-31 22:46 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126497800408928&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15199
Subject		: sata_nv and no /dev files
Submitter	: Bartłomiej Zimoń <uzi18-h7QdYz1kt/Q@public.gmane.org>
Date		: 2010-01-31 23:45 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126498153112488&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15196
Subject		: kmem_cache_create: duplicate cache ccid2_h
Submitter	: Heinz Diehl <htd-HjJ2MNWy62to6+H+lsi3Gti2O/JbrIOy@public.gmane.org>
Date		: 2010-01-30 18:33 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=126487640324942&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15192
Subject		: netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f
Submitter	: Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-25 10:03 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1b9508f6831e10d53256825de8904caa22d1ca2c
References	: http://marc.info/?l=linux-kernel&m=126441481427331&w=4
Handled-By	: Mike Galbraith <efault-Mmb7MZpHnFY@public.gmane.org>
		  Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
Subject		: HDA Intel Audio hang on boot
Submitter	: Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org>
Date		: 2010-01-15 1:24 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15142
Subject		: "INFO: possible circular locking dependency detected"
Submitter	: Matti Aarnio <matti.aarnio--kernel-bugzilla-VYF+RMHuKCpAfugRpC6u6w@public.gmane.org>
Date		: 2010-01-25 13:38 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15139
Subject		: e1000: transmit queue 0 timed out
Submitter	: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-23 15:37 (9 days old)
References	: http://marc.info/?l=linux-netdev&m=126426149306083&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15138
Subject		: evdev regression on macbook
Submitter	: Guillaume Chazarain <guichaz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-23 18:53 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=126427286219235&w=4
Handled-By	: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15125
Subject		: hung task - jbd2/dm-1-8 (during raid rebuild)
Submitter	: Michael Breuer <mbreuer-P//MSfjsEjDQT0dZR+AlfA@public.gmane.org>
Date		: 2010-01-10 21:47 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=126316012025978&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
Subject		: PCI host bridge windows ignored (works with pci=use_crs)
Submitter	: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>
Date		: 2010-01-13 5:37 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
		  Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15119
Subject		: iwl_bg_scan_completed: WARN on scan complete
Submitter	: Alex Zhavnerchik <alex.vizor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-24 12:27 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15114
Subject		: X.org hang with [drm:i915_gem_do_execbuffer] *ERROR* in dmesg
Submitter	: Matej Laitl <strohel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-23 19:54 (9 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15076
Subject		: System panic under load with clockevents_program_event
Submitter	: okias <d.okias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-17 13:03 (15 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15043
Subject		: Display goes off with i915.powersave=1 after suspend-resume
Submitter	: Soeren Sonnenburg <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Date		: 2010-01-10 20:09 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=126315457519505&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15036
Subject		: soft lockup in dmesg after suspend/resume
Submitter	: ykzhao <yakui.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-04 5:36 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=126258356202722&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15025
Subject		: Oops in ext4 driver
Submitter	: Steinar H. Gunderson <sgunderson-jG/AHqQBv7lBDgjK7y7TUQ@public.gmane.org>
Date		: 2010-01-10 13:09 (22 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14999
Subject		: possible circular locking dependency detected in rfkill at suspend
Submitter	: Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date		: 2010-01-06 21:52 (26 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14950
Subject		: tbench regression with 2.6.33-rc1
Submitter	: Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2009-12-25 11:11 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=126174044213172&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14937
Subject		: WARNING: at kernel/lockdep.c:2830
Submitter	: Grant Wilson <grant.wilson-1HOZaDBbGgxaa/9Udqfwiw@public.gmane.org>
Date		: 2009-12-27 13:35 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=126192220404829&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14792
Subject		: Misdetection of the TV output
Submitter	: Santi <santi-wpr36wD7VxHR7s880joybQ@public.gmane.org>
Date		: 2009-12-12 13:28 (51 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=27dfaf4f5825a119305db1bc63bef30ed400e376
Handled-By	: Zhao Yakui <yakui.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15198
Subject		: Radeon KMS regression
Submitter	: Kevin Winchester <kjwinchester-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-30 17:18 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=42590a75019a50012f25a962246498dead428433
References	: http://marc.info/?l=linux-kernel&m=126487191019612&w=4
Handled-By	: FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/75023/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15195
Subject		: kernel BUG at include/net/netns/generic.h:41, pfkey_create+0x36/0x18b [af_key]
Submitter	: Luca Tettamanti <kronos.it-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-30 13:23 (2 days old)
References	: http://marc.info/?l=linux-netdev&m=126485785004775&w=4
Handled-By	: Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/75891/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15039
Subject		: leds_alix2: can't allocate I/O for GPIO
Submitter	: Arnd Hannemann <hannemann-JasiFyN5vQG662+jY7v6MhvVK+yQ3ZXh@public.gmane.org>
Date		: 2010-01-07 10:26 (25 days old)
References	: http://marc.info/?l=linux-kernel&m=126286001106257&w=4
Handled-By	: Daniel Mack <daniel-rDUAYElUppE@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/72006/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14949
Subject		: drm_vm.c:drm_mmap: possible circular locking dependency detected
Submitter	: Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date		: 2009-12-26 9:45 (37 days old)
References	: http://marc.info/?l=linux-kernel&m=126182073616279&w=4
Handled-By	: Eric W. Biederman <ebiederm-BGArkANP9klv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/70461/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14791
Subject		: Something has been broken in the network stack this week
Submitter	: Delete This Account <speedyboyinovator-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-12-12 13:06 (51 days old)
Handled-By	: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/72073/


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.32,
unresolved as well as resolved, at:

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

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug #14791] Something has been broken in the network stack this week

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14791
Subject		: Something has been broken in the network stack this week
Submitter	: Delete This Account <speedyboyinovator-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
Date		: 2009-12-12 13:06 (51 days old)
Handled-By	: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Patch		: http://patchwork.kernel.org/patch/72073/

Re: [Bug #14791] Something has been broken in the network stack this week

[Ben Hutchings]

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

On Mon, 2010-02-01 at 01:19 +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.32.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14791
> Subject		: Something has been broken in the network stack this week
> Submitter	: Delete This Account <speedyboyinovator-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
> Date		: 2009-12-12 13:06 (51 days old)
> Handled-By	: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
> Patch		: http://patchwork.kernel.org/patch/72073/

Dave has accepted the patch but hasn't pushed it out yet.  I expect that
it will be in 2.6.33-rc7.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

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

[Bug #14950] tbench regression with 2.6.33-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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14950
Subject		: tbench regression with 2.6.33-rc1
Submitter	: Lin Ming <ming.m.lin@intel.com>
Date		: 2009-12-25 11:11 (38 days old)
References	: http://marc.info/?l=linux-kernel&m=126174044213172&w=4

Re: [Bug #14950] tbench regression with 2.6.33-rc1

[Mike Galbraith]

On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> (either way).

Yes, it should remain open.  Looking for places to trim overhead without
injuring other things.  The regression is a moving target on my HW.

	-Mike

Re: [Bug #14950] tbench regression with 2.6.33-rc1

[Rafael J. Wysocki]

On Monday 01 February 2010, Mike Galbraith wrote:
> On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Yes, it should remain open.  Looking for places to trim overhead without
> injuring other things.  The regression is a moving target on my HW.

Thanks for the update.

Rafael

[Bug #15036] soft lockup in dmesg after suspend/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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15036
Subject		: soft lockup in dmesg after suspend/resume
Submitter	: ykzhao <yakui.zhao-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-04 5:36 (28 days old)
References	: http://marc.info/?l=linux-kernel&m=126258356202722&w=4

[Bug #15039] leds_alix2: can't allocate I/O for GPIO

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15039
Subject		: leds_alix2: can't allocate I/O for GPIO
Submitter	: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Date		: 2010-01-07 10:26 (25 days old)
References	: http://marc.info/?l=linux-kernel&m=126286001106257&w=4
Handled-By	: Daniel Mack <daniel@caiaq.de>
Patch		: http://patchwork.kernel.org/patch/72006/

[Bug #14792] Misdetection of the TV output

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14792
Subject		: Misdetection of the TV output
Submitter	: Santi <santi@agolina.net>
Date		: 2009-12-12 13:28 (51 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=27dfaf4f5825a119305db1bc63bef30ed400e376
Handled-By	: Zhao Yakui <yakui.zhao@intel.com>

[Bug #14937] WARNING: at kernel/lockdep.c:2830

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14937
Subject		: WARNING: at kernel/lockdep.c:2830
Submitter	: Grant Wilson <grant.wilson-1HOZaDBbGgxaa/9Udqfwiw@public.gmane.org>
Date		: 2009-12-27 13:35 (36 days old)
References	: http://marc.info/?l=linux-kernel&m=126192220404829&w=4

[Bug #14999] possible circular locking dependency detected in rfkill at suspend

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14999
Subject		: possible circular locking dependency detected in rfkill at suspend
Submitter	: Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date		: 2010-01-06 21:52 (26 days old)

[Bug #14949] drm_vm.c:drm_mmap: 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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14949
Subject		: drm_vm.c:drm_mmap: possible circular locking dependency detected
Submitter	: Borislav Petkov <petkovbb@googlemail.com>
Date		: 2009-12-26 9:45 (37 days old)
References	: http://marc.info/?l=linux-kernel&m=126182073616279&w=4
Handled-By	: Eric W. Biederman <ebiederm@aristanetworks.com>
Patch		: http://patchwork.kernel.org/patch/70461/

Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected

[Borislav Petkov]

On Mon, Feb 1, 2010 at 1:22 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.32.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14949
> Subject         : drm_vm.c:drm_mmap: possible circular locking dependency detected
> Submitter       : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Date            : 2009-12-26 9:45 (37 days old)
> References      : http://marc.info/?l=linux-kernel&m=126182073616279&w=4
> Handled-By      : Eric W. Biederman <ebiederm-BGArkANP9klv6pq1l3V1OWGXanvQGlWp@public.gmane.orgm>
> Patch           : http://patchwork.kernel.org/patch/70461/

Yes, this is fixed.

-- 
Regards/Gruss,
Boris

Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected

[Rafael J. Wysocki]

On Monday 01 February 2010, Borislav Petkov wrote:
> On Mon, Feb 1, 2010 at 1:22 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.32.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14949
> > Subject         : drm_vm.c:drm_mmap: possible circular locking dependency detected
> > Submitter       : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > Date            : 2009-12-26 9:45 (37 days old)
> > References      : http://marc.info/?l=linux-kernel&m=126182073616279&w=4
> > Handled-By      : Eric W. Biederman <ebiederm-BGArkANP9klv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> > Patch           : http://patchwork.kernel.org/patch/70461/
> 
> Yes, this is fixed.

Do you mean "fixed" as "the fix is in the Linus' tree" or "fixed" as "the
patch fixed it for me"?

Rafael

Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected

[Borislav Petkov]

(Adding Greg to Cc:)

On Tue, Feb 02, 2010 at 09:46:45PM +0100, Rafael J. Wysocki wrote:
> On Monday 01 February 2010, Borislav Petkov wrote:
> > On Mon, Feb 1, 2010 at 1:22 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.32.  Please verify if it still should be listed and let me know
> > > (either way).
> > >
> > >
> > > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14949
> > > Subject         : drm_vm.c:drm_mmap: possible circular locking dependency detected
> > > Submitter       : Borislav Petkov <petkovbb@googlemail.com>
> > > Date            : 2009-12-26 9:45 (37 days old)
> > > References      : http://marc.info/?l=linux-kernel&m=126182073616279&w=4
> > > Handled-By      : Eric W. Biederman <ebiederm@aristanetworks.com>
> > > Patch           : http://patchwork.kernel.org/patch/70461/
> > 
> > Yes, this is fixed.
> 
> Do you mean "fixed" as "the fix is in the Linus' tree" or "fixed" as "the
> patch fixed it for me"?

Rather the second one, i.e. it fixes it for me. The patch is named

sysfs-cache-the-last-sysfs_dirent-to-improve-readdir-scalability-v2.patch

and is "stuck" in Greg's tree. Judging by the quilt series¹, the patch
is slated for submission after 2.6.33. This late in the game for .32,
I'm guessing maybe a stable backport after .33 is out?

[1] http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/series

-- 
Regards/Gruss,
    Boris.

Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected

[Rafael J. Wysocki]

On Tuesday 02 February 2010, Borislav Petkov wrote:
> (Adding Greg to Cc:)
> 
> On Tue, Feb 02, 2010 at 09:46:45PM +0100, Rafael J. Wysocki wrote:
> > On Monday 01 February 2010, Borislav Petkov wrote:
> > > On Mon, Feb 1, 2010 at 1:22 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.32.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > >
> > > >
> > > > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14949
> > > > Subject         : drm_vm.c:drm_mmap: possible circular locking dependency detected
> > > > Submitter       : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > > > Date            : 2009-12-26 9:45 (37 days old)
> > > > References      : http://marc.info/?l=linux-kernel&m=126182073616279&w=4
> > > > Handled-By      : Eric W. Biederman <ebiederm-BGArkANP9klv6pq1l3V1OWGXanvQGlWp@public.gmane.orgm>
> > > > Patch           : http://patchwork.kernel.org/patch/70461/
> > > 
> > > Yes, this is fixed.
> > 
> > Do you mean "fixed" as "the fix is in the Linus' tree" or "fixed" as "the
> > patch fixed it for me"?
> 
> Rather the second one, i.e. it fixes it for me. The patch is named
> 
> sysfs-cache-the-last-sysfs_dirent-to-improve-readdir-scalability-v2.patch
> 
> and is "stuck" in Greg's tree. Judging by the quilt series¹, the patch
> is slated for submission after 2.6.33. This late in the game for .32,
> I'm guessing maybe a stable backport after .33 is out?

I guess so.  Thanks!

Rafael

Re: [Bug #14949] drm_vm.c:drm_mmap: possible circular locking dependency detected

[Greg KH]

On Tue, Feb 02, 2010 at 09:58:57PM +0100, Borislav Petkov wrote:
> (Adding Greg to Cc:)
> 
> On Tue, Feb 02, 2010 at 09:46:45PM +0100, Rafael J. Wysocki wrote:
> > On Monday 01 February 2010, Borislav Petkov wrote:
> > > On Mon, Feb 1, 2010 at 1:22 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.32.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > >
> > > >
> > > > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14949
> > > > Subject         : drm_vm.c:drm_mmap: possible circular locking dependency detected
> > > > Submitter       : Borislav Petkov <petkovbb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > > > Date            : 2009-12-26 9:45 (37 days old)
> > > > References      : http://marc.info/?l=linux-kernel&m=126182073616279&w=4
> > > > Handled-By      : Eric W. Biederman <ebiederm-BGArkANP9klv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> > > > Patch           : http://patchwork.kernel.org/patch/70461/
> > > 
> > > Yes, this is fixed.
> > 
> > Do you mean "fixed" as "the fix is in the Linus' tree" or "fixed" as "the
> > patch fixed it for me"?
> 
> Rather the second one, i.e. it fixes it for me. The patch is named
> 
> sysfs-cache-the-last-sysfs_dirent-to-improve-readdir-scalability-v2.patch
> 
> and is "stuck" in Greg's tree. Judging by the quilt series??, the patch
> is slated for submission after 2.6.33. This late in the game for .32,
> I'm guessing maybe a stable backport after .33 is out?
> 
> [1] http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/series

I'll mark it for stable, I'd prefer to wait for .33 to come out before
sending it in.

thanks,

greg k-h

[Bug #15025] Oops in ext4 driver

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15025
Subject		: Oops in ext4 driver
Submitter	: Steinar H. Gunderson <sgunderson@bigfoot.com>
Date		: 2010-01-10 13:09 (22 days old)

[Bug #15043] Display goes off with i915.powersave=1 after suspend-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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15043
Subject		: Display goes off with i915.powersave=1 after suspend-resume
Submitter	: Soeren Sonnenburg <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Date		: 2010-01-10 20:09 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=126315457519505&w=4

Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume

[Soeren Sonnenburg]

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

On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15043
> Subject		: Display goes off with i915.powersave=1 after suspend-resume
> Submitter	: Soeren Sonnenburg <sonne@debian.org>
> Date		: 2010-01-10 20:09 (22 days old)
> References	: http://marc.info/?l=linux-kernel&m=126315457519505&w=4

yes still exists in current git.

Soeren
-- 
For the one fact about the future of which we can be certain is that it
will be utterly fantastic. -- Arthur C. Clarke, 1962

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

Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume

[Rafael J. Wysocki]

On Thursday 04 February 2010, Soeren Sonnenburg wrote:
> On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15043
> > Subject		: Display goes off with i915.powersave=1 after suspend-resume
> > Submitter	: Soeren Sonnenburg <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
> > Date		: 2010-01-10 20:09 (22 days old)
> > References	: http://marc.info/?l=linux-kernel&m=126315457519505&w=4
> 
> yes still exists in current git.

Thanks for the update.

Rafael

Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume

[Jesse Barnes]

On Thu, 4 Feb 2010 21:42:02 +0100
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:

> On Thursday 04 February 2010, Soeren Sonnenburg wrote:
> > On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be
> > > listed and let me know (either way).
> > > 
> > > 
> > > Bug-Entry	:
> > > http://bugzilla.kernel.org/show_bug.cgi?id=15043
> > > Subject		: Display goes off with i915.powersave=1
> > > after suspend-resume Submitter	: Soeren Sonnenburg
> > > <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> Date		: 2010-01-10 20:09 (22
> > > days old) References	:
> > > http://marc.info/?l=linux-kernel&m=126315457519505&w=4
> > 
> > yes still exists in current git.
> 
> Thanks for the update.

Just updated the corresponding FDO bug
(https://bugs.freedesktop.org/show_bug.cgi?id=24314).  There are some
hw bugs related to FBC handling on 945GM though, so we may have to
disable it on some machines.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume

[Soeren Sonnenburg]

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

On Fri, 2010-02-05 at 11:29 -0800, Jesse Barnes wrote:
> On Thu, 4 Feb 2010 21:42:02 +0100
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> 
> > On Thursday 04 February 2010, Soeren Sonnenburg wrote:
> > > On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be
> > > > listed and let me know (either way).
> > > > 
> > > > 
> > > > Bug-Entry	:
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=15043
> > > > Subject		: Display goes off with i915.powersave=1
> > > > after suspend-resume Submitter	: Soeren Sonnenburg
> > > > <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> Date		: 2010-01-10 20:09 (22
> > > > days old) References	:
> > > > http://marc.info/?l=linux-kernel&m=126315457519505&w=4
> > > 
> > > yes still exists in current git.
> > 
> > Thanks for the update.
> 
> Just updated the corresponding FDO bug
> (https://bugs.freedesktop.org/show_bug.cgi?id=24314).  There are some
> hw bugs related to FBC handling on 945GM though, so we may have to
> disable it on some machines.

FYI: With the patch from #14897 it was working for the last day and a
half at least...

Soeren
-- 
For the one fact about the future of which we can be certain is that it
will be utterly fantastic. -- Arthur C. Clarke, 1962

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

Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume

[Soeren Sonnenburg]

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

On Sat, 2010-02-06 at 06:11 +0100, Soeren Sonnenburg wrote:
> On Fri, 2010-02-05 at 11:29 -0800, Jesse Barnes wrote:
> > On Thu, 4 Feb 2010 21:42:02 +0100
> > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > 
> > > On Thursday 04 February 2010, Soeren Sonnenburg wrote:
> > > > On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be
> > > > > listed and let me know (either way).
> > > > > 
> > > > > 
> > > > > Bug-Entry	:
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=15043
> > > > > Subject		: Display goes off with i915.powersave=1
> > > > > after suspend-resume Submitter	: Soeren Sonnenburg
> > > > > <sonne-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> Date		: 2010-01-10 20:09 (22
> > > > > days old) References	:
> > > > > http://marc.info/?l=linux-kernel&m=126315457519505&w=4
> > > > 
> > > > yes still exists in current git.
> > > 
> > > Thanks for the update.
> > 
> > Just updated the corresponding FDO bug
> > (https://bugs.freedesktop.org/show_bug.cgi?id=24314).  There are some
> > hw bugs related to FBC handling on 945GM though, so we may have to
> > disable it on some machines.
> 
> FYI: With the patch from #14897 it was working for the last day and a
> half at least...

Just after I wrote that email it was happening again. So I take that
back. Flickering and display -> off just happened with that patch.

Soeren
-- 
For the one fact about the future of which we can be certain is that it
will be utterly fantastic. -- Arthur C. Clarke, 1962

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

[Bug #15076] System panic under load with clockevents_program_event

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15076
Subject		: System panic under load with clockevents_program_event
Submitter	: okias <d.okias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-17 13:03 (15 days old)

Re: [Bug #15076] System panic under load with clockevents_program_event

[okias]

Still valid. But reproduction without HIGHMEM is minimal, but still annoying.

2010/2/1, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> 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.32.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15076
> Subject		: System panic under load with clockevents_program_event
> Submitter	: okias <d.okias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date		: 2010-01-17 13:03 (15 days old)
>
>
>


-- 
Jabber/XMPP: okias-O1n184kmSCviB9QmIjCX8w@public.gmane.org
SIP VoIP: sip:17474537254-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org

Re: [Bug #15076] System panic under load with clockevents_program_event

[Rafael J. Wysocki]

On Monday 01 February 2010, okias wrote:
> Still valid. But reproduction without HIGHMEM is minimal, but still annoying.

Thanks for the update.

Rafael

[Bug #15114] X.org hang with [drm:i915_gem_do_execbuffer] *ERROR* in dmesg

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15114
Subject		: X.org hang with [drm:i915_gem_do_execbuffer] *ERROR* in dmesg
Submitter	: Matej Laitl <strohel@gmail.com>
Date		: 2010-01-23 19:54 (9 days old)

[Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
Subject		: PCI host bridge windows ignored (works with pci=use_crs)
Submitter	: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>
Date		: 2010-01-13 5:37 (19 days old)
References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
		  Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/31/2010 04:22 PM, 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.32.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> Submitter	: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>
> Date		: 2010-01-13 5:37 (19 days old)
> References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> 		  Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
> 

should be closed.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Monday 01 February 2010, Yinghai Lu wrote:
> On 01/31/2010 04:22 PM, 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.32.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > Submitter	: Jeff Garrett <jeff@jgarrett.org>
> > Date		: 2010-01-13 5:37 (19 days old)
> > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > Handled-By	: Yinghai Lu <yinghai@kernel.org>
> > 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> > 
> 
> should be closed.

Is there a fix in the Linus' tree?

Rafael

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jeff Garrett]

On Tue, Feb 02, 2010 at 09:42:58PM +0100, Rafael J. Wysocki wrote:
> On Monday 01 February 2010, Yinghai Lu wrote:
> > On 01/31/2010 04:22 PM, 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.32.  Please verify if it still should be listed and let me know
> > > (either way).
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > > Submitter	: Jeff Garrett <jeff@jgarrett.org>
> > > Date		: 2010-01-13 5:37 (19 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > > Handled-By	: Yinghai Lu <yinghai@kernel.org>
> > > 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> > > 
> > 
> > should be closed.
> 
> Is there a fix in the Linus' tree?
> 
> Rafael

Yes, it is fixed by commit e8e06eae4ffd683931b928f460c11c40cd3f7fd8

-Jeff

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Tuesday 02 February 2010, Jeff Garrett wrote:
> On Tue, Feb 02, 2010 at 09:42:58PM +0100, Rafael J. Wysocki wrote:
> > On Monday 01 February 2010, Yinghai Lu wrote:
> > > On 01/31/2010 04:22 PM, 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.32.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > > 
> > > > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > > > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > > > Submitter	: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>
> > > > Date		: 2010-01-13 5:37 (19 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > > > Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > 		  Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
> > > > 
> > > 
> > > should be closed.
> > 
> > Is there a fix in the Linus' tree?
> > 
> > Rafael
> 
> Yes, it is fixed by commit e8e06eae4ffd683931b928f460c11c40cd3f7fd8

Thanks, closing.

Rafael

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Tuesday 02 February 2010 01:42:58 pm Rafael J. Wysocki wrote:
> On Monday 01 February 2010, Yinghai Lu wrote:
> > On 01/31/2010 04:22 PM, 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.32.  Please verify if it still should be listed and let me know
> > > (either way).
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > > Submitter	: Jeff Garrett <jeff@jgarrett.org>
> > > Date		: 2010-01-13 5:37 (19 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > > Handled-By	: Yinghai Lu <yinghai@kernel.org>
> > > 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> > > 
> > 
> > should be closed.
> 
> Is there a fix in the Linus' tree?

Yes.  The regression was caused by the addition of arch/x86/pci/intel_bus.c.

Jeff's patch: http://lkml.org/lkml/2010/1/27/449 is in Linus' tree as
commit e8e06eae4ffd68, and Jeff confirmed that it works for him.

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Tuesday 02 February 2010, Bjorn Helgaas wrote:
> On Tuesday 02 February 2010 01:42:58 pm Rafael J. Wysocki wrote:
> > On Monday 01 February 2010, Yinghai Lu wrote:
> > > On 01/31/2010 04:22 PM, 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.32.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > > 
> > > > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > > > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > > > Submitter	: Jeff Garrett <jeff@jgarrett.org>
> > > > Date		: 2010-01-13 5:37 (19 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > > > Handled-By	: Yinghai Lu <yinghai@kernel.org>
> > > > 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> > > > 
> > > 
> > > should be closed.
> > 
> > Is there a fix in the Linus' tree?
> 
> Yes.  The regression was caused by the addition of arch/x86/pci/intel_bus.c.
> 
> Jeff's patch: http://lkml.org/lkml/2010/1/27/449 is in Linus' tree as
> commit e8e06eae4ffd68, and Jeff confirmed that it works for him.

Thanks, closed.

Rafael

[Bug #15119] iwl_bg_scan_completed: WARN on scan complete

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15119
Subject		: iwl_bg_scan_completed: WARN on scan complete
Submitter	: Alex Zhavnerchik <alex.vizor@gmail.com>
Date		: 2010-01-24 12:27 (8 days old)

[Bug #15139] e1000: transmit queue 0 timed out

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15139
Subject		: e1000: transmit queue 0 timed out
Submitter	: Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-23 15:37 (9 days old)
References	: http://marc.info/?l=linux-netdev&m=126426149306083&w=4

[Bug #15125] hung task - jbd2/dm-1-8 (during raid rebuild)

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15125
Subject		: hung task - jbd2/dm-1-8 (during raid rebuild)
Submitter	: Michael Breuer <mbreuer-P//MSfjsEjDQT0dZR+AlfA@public.gmane.org>
Date		: 2010-01-10 21:47 (22 days old)
References	: http://marc.info/?l=linux-kernel&m=126316012025978&w=4

Re: [Bug #15125] hung task - jbd2/dm-1-8 (during raid rebuild)

[Michael Breuer]

On 1/31/2010 7:22 PM, 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.32.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15125
> Subject		: hung task - jbd2/dm-1-8 (during raid rebuild)
> Submitter	: Michael Breuer<mbreuer-P//MSfjsEjDQT0dZR+AlfA@public.gmane.org>
> Date		: 2010-01-10 21:47 (22 days old)
> References	: http://marc.info/?l=linux-kernel&m=126316012025978&w=4
>
>    
Yup. Hit it again on 2.6.33-rc5.

Re: [Bug #15125] hung task - jbd2/dm-1-8 (during raid rebuild)

[Michael Breuer]

On 1/31/2010 7:42 PM, Michael Breuer wrote:
> On 1/31/2010 7:22 PM, 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.32.  Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=15125
>> Subject        : hung task - jbd2/dm-1-8 (during raid rebuild)
>> Submitter    : Michael Breuer<mbreuer@majjas.com>
>> Date        : 2010-01-10 21:47 (22 days old)
>> References    : http://marc.info/?l=linux-kernel&m=126316012025978&w=4
>>
> Yup. Hit it again on 2.6.33-rc5.
> -- 
> 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/
I was not able to recreate this in rc6.

Re: [Bug #15125] hung task - jbd2/dm-1-8 (during raid rebuild)

[Rafael J. Wysocki]

On Monday 01 February 2010, Michael Breuer wrote:
> On 1/31/2010 7:42 PM, Michael Breuer wrote:
> > On 1/31/2010 7:22 PM, 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.32.  Please verify if it still should be listed and let me know
> >> (either way).
> >>
> >>
> >> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=15125
> >> Subject        : hung task - jbd2/dm-1-8 (during raid rebuild)
> >> Submitter    : Michael Breuer<mbreuer-P//MSfjsEjDQT0dZR+AlfA@public.gmane.org>
> >> Date        : 2010-01-10 21:47 (22 days old)
> >> References    : http://marc.info/?l=linux-kernel&m=126316012025978&w=4
> >>
> > Yup. Hit it again on 2.6.33-rc5.
> I was not able to recreate this in rc6.

Thanks, closed then.

Rafael

[Bug #15138] evdev regression on macbook

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15138
Subject		: evdev regression on macbook
Submitter	: Guillaume Chazarain <guichaz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-23 18:53 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=126427286219235&w=4
Handled-By	: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[Bug #15142] "INFO: 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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15142
Subject		: "INFO: possible circular locking dependency detected"
Submitter	: Matti Aarnio <matti.aarnio--kernel-bugzilla-VYF+RMHuKCpAfugRpC6u6w@public.gmane.org>
Date		: 2010-01-25 13:38 (7 days old)

[Bug #15144] HDA Intel Audio hang on boot

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
Subject		: HDA Intel Audio hang on boot
Submitter	: Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org>
Date		: 2010-01-15 1:24 (17 days old)
References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4

Re: [Bug #15144] HDA Intel Audio hang on boot

[Sid Boyce]

On 01/02/10 00:22, 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.32.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
> Subject		: HDA Intel Audio hang on boot
> Submitter	: Sid Boyce <sboyce@blueyonder.co.uk>
> Date		: 2010-01-15 1:24 (17 days old)
> References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4
> 
> 
> 

Still not fixed in 2.6.33-rc6. Takashi wrote that the fix was scheduled
for 2.6.33-rc6, but it did not appear. I have gone back to using the
workaround with 2.6.33-rc6.
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: [Bug #15144] HDA Intel Audio hang on boot

[Takashi Iwai]

At Mon, 01 Feb 2010 02:01:21 +0000,
Sid Boyce wrote:
> 
> On 01/02/10 00:22, 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.32.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
> > Subject		: HDA Intel Audio hang on boot
> > Submitter	: Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org>
> > Date		: 2010-01-15 1:24 (17 days old)
> > References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4
> > 
> > 
> > 
> 
> Still not fixed in 2.6.33-rc6. Takashi wrote that the fix was scheduled
> for 2.6.33-rc6, but it did not appear.

It just slipped from rc6 due to my busy load.
The pull request was sent yesterday.


Takashi

Re: [Bug #15144] HDA Intel Audio hang on boot

[Rafael J. Wysocki]

On Monday 01 February 2010, Takashi Iwai wrote:
> At Mon, 01 Feb 2010 02:01:21 +0000,
> Sid Boyce wrote:
> > 
> > On 01/02/10 00:22, 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.32.  Please verify if it still should be listed and let me know
> > > (either way).
> > > 
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
> > > Subject		: HDA Intel Audio hang on boot
> > > Submitter	: Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org>
> > > Date		: 2010-01-15 1:24 (17 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4
> > > 
> > > 
> > > 
> > 
> > Still not fixed in 2.6.33-rc6. Takashi wrote that the fix was scheduled
> > for 2.6.33-rc6, but it did not appear.
> 
> It just slipped from rc6 due to my busy load.
> The pull request was sent yesterday.

Linus has already merged it, so I've closed the bug.

Rafael

Re: [Bug #15144] HDA Intel Audio hang on boot

[Sid Boyce]

On 02/02/10 20:40, Rafael J. Wysocki wrote:
> On Monday 01 February 2010, Takashi Iwai wrote:
>> At Mon, 01 Feb 2010 02:01:21 +0000,
>> Sid Boyce wrote:
>>>
>>> On 01/02/10 00:22, 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.32.  Please verify if it still should be listed and let me know
>>>> (either way).
>>>>
>>>>
>>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
>>>> Subject		: HDA Intel Audio hang on boot
>>>> Submitter	: Sid Boyce <sboyce-QgLWrMLu8clzjhtm8Ag3mw@public.gmane.org>
>>>> Date		: 2010-01-15 1:24 (17 days old)
>>>> References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4
>>>>
>>>>
>>>>
>>>
>>> Still not fixed in 2.6.33-rc6. Takashi wrote that the fix was scheduled
>>> for 2.6.33-rc6, but it did not appear.
>>
>> It just slipped from rc6 due to my busy load.
>> The pull request was sent yesterday.
> 
> Linus has already merged it, so I've closed the bug.
> 
> Rafael
> 

I added the line to hda_intel.c in 2.6.33-rc6 as I had oopses in
2.6.33-rc6-git1 that I haven't yet captured.
SND_PCI_QUIRK(0x1043, 0x829c, "ASUS", 0), /* nvidia */
The problem was still there. I shall have a further look later today.
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: [Bug #15144] HDA Intel Audio hang on boot

[Sid Boyce]

On 01/02/10 06:43, Takashi Iwai wrote:
> At Mon, 01 Feb 2010 02:01:21 +0000,
> Sid Boyce wrote:
>>
>> On 01/02/10 00:22, 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.32.  Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
>>> Subject		: HDA Intel Audio hang on boot
>>> Submitter	: Sid Boyce <sboyce@blueyonder.co.uk>
>>> Date		: 2010-01-15 1:24 (17 days old)
>>> References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4
>>>
>>>
>>>
>>
>> Still not fixed in 2.6.33-rc6. Takashi wrote that the fix was scheduled
>> for 2.6.33-rc6, but it did not appear.
> 
> It just slipped from rc6 due to my busy load.
> The pull request was sent yesterday.
> 
> 
> Takashi
> 

Up to 2.6.33-rc8 still needs the work around in
/etc/modprobe.d/50-sound.conf, so the kernel blacklist fix does not work.

# less /etc/modprobe.d/50-sound.conf

options slots=snd-hda-intel
# 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio
alias snd-card-0 snd-hda-intel
options snd-hda-intel enable_msi=0
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: [Bug #15144] HDA Intel Audio hang on boot

[Rafael J. Wysocki]

On Sunday 14 February 2010, Sid Boyce wrote:
> On 01/02/10 06:43, Takashi Iwai wrote:
> > At Mon, 01 Feb 2010 02:01:21 +0000,
> > Sid Boyce wrote:
> >>
> >> On 01/02/10 00:22, 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.32.  Please verify if it still should be listed and let me know
> >>> (either way).
> >>>
> >>>
> >>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15144
> >>> Subject		: HDA Intel Audio hang on boot
> >>> Submitter	: Sid Boyce <sboyce@blueyonder.co.uk>
> >>> Date		: 2010-01-15 1:24 (17 days old)
> >>> References	: http://marc.info/?l=linux-kernel&m=126351866722507&w=4
> >>>
> >>>
> >>>
> >>
> >> Still not fixed in 2.6.33-rc6. Takashi wrote that the fix was scheduled
> >> for 2.6.33-rc6, but it did not appear.
> > 
> > It just slipped from rc6 due to my busy load.
> > The pull request was sent yesterday.
> > 
> > 
> > Takashi
> > 
> 
> Up to 2.6.33-rc8 still needs the work around in
> /etc/modprobe.d/50-sound.conf, so the kernel blacklist fix does not work.
> 
> # less /etc/modprobe.d/50-sound.conf
> 
> options slots=snd-hda-intel
> # 9LTX.vLXC8EvZgR7:MCP55 High Definition Audio
> alias snd-card-0 snd-hda-intel
> options snd-hda-intel enable_msi=0

Thanks for the update.

I'll be sending a summary regression report later today with a follow-up
message regarding this bug.  You won't need to reply to that one.

Rafael

[Bug #15195] kernel BUG at include/net/netns/generic.h:41, pfkey_create+0x36/0x18b [af_key]

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15195
Subject		: kernel BUG at include/net/netns/generic.h:41, pfkey_create+0x36/0x18b [af_key]
Submitter	: Luca Tettamanti <kronos.it@gmail.com>
Date		: 2010-01-30 13:23 (2 days old)
References	: http://marc.info/?l=linux-netdev&m=126485785004775&w=4
Handled-By	: Alexey Dobriyan <adobriyan@gmail.com>
Patch		: http://patchwork.kernel.org/patch/75891/

[Bug #15192] netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15192
Subject		: netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f
Submitter	: Lin Ming <ming.m.lin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date		: 2010-01-25 10:03 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1b9508f6831e10d53256825de8904caa22d1ca2c
References	: http://marc.info/?l=linux-kernel&m=126441481427331&w=4
Handled-By	: Mike Galbraith <efault-Mmb7MZpHnFY@public.gmane.org>
		  Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

Re: [Bug #15192] netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f

[Mike Galbraith]

On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> (either way).

Yes, it should remain open.  We're currently waiting for some data from
Lin Ming.  The regression itself isn't making much sense.. a kernel with
NEWIDLE disabled should show the same performance, but does not.  

	-Mike

Re: [Bug #15192] netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f

[Rafael J. Wysocki]

On Monday 01 February 2010, Mike Galbraith wrote:
> On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Yes, it should remain open.  We're currently waiting for some data from
> Lin Ming.  The regression itself isn't making much sense.. a kernel with
> NEWIDLE disabled should show the same performance, but does not.  

Well, thanks for the update.

Rafael

Re: [Bug #15192] netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f

[Lin Ming]

On Mon, 2010-02-01 at 16:04 +0800, Mike Galbraith wrote:
> On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> > (either way).
> 
> Yes, it should remain open.  We're currently waiting for some data from
> Lin Ming.  The regression itself isn't making much sense.. a kernel with
> NEWIDLE disabled should show the same performance, but does not.  

(sorry for late response, I'm just back from vacation)

We finally located this to a bug in mwait based C-state entry.
Venki's patch has fixed it.
http://patchwork.kernel.org/patch/78544/

Venki, this is the original report,
http://marc.info/?l=linux-kernel&m=126441481427331&w=4

Thanks,
Lin Ming

Re: [Bug #15192] netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f

[Mike Galbraith]

On Sat, 2010-02-20 at 15:52 +0800, Lin Ming wrote:
> On Mon, 2010-02-01 at 16:04 +0800, Mike Galbraith wrote:
> > On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> > > (either way).
> > 
> > Yes, it should remain open.  We're currently waiting for some data from
> > Lin Ming.  The regression itself isn't making much sense.. a kernel with
> > NEWIDLE disabled should show the same performance, but does not.  
> 
> (sorry for late response, I'm just back from vacation)
> 
> We finally located this to a bug in mwait based C-state entry.
> Venki's patch has fixed it.
> http://patchwork.kernel.org/patch/78544/
> 
> Venki, this is the original report,
> http://marc.info/?l=linux-kernel&m=126441481427331&w=4

Excellent, mystery solved.  (adds acpi)

	-Mike

[Bug #15199] sata_nv and no /dev files

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15199
Subject		: sata_nv and no /dev files
Submitter	: Bartłomiej Zimoń <uzi18@o2.pl>
Date		: 2010-01-31 23:45 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126498153112488&w=4

[Bug #15198] Radeon KMS 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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15198
Subject		: Radeon KMS regression
Submitter	: Kevin Winchester <kjwinchester@gmail.com>
Date		: 2010-01-30 17:18 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=42590a75019a50012f25a962246498dead428433
References	: http://marc.info/?l=linux-kernel&m=126487191019612&w=4
Handled-By	: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Patch		: http://patchwork.kernel.org/patch/75023/

Re: [Bug #15198] Radeon KMS regression

[Kevin Winchester]

On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15198
> Subject		: Radeon KMS regression
> Submitter	: Kevin Winchester <kjwinchester@gmail.com>
> Date		: 2010-01-30 17:18 (2 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=42590a75019a50012f25a962246498dead428433
> References	: http://marc.info/?l=linux-kernel&m=126487191019612&w=4
> Handled-By	: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Patch		: http://patchwork.kernel.org/patch/75023/
> 
> 

This is fixed by the patch from FUJITA Tomonori - I just confirmed with
my latest build of Linus' tree (which has the patch).

Thanks,

-- 
Kevin Winchester

Re: [Bug #15198] Radeon KMS regression

[Rafael J. Wysocki]

On Tuesday 02 February 2010, Kevin Winchester wrote:
> On Mon, 2010-02-01 at 01:22 +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.32.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15198
> > Subject		: Radeon KMS regression
> > Submitter	: Kevin Winchester <kjwinchester-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date		: 2010-01-30 17:18 (2 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=42590a75019a50012f25a962246498dead428433
> > References	: http://marc.info/?l=linux-kernel&m=126487191019612&w=4
> > Handled-By	: FUJITA Tomonori <fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
> > Patch		: http://patchwork.kernel.org/patch/75023/
> > 
> > 
> 
> This is fixed by the patch from FUJITA Tomonori - I just confirmed with
> my latest build of Linus' tree (which has the patch).

Thanks, already closed.

Rafael

[Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15196
Subject		: kmem_cache_create: duplicate cache ccid2_h
Submitter	: Heinz Diehl <htd@fancy-poultry.org>
Date		: 2010-01-30 18:33 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=126487640324942&w=4

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[Xiaotian Feng]

On Mon, Feb 1, 2010 at 8:22 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.32.  Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=15196
> Subject         : kmem_cache_create: duplicate cache ccid2_h
> Submitter       : Heinz Diehl <htd-HjJ2MNWy62to6+H+lsi3Gti2O/JbrIOy@public.gmane.org>
> Date            : 2010-01-30 18:33 (2 days old)
> References      : http://marc.info/?l=linux-kernel&m=126487640324942&w=4

Cced Neil,

I think this one is introduced by commit
de4ef86cfce60d2250111f34f8a084e769f23b16,
passing char *slab_name_fmt as function parameter, but vsnprintf is
using sizeof(slab_name_fmt),
which is 8 (or 4 in 32bit kernel) instead of 32 as old version.

Does following patch resolve this bug, Heinz?

diff --git a/net/dccp/ccid.c b/net/dccp/ccid.c
index 57dfb9c..6e52879 100644
--- a/net/dccp/ccid.c
+++ b/net/dccp/ccid.c
@@ -77,13 +77,14 @@ int ccid_getsockopt_builtin_ccids(struct sock *sk, int len,
        return err;
 }

-static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char
*slab_name_fmt, const char *fmt,...)
+static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char
*slab_name_fmt,
+                                                int length,const char *fmt,...)
 {
        struct kmem_cache *slab;
        va_list args;

        va_start(args, fmt);
-       vsnprintf(slab_name_fmt, sizeof(slab_name_fmt), fmt, args);
+       vsnprintf(slab_name_fmt, length, fmt, args);
        va_end(args);

        slab = kmem_cache_create(slab_name_fmt, sizeof(struct ccid) +
obj_size, 0,
@@ -104,6 +105,7 @@ static int ccid_activate(struct ccid_operations *ccid_ops)
        ccid_ops->ccid_hc_rx_slab =
                        ccid_kmem_cache_create(ccid_ops->ccid_hc_rx_obj_size,
                                               ccid_ops->ccid_hc_rx_slab_name,
+
sizeof(ccid_ops->ccid_hc_rx_slab_name),
                                               "ccid%u_hc_rx_sock",
                                               ccid_ops->ccid_id);
        if (ccid_ops->ccid_hc_rx_slab == NULL)
@@ -112,6 +114,7 @@ static int ccid_activate(struct ccid_operations *ccid_ops)
        ccid_ops->ccid_hc_tx_slab =
                        ccid_kmem_cache_create(ccid_ops->ccid_hc_tx_obj_size,
                                               ccid_ops->ccid_hc_tx_slab_name,
+
sizeof(ccid_ops->ccid_hc_tx_slab_name),
                                               "ccid%u_hc_tx_sock",
                                               ccid_ops->ccid_id);
        if (ccid_ops->ccid_hc_tx_slab == NULL)

>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[David Miller]

From: Xiaotian Feng <xtfeng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 1 Feb 2010 11:30:02 +0800

> On Mon, Feb 1, 2010 at 8:22 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.32.  Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=15196
>> Subject         : kmem_cache_create: duplicate cache ccid2_h
>> Submitter       : Heinz Diehl <htd-HjJ2MNWy62to6+H+lsi3Gti2O/JbrIOy@public.gmane.org>
>> Date            : 2010-01-30 18:33 (2 days old)
>> References      : http://marc.info/?l=linux-kernel&m=126487640324942&w=4
> 
> Cced Neil,
> 
> I think this one is introduced by commit
> de4ef86cfce60d2250111f34f8a084e769f23b16,
> passing char *slab_name_fmt as function parameter, but vsnprintf is
> using sizeof(slab_name_fmt),
> which is 8 (or 4 in 32bit kernel) instead of 32 as old version.
> 
> Does following patch resolve this bug, Heinz?

There seems to be even more to this than that.  Neils
patch seems to need completely reverting.

See the patch set posted by Gerrit Renker:

http://marc.info/?l=linux-netdev&m=126500585823775&w=2
http://marc.info/?l=linux-netdev&m=126500591923880&w=2

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[Neil Horman]

On Sun, Jan 31, 2010 at 11:20:50PM -0800, David Miller wrote:
> From: Xiaotian Feng <xtfeng@gmail.com>
> Date: Mon, 1 Feb 2010 11:30:02 +0800
> 
> > On Mon, Feb 1, 2010 at 8:22 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.32.  Please verify if it still should be listed and let me know
> >> (either way).
> >>
> >>
> >> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=15196
> >> Subject         : kmem_cache_create: duplicate cache ccid2_h
> >> Submitter       : Heinz Diehl <htd@fancy-poultry.org>
> >> Date            : 2010-01-30 18:33 (2 days old)
> >> References      : http://marc.info/?l=linux-kernel&m=126487640324942&w=4
> > 
> > Cced Neil,
> > 
> > I think this one is introduced by commit
> > de4ef86cfce60d2250111f34f8a084e769f23b16,
> > passing char *slab_name_fmt as function parameter, but vsnprintf is
> > using sizeof(slab_name_fmt),
> > which is 8 (or 4 in 32bit kernel) instead of 32 as old version.
> > 
> > Does following patch resolve this bug, Heinz?
> 
> There seems to be even more to this than that.  Neils
> patch seems to need completely reverting.
> 
> See the patch set posted by Gerrit Renker:
> 
> http://marc.info/?l=linux-netdev&m=126500585823775&w=2
> http://marc.info/?l=linux-netdev&m=126500591923880&w=2
> 


Dave, some of this doesn't make the least bit of sense to me.  I get the sizeof
error, thats clear (and I apologize, I should have seen that), but Gerrits
revert of the dccp_probe changes is non-sensical.  I'm not sure I even follow
the comments:

>Previously (during about 4 years of this module's history) there had never
>been a problem with the 'silent dependency' that the commit tried to fix:
>this dependency is deliberate and required, since dccp_probe performs probing
>of dccp connections and hence needs to know about dccp internals.

He claims this dependency is deliberate and requires, to which I agree, but he
would seem to fix that by making the dccp_probe module error out in the event
that dccp wasn't loaded.  Why bother with that?
Neil

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[David Miller]

From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 1 Feb 2010 06:55:18 -0500

> He claims this dependency is deliberate and requires, to which I agree, but he
> would seem to fix that by making the dccp_probe module error out in the event
> that dccp wasn't loaded.  Why bother with that?

Neil, please get into the thread Gerrit started so he can see your
questions and responses too.

I already chided him for not CC:'ing you in the first place, guys
stop hiding from eachother :-)

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[Neil Horman]

On Mon, Feb 01, 2010 at 04:49:11AM -0800, David Miller wrote:
> From: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Mon, 1 Feb 2010 06:55:18 -0500
> 
> > He claims this dependency is deliberate and requires, to which I agree, but he
> > would seem to fix that by making the dccp_probe module error out in the event
> > that dccp wasn't loaded.  Why bother with that?
> 
> Neil, please get into the thread Gerrit started so he can see your
> questions and responses too.
> 
> I already chided him for not CC:'ing you in the first place, guys
> stop hiding from eachother :-)
> 
I already posted to both of his posts (about 45 minutes ago).  I think vger is
being slow (whoever runs that system should really tune it up ;) )

Neil

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[Heinz Diehl]

On 01.02.2010, Xiaotian Feng wrote: 

> Does following patch resolve this bug, Heinz?
[....]

The patch was completely malformed, don't know what happened on the way,
but I applied it by hand. Yes, it fixes the problem for me.

Thanks,
Heinz.

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[Heinz Diehl]

On 01.02.2010, Heinz Diehl wrote: 

[....]

Quoting myself here...

> The patch was completely malformed, don't know what happened on the way,
> but I applied it by hand. Yes, it fixes the problem for me.

Xiaotiangs patch quoted in the thread listed here (coming via kernel.org's
bugtracker)

 http://patchwork.kernel.org/patch/76023/
 
is missing some lines, and the patch attached at the end of the
thread is incomplete and malformed, as reported earlier. I guess this is
how it should have looked like (please correct me if I'm wrong):


--- /a/ccid.c	2010-02-06 23:17:12.000000000 +0100
+++ /b/ccid.c	2010-02-07 09:50:40.000000000 +0100
@@ -77,13 +77,13 @@
 	return err;
 }
 
-static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char *slab_name_fmt, const char *fmt,...)
+static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char *slab_name_fmt, int length, const char *fmt,...)
 {
 	struct kmem_cache *slab;
 	va_list args;
 
 	va_start(args, fmt);
-	vsnprintf(slab_name_fmt, sizeof(slab_name_fmt), fmt, args);
+	vsnprintf(slab_name_fmt, length, fmt, args);
 	va_end(args);
 
 	slab = kmem_cache_create(slab_name_fmt, sizeof(struct ccid) + obj_size, 0,
@@ -104,6 +104,7 @@
 	ccid_ops->ccid_hc_rx_slab =
 			ccid_kmem_cache_create(ccid_ops->ccid_hc_rx_obj_size,
 					       ccid_ops->ccid_hc_rx_slab_name,
+					       sizeof(ccid_ops->ccid_hc_rx_slab_name),
 					       "ccid%u_hc_rx_sock",
 					       ccid_ops->ccid_id);
 	if (ccid_ops->ccid_hc_rx_slab == NULL)
@@ -112,6 +113,7 @@
 	ccid_ops->ccid_hc_tx_slab =
 			ccid_kmem_cache_create(ccid_ops->ccid_hc_tx_obj_size,
 					       ccid_ops->ccid_hc_tx_slab_name,
+					       sizeof(ccid_ops->ccid_hc_tx_slab_name),
 					       "ccid%u_hc_tx_sock",
 					       ccid_ops->ccid_id);
 	if (ccid_ops->ccid_hc_tx_slab == NULL)

Re: [Bug #15196] kmem_cache_create: duplicate cache ccid2_h

[Rafael J. Wysocki]

On Sunday 07 February 2010, Heinz Diehl wrote:
> On 01.02.2010, Heinz Diehl wrote: 
> 
> [....]
> 
> Quoting myself here...
> 
> > The patch was completely malformed, don't know what happened on the way,
> > but I applied it by hand. Yes, it fixes the problem for me.
> 
> Xiaotiangs patch quoted in the thread listed here (coming via kernel.org's
> bugtracker)
> 
>  http://patchwork.kernel.org/patch/76023/
>  
> is missing some lines, and the patch attached at the end of the
> thread is incomplete and malformed, as reported earlier. I guess this is
> how it should have looked like (please correct me if I'm wrong):

Thanks, I updated the bug entry with a link to your patch below.

> --- /a/ccid.c	2010-02-06 23:17:12.000000000 +0100
> +++ /b/ccid.c	2010-02-07 09:50:40.000000000 +0100
> @@ -77,13 +77,13 @@
>  	return err;
>  }
>  
> -static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char *slab_name_fmt, const char *fmt,...)
> +static struct kmem_cache *ccid_kmem_cache_create(int obj_size, char *slab_name_fmt, int length, const char *fmt,...)
>  {
>  	struct kmem_cache *slab;
>  	va_list args;
>  
>  	va_start(args, fmt);
> -	vsnprintf(slab_name_fmt, sizeof(slab_name_fmt), fmt, args);
> +	vsnprintf(slab_name_fmt, length, fmt, args);
>  	va_end(args);
>  
>  	slab = kmem_cache_create(slab_name_fmt, sizeof(struct ccid) + obj_size, 0,
> @@ -104,6 +104,7 @@
>  	ccid_ops->ccid_hc_rx_slab =
>  			ccid_kmem_cache_create(ccid_ops->ccid_hc_rx_obj_size,
>  					       ccid_ops->ccid_hc_rx_slab_name,
> +					       sizeof(ccid_ops->ccid_hc_rx_slab_name),
>  					       "ccid%u_hc_rx_sock",
>  					       ccid_ops->ccid_id);
>  	if (ccid_ops->ccid_hc_rx_slab == NULL)
> @@ -112,6 +113,7 @@
>  	ccid_ops->ccid_hc_tx_slab =
>  			ccid_kmem_cache_create(ccid_ops->ccid_hc_tx_obj_size,
>  					       ccid_ops->ccid_hc_tx_slab_name,
> +					       sizeof(ccid_ops->ccid_hc_tx_slab_name),
>  					       "ccid%u_hc_tx_sock",
>  					       ccid_ops->ccid_id);
>  	if (ccid_ops->ccid_hc_tx_slab == NULL)
> 

Rafael

[Bug #15200] NFS problems in 2.6.33-rc6: Unknown error 526

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15200
Subject		: NFS problems in 2.6.33-rc6: Unknown error 526
Submitter	: J.A. Magallón <jamagallon@ono.com>
Date		: 2010-01-31 22:46 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126497800408928&w=4

[Bug #15202] lockdep warning during elevator_switch

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15202
Subject		: lockdep warning during elevator_switch
Submitter	: Hugh Dickins <hugh.dickins-IWqWACnzNjwqdlJmJB21zg@public.gmane.org>
Date		: 2010-01-31 23:55 (1 days old)
References	: http://marc.info/?l=linux-kernel&m=126498212613051&w=4

2.6.33-rc5: Reported regressions from 2.6.32

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.32, 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.32, 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
  ----------------------------------------
  2010-01-24       75       29          23
  2010-01-10       55       33          21
  2009-12-29       36       34          27


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15139
Subject		: e1000: transmit queue 0 timed out
Submitter	: Alexander Beregalov <a.beregalov@gmail.com>
Date		: 2010-01-23 15:37 (2 days old)
References	: http://marc.info/?l=linux-netdev&m=126426149306083&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15138
Subject		: evdev regression on macbook
Submitter	: Guillaume Chazarain <guichaz@gmail.com>
Date		: 2010-01-23 18:53 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=126427286219235&w=4
Handled-By	: Dmitry Torokhov <dmitry.torokhov@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15133
Subject		: Wake on LAN doesn't work in sky2
Submitter	: Tino Keitel <tino.keitel@tikei.de>
Date		: 2010-01-15 9:10 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=166a0fd4c788ec7f10ca8194ec6d526afa12db75
References	: http://marc.info/?l=linux-kernel&m=126354704815848&w=4
Handled-By	: Stephen Hemminger <shemminger@vyatta.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15132
Subject		: OOPS's with large initramfs
Submitter	: Nigel Kukard <nkukard@lbsd.net>
Date		: 2010-01-16 11:12 (9 days old)
References	: http://marc.info/?l=linux-kernel&m=126364100321603&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15129
Subject		: [drm:i915_gem_execbuffer] *ERROR* i915_gem_do_execbuffer returns -512
Submitter	: Miles Lane <miles.lane@gmail.com>
Date		: 2010-01-14 23:18 (11 days old)
References	: http://lkml.org/lkml/2010/1/14/570
Handled-By	: Chris Wilson <chris@chris-wilson.co.uk>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15126
Subject		: REGRESSION for RT2561/RT61 in 2.6.33
Submitter	: Alan Stern <stern@rowland.harvard.edu>
Date		: 2010-01-11 14:54 (14 days old)
References	: http://marc.info/?l=linux-kernel&m=126322167427159&w=4
Handled-By	: Johannes Berg <johannes@sipsolutions.net>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15125
Subject		: hung task - jbd2/dm-1-8 (during raid rebuild)
Submitter	: Michael Breuer <mbreuer@majjas.com>
Date		: 2010-01-10 21:47 (15 days old)
References	: http://marc.info/?l=linux-kernel&m=126316012025978&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
Subject		: PCI host bridge windows ignored (works with pci=use_crs)
Submitter	: Jeff Garrett <jeff@jgarrett.org>
Date		: 2010-01-13 5:37 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
Handled-By	: Yinghai Lu <yinghai@kernel.org>
		  Bjorn Helgaas <bjorn.helgaas@hp.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15076
Subject		: System panic under load with clockevents_program_event
Submitter	: okias <d.okias@gmail.com>
Date		: 2010-01-17 13:03 (8 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15043
Subject		: Display goes off with i915.powersave=1
Submitter	: Soeren Sonnenburg <sonne@debian.org>
Date		: 2010-01-10 20:09 (15 days old)
References	: http://marc.info/?l=linux-kernel&m=126315457519505&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15038
Subject		: drm/ksm: fbdev blanking regression
Submitter	: Johan Hovold <jhovold@gmail.com>
Date		: 2010-01-06 17:00 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=731b5a15a3b1474a41c2ca29b4c32b0f21bc852e
References	: http://marc.info/?l=linux-kernel&m=126279726418748&w=4
Handled-By	: James Simmons <jsimmons@infradead.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15036
Subject		: soft lockup in dmesg after suspend/resume
Submitter	: ykzhao <yakui.zhao@intel.com>
Date		: 2010-01-04 5:36 (21 days old)
References	: http://marc.info/?l=linux-kernel&m=126258356202722&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15032
Subject		: Oops in uart_resume_port() on resume
Submitter	: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date		: 2010-01-04 15:47 (21 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba15ab0e8de0d4439a91342ad52d55ca9e313f3d
References	: http://marc.info/?l=linux-kernel&m=126262008815689&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15025
Subject		: Oops in ext4 driver
Submitter	: Steinar H. Gunderson <sgunderson@bigfoot.com>
Date		: 2010-01-10 13:09 (15 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15017
Subject		: kexec regression, radeon/kms irq related (bisected)
Submitter	: Markus Trippelsdorf <markus@trippelsdorf.de>
Date		: 2010-01-09 18:49 (16 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d8f60cfc93452d0554f6a701aa8e3236cbee4636


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15000
Subject		: Thinkpad dock button no longer works
Submitter	: Paul Martin <pm@debian.org>
Date		: 2010-01-07 02:11 (18 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14999
Subject		: possible circular locking dependency detected in rfkill at suspend
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2010-01-06 21:52 (19 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14950
Subject		: tbench regression with 2.6.33-rc1
Submitter	: Lin Ming <ming.m.lin@intel.com>
Date		: 2009-12-25 11:11 (31 days old)
References	: http://marc.info/?l=linux-kernel&m=126174044213172&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14946
Subject		: All kernels after 2.6.32-git10  show only 1 CPU
Submitter	: Sid Boyce <sboyce@blueyonder.co.uk>
Date		: 2009-12-23 16:55 (33 days old)
References	: http://marc.info/?l=linux-kernel&m=126158734326801&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14937
Subject		: WARNING: at kernel/lockdep.c:2830
Submitter	: Grant Wilson <grant.wilson@zen.co.uk>
Date		: 2009-12-27 13:35 (29 days old)
References	: http://marc.info/?l=linux-kernel&m=126192220404829&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14924
Subject		: Weird hard hangs when rendering 'some' web-sites in Firefox
Submitter	: David <david@unsolicited.net>
Date		: 2009-12-21 21:53 (35 days old)
References	: http://marc.info/?l=linux-kernel&m=126143375823340&w=4


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14859
Subject		: System timer firing too much without cause
Submitter	: Shawn Starr <shawn.starr@rogers.com>
Date		: 2009-12-21 19:16 (35 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14792
Subject		: Misdetection of the TV output
Submitter	: Santi <santi@agolina.net>
Date		: 2009-12-12 13:28 (44 days old)


Regressions with patches
------------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15137
Subject		: NULL pointer dereference in vlan_skb_recv
Submitter	: Bruno Prémont <bonbons@linux-vserver.org>
Date		: 2010-01-23 15:56 (2 days old)
References	: http://marc.info/?l=linux-kernel&m=126426286507497&w=4
Handled-By	: Eric Dumazet <eric.dumazet@gmail.com>
Patch		: http://patchwork.kernel.org/patch/74999/
		  http://patchwork.kernel.org/patch/75002/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15131
Subject		: [OOPS] radeon kms
Submitter	: John Kacur <jkacur@redhat.com>
Date		: 2010-01-15 15:45 (10 days old)
References	: http://lkml.org/lkml/2010/1/15/129
Handled-By	: Jerome Glisse <glisse@freedesktop.org>
Patch		: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=patch;h=30d2d9a54d48e4fefede0389ded1b6fc2d44a522


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15128
Subject		: Boot regression on AMD
Submitter	: Gene Heskett <gene.heskett@verizon.net>
Date		: 2010-01-13 20:21 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=126341413213017&w=4
Handled-By	: Andreas Herrmann <andreas.herrmann3@amd.com>
Patch		: http://patchwork.kernel.org/patch/74883/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15039
Subject		: leds_alix2: can't allocate I/O for GPIO
Submitter	: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
Date		: 2010-01-07 10:26 (18 days old)
References	: http://marc.info/?l=linux-kernel&m=126286001106257&w=4
Handled-By	: Daniel Mack <daniel@caiaq.de>
Patch		: http://patchwork.kernel.org/patch/72006/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14949
Subject		: drm_vm.c:drm_mmap: possible circular locking dependency detected
Submitter	: Borislav Petkov <petkovbb@googlemail.com>
Date		: 2009-12-26 9:45 (30 days old)
References	: http://marc.info/?l=linux-kernel&m=126182073616279&w=4
Handled-By	: Eric W. Biederman <ebiederm@aristanetworks.com>
Patch		: http://patchwork.kernel.org/patch/70461/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=14791
Subject		: Something has been broken in the network stack this week
Submitter	: Delete This Account <speedyboyinovator@hotmail.com>
Date		: 2009-12-12 13:06 (44 days old)
Handled-By	: Ben Hutchings <ben@decadent.org.uk>
Patch		: http://patchwork.kernel.org/patch/72073/


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.32,
unresolved as well as resolved, at:

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

Please let me know if there are any Bugzilla entries that should be added to
the list in there.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[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.32.  Please verify if it still should be listed and let me know
(either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
Subject		: PCI host bridge windows ignored (works with pci=use_crs)
Submitter	: Jeff Garrett <jeff@jgarrett.org>
Date		: 2010-01-13 5:37 (12 days old)
References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
Handled-By	: Yinghai Lu <yinghai@kernel.org>
		  Bjorn Helgaas <bjorn.helgaas@hp.com>

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jeff Garrett]

On Sun, Jan 24, 2010 at 11:04:38PM +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.32.  Please verify if it still should be listed and let me know
> (either way).
> 
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> Submitter	: Jeff Garrett <jeff@jgarrett.org>
> Date		: 2010-01-13 5:37 (12 days old)
> References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> Handled-By	: Yinghai Lu <yinghai@kernel.org>
> 		  Bjorn Helgaas <bjorn.helgaas@hp.com>

This regression should still be listed.  No patch to test yet.

-Jeff Garrett

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Tuesday 26 January 2010, Jeff Garrett wrote:
> On Sun, Jan 24, 2010 at 11:04:38PM +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.32.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > Submitter	: Jeff Garrett <jeff@jgarrett.org>
> > Date		: 2010-01-13 5:37 (12 days old)
> > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > Handled-By	: Yinghai Lu <yinghai@kernel.org>
> > 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> This regression should still be listed.  No patch to test yet.

Thanks for the update.

IIRC, we already know how to fix this ...

Rafael

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Tuesday 26 January 2010 05:48:59 am Rafael J. Wysocki wrote:
> On Tuesday 26 January 2010, Jeff Garrett wrote:
> > On Sun, Jan 24, 2010 at 11:04:38PM +0100, Rafael J. Wysocki wrote:
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.32.  Please verify if it still should be listed and let me know
> > > (either way).
> > > 
> > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > > Submitter	: Jeff Garrett <jeff@jgarrett.org>
> > > Date		: 2010-01-13 5:37 (12 days old)
> > > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > > Handled-By	: Yinghai Lu <yinghai@kernel.org>
> > > 		  Bjorn Helgaas <bjorn.helgaas@hp.com>
> > 
> > This regression should still be listed.  No patch to test yet.
> ...
> IIRC, we already know how to fix this ...

As far as I know, we do NOT know how to fix this.

This regression occurred when we added intel_bus.c because it's not
yet smart enough to determine the correct host bridge apertures.
Here's what it thinks the bridge aperture is and the Radeon BAR:

  IOH bus: 00 index 1 mmio: [e0000000, fdffffff]
  pci 0000:04:00.0: reg 10: [mem 0xd0000000-0xdfffffff 64bit pref]

The IOH aperture is obviously not big enough to cover the Radeon BAR.
But the host bridge _CRS tells us this:

  pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff]
  pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff]

which IS big enough, and we know the bridge is in fact forwarding the
[mem 0xd0000000-0xdfffffff 64bit pref] region, because the Radeon works
when Jeff boots with "pci=use_crs".

I'm quite concerned about this for .33 because I don't think Jeff's
configuration (Dell desktop with Intel x58 and large graphics device)
is unusual.

The benefit of intel_bus.c is on machines with multiple IOHs, where we
need to figure out which address ranges go to which IOHs so we can
program downstream devices correctly.  But even there, _CRS should give
us the information we need, so "pci=use_crs" should make these machines
work.

I think we should remove intel_bus.c before .33.  It's breaking boxes
and we don't know how to fix it.  Even if we do find out how to fix it,
I think we should move toward using _CRS instead, because that's what
Windows uses and it's an easy way for the firmware to tell us about
platform quirks.

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Tuesday 26 January 2010, Bjorn Helgaas wrote:
> On Tuesday 26 January 2010 05:48:59 am Rafael J. Wysocki wrote:
> > On Tuesday 26 January 2010, Jeff Garrett wrote:
> > > On Sun, Jan 24, 2010 at 11:04:38PM +0100, Rafael J. Wysocki wrote:
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.32.  Please verify if it still should be listed and let me know
> > > > (either way).
> > > > 
> > > > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=15124
> > > > Subject		: PCI host bridge windows ignored (works with pci=use_crs)
> > > > Submitter	: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>
> > > > Date		: 2010-01-13 5:37 (12 days old)
> > > > References	: http://marc.info/?l=linux-kernel&m=126336296600307&w=4
> > > > Handled-By	: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > 		  Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
> > > 
> > > This regression should still be listed.  No patch to test yet.
> > ...
> > IIRC, we already know how to fix this ...
> 
> As far as I know, we do NOT know how to fix this.
> 
> This regression occurred when we added intel_bus.c because it's not
> yet smart enough to determine the correct host bridge apertures.
> Here's what it thinks the bridge aperture is and the Radeon BAR:
> 
>   IOH bus: 00 index 1 mmio: [e0000000, fdffffff]
>   pci 0000:04:00.0: reg 10: [mem 0xd0000000-0xdfffffff 64bit pref]
> 
> The IOH aperture is obviously not big enough to cover the Radeon BAR.
> But the host bridge _CRS tells us this:
> 
>   pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff]
>   pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff]
> 
> which IS big enough, and we know the bridge is in fact forwarding the
> [mem 0xd0000000-0xdfffffff 64bit pref] region, because the Radeon works
> when Jeff boots with "pci=use_crs".
> 
> I'm quite concerned about this for .33 because I don't think Jeff's
> configuration (Dell desktop with Intel x58 and large graphics device)
> is unusual.
> 
> The benefit of intel_bus.c is on machines with multiple IOHs, where we
> need to figure out which address ranges go to which IOHs so we can
> program downstream devices correctly.  But even there, _CRS should give
> us the information we need, so "pci=use_crs" should make these machines
> work.
> 
> I think we should remove intel_bus.c before .33.  It's breaking boxes
> and we don't know how to fix it.  Even if we do find out how to fix it,
> I think we should move toward using _CRS instead, because that's what
> Windows uses and it's an easy way for the firmware to tell us about
> platform quirks.

Perhaps it would be sufficient to make pci=use_crs the default and leave the
option to use intel_bus.c for whoever needs that?

Rafael

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Tue, 26 Jan 2010 19:02:13 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > I'm quite concerned about this for .33 because I don't think Jeff's
> > configuration (Dell desktop with Intel x58 and large graphics device)
> > is unusual.
> > 
> > The benefit of intel_bus.c is on machines with multiple IOHs, where we
> > need to figure out which address ranges go to which IOHs so we can
> > program downstream devices correctly.  But even there, _CRS should give
> > us the information we need, so "pci=use_crs" should make these machines
> > work.
> > 
> > I think we should remove intel_bus.c before .33.  It's breaking boxes
> > and we don't know how to fix it.  Even if we do find out how to fix it,
> > I think we should move toward using _CRS instead, because that's what
> > Windows uses and it's an easy way for the firmware to tell us about
> > platform quirks.
> 
> Perhaps it would be sufficient to make pci=use_crs the default and leave the
> option to use intel_bus.c for whoever needs that?

We can't make use_crs the default w/o some more _CRS handling fixes
(some firmwares have large lists we need to handle).

We can disable intel_bus.c though.  Yinghai, I'm inclined against the
intel_bus.c approach at this point.  It seems unlikely we'll ever keep
it up to date with new bridges, since its approach differs so much from
how things are done in the Windows world, where the firmware provides
a list of resources.  We'll always be playing catch up, and will
probably be behind the firmware most of the time since the docs with
the necessary info likely won't be public most of the time.

For 2.6.33 I'd like a minimal fix though, can you disable it for all
but the multi-IOH case perhaps?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/26/2010 10:17 AM, Jesse Barnes wrote:
> On Tue, 26 Jan 2010 19:02:13 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>>> I'm quite concerned about this for .33 because I don't think Jeff's
>>> configuration (Dell desktop with Intel x58 and large graphics device)
>>> is unusual.
>>>
>>> The benefit of intel_bus.c is on machines with multiple IOHs, where we
>>> need to figure out which address ranges go to which IOHs so we can
>>> program downstream devices correctly.  But even there, _CRS should give
>>> us the information we need, so "pci=use_crs" should make these machines
>>> work.
>>>
>>> I think we should remove intel_bus.c before .33.  It's breaking boxes
>>> and we don't know how to fix it.  Even if we do find out how to fix it,
>>> I think we should move toward using _CRS instead, because that's what
>>> Windows uses and it's an easy way for the firmware to tell us about
>>> platform quirks.
>>
>> Perhaps it would be sufficient to make pci=use_crs the default and leave the
>> option to use intel_bus.c for whoever needs that?
> 
> We can't make use_crs the default w/o some more _CRS handling fixes
> (some firmwares have large lists we need to handle).
> 
> We can disable intel_bus.c though.  Yinghai, I'm inclined against the
> intel_bus.c approach at this point.  It seems unlikely we'll ever keep
> it up to date with new bridges, since its approach differs so much from
> how things are done in the Windows world, where the firmware provides
> a list of resources.  We'll always be playing catch up, and will
> probably be behind the firmware most of the time since the docs with
> the necessary info likely won't be public most of the time.
> 
> For 2.6.33 I'd like a minimal fix though, can you disable it for all
> but the multi-IOH case perhaps?

ok, we have one patch to enable that only with multi-IOH case.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/26/2010 10:17 AM, Jesse Barnes wrote:

> 
> For 2.6.33 I'd like a minimal fix though, can you disable it for all
> but the multi-IOH case perhaps?
> 
please check,

[PATCH] x86/pci: don't use ioh resource if only have one ioh

some system could use reosurce out of IOH resources when only one ioh is there.

could be BIOS have wrong IOH resources and not enable them.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/pci/intel_bus.c |   86 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

Index: linux-2.6/arch/x86/pci/intel_bus.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/intel_bus.c
+++ linux-2.6/arch/x86/pci/intel_bus.c
@@ -7,9 +7,11 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <asm/pci_x86.h>
+#include <asm/pci-direct.h>
 
 #include "bus_numa.h"
 
+static int nr_ioh;
 static inline void print_ioh_resources(struct pci_root_info *info)
 {
 	int res_num;
@@ -49,6 +51,9 @@ static void __devinit pci_root_bus_res(s
 	u64 mmioh_base, mmioh_end;
 	int bus_base, bus_end;
 
+	if (nr_ioh < 2)
+		return;
+
 	/* some sys doesn't get mmconf enabled */
 	if (dev->cfg_size < 0x120)
 		return;
@@ -92,3 +97,84 @@ static void __devinit pci_root_bus_res(s
 
 /* intel IOH */
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, pci_root_bus_res);
+
+static void __init count_ioh(int num, int slot, int func)
+{
+	nr_ioh++;
+}
+
+struct pci_check_probe {
+	u32 vendor;
+	u32 device;
+	void (*f)(int num, int slot, int func);
+};
+
+static struct pci_check_probe early_qrk[] __initdata = {
+	{ PCI_VENDOR_ID_INTEL, 0x342e, count_ioh },
+	{}
+};
+
+static void __init early_check_pci_dev(int num, int slot, int func)
+{
+	u16 vendor;
+	u16 device;
+	int i;
+
+	vendor = read_pci_config_16(num, slot, func, PCI_VENDOR_ID);
+	device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
+
+	for (i = 0; early_qrk[i].f != NULL; i++) {
+		if (((early_qrk[i].vendor == PCI_ANY_ID) ||
+			(early_qrk[i].vendor == vendor)) &&
+			((early_qrk[i].device == PCI_ANY_ID) ||
+			(early_qrk[i].device == device)))
+				early_qrk[i].f(num, slot, func);
+	}
+}
+
+static void __init early_check_pci_devs(void)
+{
+	unsigned bus, slot, func;
+
+	if (!early_pci_allowed())
+		return;
+
+	for (bus = 0; bus < 256; bus++) {
+		for (slot = 0; slot < 32; slot++) {
+			for (func = 0; func < 8; func++) {
+				u32 class;
+				u8 type;
+
+				class = read_pci_config(bus, slot, func,
+							PCI_CLASS_REVISION);
+				if (class == 0xffffffff)
+					continue;
+
+				early_check_pci_dev(bus, slot, func);
+
+				if (func == 0) {
+					type = read_pci_config_byte(bus, slot,
+								    func,
+							       PCI_HEADER_TYPE);
+					if (!(type & 0x80))
+						break;
+				}
+			}
+		}
+	}
+}
+
+static int __init intel_postcore_init(void)
+{
+	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+		return 0;
+
+	early_check_pci_devs();
+
+	if (nr_ioh)
+		printk(KERN_DEBUG "pci: found %d IOH\n", nr_ioh);
+
+	return 0;
+}
+postcore_initcall(intel_postcore_init);
+

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Tuesday 26 January 2010 03:57:31 pm Yinghai Lu wrote:
> [PATCH] x86/pci: don't use ioh resource if only have one ioh
> 
> some system could use reosurce out of IOH resources when only one ioh is there.
> 
> could be BIOS have wrong IOH resources and not enable them.

The subtractive decode theory makes sense and would explain what's
happening, but I don't like this patch.

If we assume that this really is a subtractive decode issue, this
patch approaches it the wrong way.  We need to know whether a
particular host bridge is configured for subtractive decode.  This
patch tests whether we have more than one host bridge, which is quite
a different question.

Imagine these system configurations:

  1) a single host bridge with subtractive decode
  2) a single host bridge with only positive decode
  3) multiple host bridges with subtractive decode enabled on one
  4) multiple host bridges with only positive decode

This patch will break if we encounter configs 2 or 3.  In config 2,
this patch assumes the bridge performs subtractive decode, so we
think the bridge forwards more address space than it actually does.
If we try to use that address space, the device will never see the
accesses.  In config 3, this patch assumes there's no subtractive
decode, so we would see Jeff's problem all over again.

For configs 3 and 4, there might be a single host bridge in domain 0,
with the others in different domains.  This patch would find only one
host bridge (the one in domain 0), so we would wrongly assume that ALL
the host bridges use subtractive decode, which is obviously a disaster.

Bjorn

> ---
>  arch/x86/pci/intel_bus.c |   86 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 86 insertions(+)
> 
> Index: linux-2.6/arch/x86/pci/intel_bus.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/pci/intel_bus.c
> +++ linux-2.6/arch/x86/pci/intel_bus.c
> @@ -7,9 +7,11 @@
>  #include <linux/pci.h>
>  #include <linux/init.h>
>  #include <asm/pci_x86.h>
> +#include <asm/pci-direct.h>
>  
>  #include "bus_numa.h"
>  
> +static int nr_ioh;
>  static inline void print_ioh_resources(struct pci_root_info *info)
>  {
>  	int res_num;
> @@ -49,6 +51,9 @@ static void __devinit pci_root_bus_res(s
>  	u64 mmioh_base, mmioh_end;
>  	int bus_base, bus_end;
>  
> +	if (nr_ioh < 2)
> +		return;
> +
>  	/* some sys doesn't get mmconf enabled */
>  	if (dev->cfg_size < 0x120)
>  		return;
> @@ -92,3 +97,84 @@ static void __devinit pci_root_bus_res(s
>  
>  /* intel IOH */
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, pci_root_bus_res);
> +
> +static void __init count_ioh(int num, int slot, int func)
> +{
> +	nr_ioh++;
> +}
> +
> +struct pci_check_probe {
> +	u32 vendor;
> +	u32 device;
> +	void (*f)(int num, int slot, int func);
> +};
> +
> +static struct pci_check_probe early_qrk[] __initdata = {
> +	{ PCI_VENDOR_ID_INTEL, 0x342e, count_ioh },
> +	{}
> +};
> +
> +static void __init early_check_pci_dev(int num, int slot, int func)
> +{
> +	u16 vendor;
> +	u16 device;
> +	int i;
> +
> +	vendor = read_pci_config_16(num, slot, func, PCI_VENDOR_ID);
> +	device = read_pci_config_16(num, slot, func, PCI_DEVICE_ID);
> +
> +	for (i = 0; early_qrk[i].f != NULL; i++) {
> +		if (((early_qrk[i].vendor == PCI_ANY_ID) ||
> +			(early_qrk[i].vendor == vendor)) &&
> +			((early_qrk[i].device == PCI_ANY_ID) ||
> +			(early_qrk[i].device == device)))
> +				early_qrk[i].f(num, slot, func);
> +	}
> +}
> +
> +static void __init early_check_pci_devs(void)
> +{
> +	unsigned bus, slot, func;
> +
> +	if (!early_pci_allowed())
> +		return;
> +
> +	for (bus = 0; bus < 256; bus++) {
> +		for (slot = 0; slot < 32; slot++) {
> +			for (func = 0; func < 8; func++) {
> +				u32 class;
> +				u8 type;
> +
> +				class = read_pci_config(bus, slot, func,
> +							PCI_CLASS_REVISION);
> +				if (class == 0xffffffff)
> +					continue;
> +
> +				early_check_pci_dev(bus, slot, func);
> +
> +				if (func == 0) {
> +					type = read_pci_config_byte(bus, slot,
> +								    func,
> +							       PCI_HEADER_TYPE);
> +					if (!(type & 0x80))
> +						break;
> +				}
> +			}
> +		}
> +	}
> +}
> +
> +static int __init intel_postcore_init(void)
> +{
> +	if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> +		return 0;
> +
> +	early_check_pci_devs();
> +
> +	if (nr_ioh)
> +		printk(KERN_DEBUG "pci: found %d IOH\n", nr_ioh);
> +
> +	return 0;
> +}
> +postcore_initcall(intel_postcore_init);
> +
> 

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Wed, 27 Jan 2010 09:45:15 -0700
Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:

> On Tuesday 26 January 2010 03:57:31 pm Yinghai Lu wrote:
> > [PATCH] x86/pci: don't use ioh resource if only have one ioh
> > 
> > some system could use reosurce out of IOH resources when only one ioh is there.
> > 
> > could be BIOS have wrong IOH resources and not enable them.
> 
> The subtractive decode theory makes sense and would explain what's
> happening, but I don't like this patch.
> 
> If we assume that this really is a subtractive decode issue, this
> patch approaches it the wrong way.  We need to know whether a
> particular host bridge is configured for subtractive decode.  This
> patch tests whether we have more than one host bridge, which is quite
> a different question.
> 
> Imagine these system configurations:
> 
>   1) a single host bridge with subtractive decode
>   2) a single host bridge with only positive decode
>   3) multiple host bridges with subtractive decode enabled on one
>   4) multiple host bridges with only positive decode
> 
> This patch will break if we encounter configs 2 or 3.  In config 2,
> this patch assumes the bridge performs subtractive decode, so we
> think the bridge forwards more address space than it actually does.
> If we try to use that address space, the device will never see the
> accesses.  In config 3, this patch assumes there's no subtractive
> decode, so we would see Jeff's problem all over again.

Right, but OTOH:
  - multiple IOH has already been tested with the intel_bus.c code
  - we want to move to using _CRS data in these cases instead

So do you have any objection to applying this patch for 2.6.33 and then
moving away from intel_bus.c in .34 (assuming we can get _CRS working
well on the same machines where intel_bus.c was needed)?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Wednesday 27 January 2010 09:53:37 am Jesse Barnes wrote:
> On Wed, 27 Jan 2010 09:45:15 -0700
> Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org> wrote:
> 
> > On Tuesday 26 January 2010 03:57:31 pm Yinghai Lu wrote:
> > > [PATCH] x86/pci: don't use ioh resource if only have one ioh
> > > 
> > > some system could use reosurce out of IOH resources when only one ioh is there.
> > > 
> > > could be BIOS have wrong IOH resources and not enable them.
> > 
> > The subtractive decode theory makes sense and would explain what's
> > happening, but I don't like this patch.
> > 
> > If we assume that this really is a subtractive decode issue, this
> > patch approaches it the wrong way.  We need to know whether a
> > particular host bridge is configured for subtractive decode.  This
> > patch tests whether we have more than one host bridge, which is quite
> > a different question.
> > 
> > Imagine these system configurations:
> > 
> >   1) a single host bridge with subtractive decode
> >   2) a single host bridge with only positive decode
> >   3) multiple host bridges with subtractive decode enabled on one
> >   4) multiple host bridges with only positive decode
> > 
> > This patch will break if we encounter configs 2 or 3.  In config 2,
> > this patch assumes the bridge performs subtractive decode, so we
> > think the bridge forwards more address space than it actually does.
> > If we try to use that address space, the device will never see the
> > accesses.  In config 3, this patch assumes there's no subtractive
> > decode, so we would see Jeff's problem all over again.
> 
> Right, but OTOH:
>   - multiple IOH has already been tested with the intel_bus.c code
>   - we want to move to using _CRS data in these cases instead

> So do you have any objection to applying this patch for 2.6.33 and then
> moving away from intel_bus.c in .34 (assuming we can get _CRS working
> well on the same machines where intel_bus.c was needed)?

Without intel_bus.c, we essentially assume config 1 all the time.
If we keep intel_bus.c and this patch for .33, things should work
for configs 1 and 4.  Adding support for config 4 is good.

The bad part is that for config 4, intel_bus.c covers up any defects
in the _CRS or the Linux code that interprets it.  The reason Yinghai
added intel_bus.c in the first place was to work around a defect in
this area[1].  Keeping it will make it harder to fix the underlying
issue that keeps us from turning on _CRS for that box.

Bjorn

[1] http://lkml.org/lkml/2009/10/6/371

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Linus Torvalds]

On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
> 
> Without intel_bus.c, we essentially assume config 1 all the time.
> If we keep intel_bus.c and this patch for .33, things should work
> for configs 1 and 4.  Adding support for config 4 is good.

Quite frankly, is there any major downside to just disabling/removing 
intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
anyway - or even if we are, but we can't be really happy about the state 
of it as it would be in 2.6.33, not using it at all seems to be the 
smaller headache.

The machines that it helps are also the machines where you can fix things 
up with 'use_csr', no? And they are pretty rare, and they didn't use to 
work without that use_csr in 2.6.32 either, so it's not even a regression.

Am I missing something?

		Linus

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

> 
> 
> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
> > 
> > Without intel_bus.c, we essentially assume config 1 all the time.
> > If we keep intel_bus.c and this patch for .33, things should work
> > for configs 1 and 4.  Adding support for config 4 is good.
> 
> Quite frankly, is there any major downside to just disabling/removing 
> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
> anyway - or even if we are, but we can't be really happy about the state 
> of it as it would be in 2.6.33, not using it at all seems to be the 
> smaller headache.
> 
> The machines that it helps are also the machines where you can fix things 
> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
> work without that use_csr in 2.6.32 either, so it's not even a regression.
> 
> Am I missing something?

No that's the plan.  intel_bus.c was a good effort, but it's just too
different from what Windows does, and it'll always be behind.  We'll
disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but
fixing the problem with large numbers of _CRS resources this time).

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Wed, 27 Jan 2010 12:59:05 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > 
> > 
> > On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
> > > 
> > > Without intel_bus.c, we essentially assume config 1 all the time.
> > > If we keep intel_bus.c and this patch for .33, things should work
> > > for configs 1 and 4.  Adding support for config 4 is good.
> > 
> > Quite frankly, is there any major downside to just disabling/removing 
> > intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
> > anyway - or even if we are, but we can't be really happy about the state 
> > of it as it would be in 2.6.33, not using it at all seems to be the 
> > smaller headache.
> > 
> > The machines that it helps are also the machines where you can fix things 
> > up with 'use_csr', no? And they are pretty rare, and they didn't use to 
> > work without that use_csr in 2.6.32 either, so it's not even a regression.
> > 
> > Am I missing something?
> 
> No that's the plan.  intel_bus.c was a good effort, but it's just too
> different from what Windows does, and it'll always be behind.  We'll
> disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but
> fixing the problem with large numbers of _CRS resources this time).

Should say "disable it for 2.6.33 for all but multi-IOH configs", which
seem to be fairly rare anyway, and were what intel_bus.c was designed
to accommodate.  On the one machine that motivated it, use_crs was
broken (though it likely isn't now), so it seems the safest route.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/27/2010 01:02 PM, Jesse Barnes wrote:
> On Wed, 27 Jan 2010 12:59:05 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
>> On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>>>
>>>
>>> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
>>>>
>>>> Without intel_bus.c, we essentially assume config 1 all the time.
>>>> If we keep intel_bus.c and this patch for .33, things should work
>>>> for configs 1 and 4.  Adding support for config 4 is good.
>>>
>>> Quite frankly, is there any major downside to just disabling/removing 
>>> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
>>> anyway - or even if we are, but we can't be really happy about the state 
>>> of it as it would be in 2.6.33, not using it at all seems to be the 
>>> smaller headache.
>>>
>>> The machines that it helps are also the machines where you can fix things 
>>> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
>>> work without that use_csr in 2.6.32 either, so it's not even a regression.
>>>
>>> Am I missing something?
>>
>> No that's the plan.  intel_bus.c was a good effort, but it's just too
>> different from what Windows does, and it'll always be behind.  We'll
>> disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but
>> fixing the problem with large numbers of _CRS resources this time).
> 
> Should say "disable it for 2.6.33 for all but multi-IOH configs", which
> seem to be fairly rare anyway, and were what intel_bus.c was designed
> to accommodate.  On the one machine that motivated it, use_crs was
> broken (though it likely isn't now), so it seems the safest route.

will try to produce one patch to handle subtract decoding for legacy IOH aka the one with ESI.

the structure could be something like amd_bus.c, need to do it early, but it need after pci_arch_init to get mmconf.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
> 
> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
> > 
> > Without intel_bus.c, we essentially assume config 1 all the time.
> > If we keep intel_bus.c and this patch for .33, things should work
> > for configs 1 and 4.  Adding support for config 4 is good.
> 
> Quite frankly, is there any major downside to just disabling/removing 
> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
> anyway - or even if we are, but we can't be really happy about the state 
> of it as it would be in 2.6.33, not using it at all seems to be the 
> smaller headache.
> 
> The machines that it helps are also the machines where you can fix things 
> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
> work without that use_csr in 2.6.32 either, so it's not even a regression.
> 
> Am I missing something?

Only that when we added intel_bus.c, Yinghai reported that the reason
was because a machine had a broken _CRS, so "pci=use_crs" wouldn't help.

At the time, Windows hadn't been brought up on that box.  My
speculation is that by now, they've done that bringup and probably
fixed the _CRS issue, so it might work now.

If that's the case, we could drop intel_bus.c from .33 and just use
"pci=use_crs" on those boxes until we can figure out how to turn it
on automatically.

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
> On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
>>
>> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
>>>
>>> Without intel_bus.c, we essentially assume config 1 all the time.
>>> If we keep intel_bus.c and this patch for .33, things should work
>>> for configs 1 and 4.  Adding support for config 4 is good.
>>
>> Quite frankly, is there any major downside to just disabling/removing 
>> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
>> anyway - or even if we are, but we can't be really happy about the state 
>> of it as it would be in 2.6.33, not using it at all seems to be the 
>> smaller headache.
>>
>> The machines that it helps are also the machines where you can fix things 
>> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
>> work without that use_csr in 2.6.32 either, so it's not even a regression.
>>
>> Am I missing something?
> 
> Only that when we added intel_bus.c, Yinghai reported that the reason
> was because a machine had a broken _CRS, so "pci=use_crs" wouldn't help.
> 
> At the time, Windows hadn't been brought up on that box.  My
> speculation is that by now, they've done that bringup and probably
> fixed the _CRS issue, so it might work now.
> 
> If that's the case, we could drop intel_bus.c from .33 and just use
> "pci=use_crs" on those boxes until we can figure out how to turn it
> on automatically.

BIOS fixed that problem already. but
1. how to turn that pci=use_crs for that box automatically ?
how about our other kind of boxes?
2. how about when apci is disabled?

let's apply that patch at first, and wait for intel give us info about which bit is used to enable routing set up.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
> > On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
> >>
> >> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
> >>>
> >>> Without intel_bus.c, we essentially assume config 1 all the time.
> >>> If we keep intel_bus.c and this patch for .33, things should work
> >>> for configs 1 and 4.  Adding support for config 4 is good.
> >>
> >> Quite frankly, is there any major downside to just disabling/removing 
> >> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
> >> anyway - or even if we are, but we can't be really happy about the state 
> >> of it as it would be in 2.6.33, not using it at all seems to be the 
> >> smaller headache.
> >>
> >> The machines that it helps are also the machines where you can fix things 
> >> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
> >> work without that use_csr in 2.6.32 either, so it's not even a regression.
> >>
> >> Am I missing something?
> > 
> > Only that when we added intel_bus.c, Yinghai reported that the reason
> > was because a machine had a broken _CRS, so "pci=use_crs" wouldn't help.
> > 
> > At the time, Windows hadn't been brought up on that box.  My
> > speculation is that by now, they've done that bringup and probably
> > fixed the _CRS issue, so it might work now.
> > 
> > If that's the case, we could drop intel_bus.c from .33 and just use
> > "pci=use_crs" on those boxes until we can figure out how to turn it
> > on automatically.
> 
> BIOS fixed that problem already. but
> 1. how to turn that pci=use_crs for that box automatically ?
> how about our other kind of boxes?

Yes, we need a way to turn on "pci=use_crs" automatically.  My first
thought is to turn it on for all BIOSes with dates of 2010 or later, and
in addition, have a whitelist of the pre-2010 machines that require it.

> 2. how about when apci is disabled?

When ACPI is disabled, I think we just have to accept that we lose some
functionality.  I don't see the need for alternate ways to accomplish
everything that ACPI does.  It's becoming less and less useful to
disable ACPI; I think it's only interesting as a debugging tool, and
even then it's a sledgehammer.

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
>> On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
>>> On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
>>>>
>>>> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
>>>>>
>>>>> Without intel_bus.c, we essentially assume config 1 all the time.
>>>>> If we keep intel_bus.c and this patch for .33, things should work
>>>>> for configs 1 and 4.  Adding support for config 4 is good.
>>>>
>>>> Quite frankly, is there any major downside to just disabling/removing 
>>>> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
>>>> anyway - or even if we are, but we can't be really happy about the state 
>>>> of it as it would be in 2.6.33, not using it at all seems to be the 
>>>> smaller headache.
>>>>
>>>> The machines that it helps are also the machines where you can fix things 
>>>> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
>>>> work without that use_csr in 2.6.32 either, so it's not even a regression.
>>>>
>>>> Am I missing something?
>>>
>>> Only that when we added intel_bus.c, Yinghai reported that the reason
>>> was because a machine had a broken _CRS, so "pci=use_crs" wouldn't help.
>>>
>>> At the time, Windows hadn't been brought up on that box.  My
>>> speculation is that by now, they've done that bringup and probably
>>> fixed the _CRS issue, so it might work now.
>>>
>>> If that's the case, we could drop intel_bus.c from .33 and just use
>>> "pci=use_crs" on those boxes until we can figure out how to turn it
>>> on automatically.
>>
>> BIOS fixed that problem already. but
>> 1. how to turn that pci=use_crs for that box automatically ?
>> how about our other kind of boxes?
> 
> Yes, we need a way to turn on "pci=use_crs" automatically.  My first
> thought is to turn it on for all BIOSes with dates of 2010 or later, and
> in addition, have a whitelist of the pre-2010 machines that require it.
> 
>> 2. how about when apci is disabled?
> 
> When ACPI is disabled, I think we just have to accept that we lose some
> functionality.  I don't see the need for alternate ways to accomplish
> everything that ACPI does.  It's becoming less and less useful to
> disable ACPI; I think it's only interesting as a debugging tool, and
> even then it's a sledgehammer.

some systems when acpi is enabled could have interrupt storm. 
and have to disable acpi.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Thursday 28 January 2010, Yinghai Lu wrote:
> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> > On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> >> On 01/27/2010 01:03 PM, Bjorn Helgaas wrote:
> >>> On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds wrote:
> >>>>
> >>>> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
> >>>>>
> >>>>> Without intel_bus.c, we essentially assume config 1 all the time.
> >>>>> If we keep intel_bus.c and this patch for .33, things should work
> >>>>> for configs 1 and 4.  Adding support for config 4 is good.
> >>>>
> >>>> Quite frankly, is there any major downside to just disabling/removing 
> >>>> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
> >>>> anyway - or even if we are, but we can't be really happy about the state 
> >>>> of it as it would be in 2.6.33, not using it at all seems to be the 
> >>>> smaller headache.
> >>>>
> >>>> The machines that it helps are also the machines where you can fix things 
> >>>> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
> >>>> work without that use_csr in 2.6.32 either, so it's not even a regression.
> >>>>
> >>>> Am I missing something?
> >>>
> >>> Only that when we added intel_bus.c, Yinghai reported that the reason
> >>> was because a machine had a broken _CRS, so "pci=use_crs" wouldn't help.
> >>>
> >>> At the time, Windows hadn't been brought up on that box.  My
> >>> speculation is that by now, they've done that bringup and probably
> >>> fixed the _CRS issue, so it might work now.
> >>>
> >>> If that's the case, we could drop intel_bus.c from .33 and just use
> >>> "pci=use_crs" on those boxes until we can figure out how to turn it
> >>> on automatically.
> >>
> >> BIOS fixed that problem already. but
> >> 1. how to turn that pci=use_crs for that box automatically ?
> >> how about our other kind of boxes?
> > 
> > Yes, we need a way to turn on "pci=use_crs" automatically.  My first
> > thought is to turn it on for all BIOSes with dates of 2010 or later, and
> > in addition, have a whitelist of the pre-2010 machines that require it.
> > 
> >> 2. how about when apci is disabled?
> > 
> > When ACPI is disabled, I think we just have to accept that we lose some
> > functionality.  I don't see the need for alternate ways to accomplish
> > everything that ACPI does.  It's becoming less and less useful to
> > disable ACPI; I think it's only interesting as a debugging tool, and
> > even then it's a sledgehammer.
> 
> some systems when acpi is enabled could have interrupt storm. 
> and have to disable acpi.

Blacklist them?

Rafael

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> > On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:

> >> 2. how about when apci is disabled?
> > 
> > When ACPI is disabled, I think we just have to accept that we lose some
> > functionality.  I don't see the need for alternate ways to accomplish
> > everything that ACPI does.  It's becoming less and less useful to
> > disable ACPI; I think it's only interesting as a debugging tool, and
> > even then it's a sledgehammer.
> 
> some systems when acpi is enabled could have interrupt storm. 
> and have to disable acpi.

We should fix that problem rather than just covering it up by
disabling ACPI.  Can you provide any details?

I think it's crazy to add code to work around Problem B that only
occurs because we disabled ACPI to work around Problem A.  We should
just fix Problem A instead.

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
>> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
>>> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> 
>>>> 2. how about when apci is disabled?
>>>
>>> When ACPI is disabled, I think we just have to accept that we lose some
>>> functionality.  I don't see the need for alternate ways to accomplish
>>> everything that ACPI does.  It's becoming less and less useful to
>>> disable ACPI; I think it's only interesting as a debugging tool, and
>>> even then it's a sledgehammer.
>>
>> some systems when acpi is enabled could have interrupt storm. 
>> and have to disable acpi.
> 
> We should fix that problem rather than just covering it up by
> disabling ACPI.  Can you provide any details?
that is not covering problem. acpi just cause too many problems.

systems using acpi hotplug support, and use acpi aml code to monitor the hotplug status instead of HW
and after one or two days will have interrupt storm with sci/acpi interrupt aka 9.
> 
> I think it's crazy to add code to work around Problem B that only
> occurs because we disabled ACPI to work around Problem A.  We should
> just fix Problem A instead.

that is not point. fix BIOS or HW or OS?

check many systems have broken acpi?
some system acpi code even clear pci bar when just enable acpi at the first point.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Thu, 28 Jan 2010 10:20:04 -0800
Yinghai Lu <yinghai@kernel.org> wrote:

> On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> > On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> >> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> >>> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> > 
> >>>> 2. how about when apci is disabled?
> >>>
> >>> When ACPI is disabled, I think we just have to accept that we
> >>> lose some functionality.  I don't see the need for alternate ways
> >>> to accomplish everything that ACPI does.  It's becoming less and
> >>> less useful to disable ACPI; I think it's only interesting as a
> >>> debugging tool, and even then it's a sledgehammer.
> >>
> >> some systems when acpi is enabled could have interrupt storm. 
> >> and have to disable acpi.
> > 
> > We should fix that problem rather than just covering it up by
> > disabling ACPI.  Can you provide any details?
> that is not covering problem. acpi just cause too many problems.
> 
> systems using acpi hotplug support, and use acpi aml code to monitor
> the hotplug status instead of HW and after one or two days will have
> interrupt storm with sci/acpi interrupt aka 9.


But disabling it gets us into trouble too.  When platforms are designed
for Linux, they may be designed to have ACPI disabled (though this is
probably rare for general purpose PCs and servers).  However when
they're designed for Windows, they're generally designed to use ACPI,
so if we disable it we run the risk of hitting all sorts of bugs since
we're running in an untested configuration.

So fixing the issues with ACPI enabled seems like a better idea; after
all, presumably Windows works on this platform with ACPI enabled, why
shouldn't we?

But I'm speaking in general here; we'd have to dig into the details of
the particular problem you mention to figure out the best course of
action (but I'm still pretty sure it's not "disable ACPI").

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Rafael J. Wysocki]

On Thursday 28 January 2010, Jesse Barnes wrote:
> On Thu, 28 Jan 2010 10:20:04 -0800
> Yinghai Lu <yinghai@kernel.org> wrote:
> 
> > On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> > > On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> > >> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> > >>> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> > > 
> > >>>> 2. how about when apci is disabled?
> > >>>
> > >>> When ACPI is disabled, I think we just have to accept that we
> > >>> lose some functionality.  I don't see the need for alternate ways
> > >>> to accomplish everything that ACPI does.  It's becoming less and
> > >>> less useful to disable ACPI; I think it's only interesting as a
> > >>> debugging tool, and even then it's a sledgehammer.
> > >>
> > >> some systems when acpi is enabled could have interrupt storm. 
> > >> and have to disable acpi.
> > > 
> > > We should fix that problem rather than just covering it up by
> > > disabling ACPI.  Can you provide any details?
> > that is not covering problem. acpi just cause too many problems.
> > 
> > systems using acpi hotplug support, and use acpi aml code to monitor
> > the hotplug status instead of HW and after one or two days will have
> > interrupt storm with sci/acpi interrupt aka 9.
> 
> 
> But disabling it gets us into trouble too.  When platforms are designed
> for Linux, they may be designed to have ACPI disabled (though this is
> probably rare for general purpose PCs and servers).

Well, not quite.  On recent SMP systems it's next to impossible to get all of
the necessary system configuration information without ACPI, since it only is
provided by the ACPI tables (the configuration of APICs, interrupt routing,
CPU C states, other stuff).

[BTW, I think it's better to CC linux-acpi and Len at this point.]

> However when they're designed for Windows, they're generally designed to use
> ACPI, so if we disable it we run the risk of hitting all sorts of bugs since
> we're running in an untested configuration.

I guess without ACPI we're guaranteed to run into troubles on many modern
hardware configurations.

> So fixing the issues with ACPI enabled seems like a better idea; after
> all, presumably Windows works on this platform with ACPI enabled, why
> shouldn't we?
> 
> But I'm speaking in general here; we'd have to dig into the details of
> the particular problem you mention to figure out the best course of
> action (but I'm still pretty sure it's not "disable ACPI").

Agreed.

Rafael

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Thu, 28 Jan 2010 21:28:33 +0100
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > But disabling it gets us into trouble too.  When platforms are
> > designed for Linux, they may be designed to have ACPI disabled
> > (though this is probably rare for general purpose PCs and servers).
> 
> Well, not quite.  On recent SMP systems it's next to impossible to
> get all of the necessary system configuration information without
> ACPI, since it only is provided by the ACPI tables (the configuration
> of APICs, interrupt routing, CPU C states, other stuff).
> 
> [BTW, I think it's better to CC linux-acpi and Len at this point.]

I was thinking more of custom designed low power servers or something,
possibly running LinuxBIOS or some other custom BIOS.  For a general
purpose machine though I'm 100% agreed.  ACPI is required these days
for PCs.

I was trying to make a point that we shouldn't disable ACPI on
platforms that support it.  Rather, we should fix any bugs we discover
in handling ACPI correctly, rather than working around it by turning it
off.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Zhang Rui]

On Fri, 2010-01-29 at 04:28 +0800, Rafael J. Wysocki wrote:
> On Thursday 28 January 2010, Jesse Barnes wrote:
> > On Thu, 28 Jan 2010 10:20:04 -0800
> > Yinghai Lu <yinghai@kernel.org> wrote:
> > 
> > > On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> > > > On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> > > >> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> > > >>> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> > > > 
> > > >>>> 2. how about when apci is disabled?
> > > >>>
> > > >>> When ACPI is disabled, I think we just have to accept that we
> > > >>> lose some functionality.  I don't see the need for alternate ways
> > > >>> to accomplish everything that ACPI does.  It's becoming less and
> > > >>> less useful to disable ACPI; I think it's only interesting as a
> > > >>> debugging tool, and even then it's a sledgehammer.
> > > >>
> > > >> some systems when acpi is enabled could have interrupt storm. 
> > > >> and have to disable acpi.
> > > > 
> > > > We should fix that problem rather than just covering it up by
> > > > disabling ACPI.  Can you provide any details?
> > > that is not covering problem. acpi just cause too many problems.
> > > 
> > > systems using acpi hotplug support, and use acpi aml code to monitor
> > > the hotplug status instead of HW and after one or two days will have
> > > interrupt storm with sci/acpi interrupt aka 9.
> > 
> > 
> > But disabling it gets us into trouble too.  When platforms are designed
> > for Linux, they may be designed to have ACPI disabled (though this is
> > probably rare for general purpose PCs and servers).
> 
> Well, not quite.  On recent SMP systems it's next to impossible to get all of
> the necessary system configuration information without ACPI, since it only is
> provided by the ACPI tables (the configuration of APICs, interrupt routing,
> CPU C states, other stuff).
> 
> [BTW, I think it's better to CC linux-acpi and Len at this point.]
> 
IMO, Disabling ACPI is wrong.
"acpi=off" should just be used for debug purpose. For example, it is a
good excuse to dedicate an uncleared bug to ACPI if the problem doesn't
exist with acpi=off, although they may be not ACPI related sometime.

So if there are some platforms that
1. work in Windows.
2. don't work in Linux when ACPI is on.
3. work in Linux when ACPI is off.
please file a bug at
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI

thanks,
rui

> > However when they're designed for Windows, they're generally designed to use
> > ACPI, so if we disable it we run the risk of hitting all sorts of bugs since
> > we're running in an untested configuration.
> 
> I guess without ACPI we're guaranteed to run into troubles on many modern
> hardware configurations.
> 
> > So fixing the issues with ACPI enabled seems like a better idea; after
> > all, presumably Windows works on this platform with ACPI enabled, why
> > shouldn't we?
> > 
> > But I'm speaking in general here; we'd have to dig into the details of
> > the particular problem you mention to figure out the best course of
> > action (but I'm still pretty sure it's not "disable ACPI").
> 
> Agreed.
> 
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Thursday 28 January 2010 11:20:04 am Yinghai Lu wrote:
> On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> > On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> >> On 01/27/2010 08:26 PM, Bjorn Helgaas wrote:
> >>> On Wed, 2010-01-27 at 15:34 -0800, Yinghai Lu wrote:
> > 
> >>>> 2. how about when apci is disabled?
> >>>
> >>> When ACPI is disabled, I think we just have to accept that we lose some
> >>> functionality.  I don't see the need for alternate ways to accomplish
> >>> everything that ACPI does.  It's becoming less and less useful to
> >>> disable ACPI; I think it's only interesting as a debugging tool, and
> >>> even then it's a sledgehammer.
> >>
> >> some systems when acpi is enabled could have interrupt storm. 
> >> and have to disable acpi.
> > 
> > We should fix that problem rather than just covering it up by
> > disabling ACPI.  Can you provide any details?
> that is not covering problem. acpi just cause too many problems.
> 
> systems using acpi hotplug support, and use acpi aml code to monitor the hotplug status instead of HW
> and after one or two days will have interrupt storm with sci/acpi interrupt aka 9.

If you just want to whine about problems without helping us figure
them out and fix them, I think there's another mailing list for that.

I really don't have time to deal with unsubstantiated rumor-mongering
like this.

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Bjorn Helgaas]

On Thursday 28 January 2010 11:20:04 am Yinghai Lu wrote:
> On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
> > On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
> > We should fix that problem rather than just covering it up by
> > disabling ACPI.  Can you provide any details?
> that is not covering problem. acpi just cause too many problems.
> 
> systems using acpi hotplug support, and use acpi aml code to monitor the hotplug status instead of HW
> and after one or two days will have interrupt storm with sci/acpi interrupt aka 9.
> ...
> check many systems have broken acpi?
> some system acpi code even clear pci bar when just enable acpi at the first point.

Sorry, let me try to be more constructive.  You mention some things
above that might be issues with Linux.  I am eager to help fix them.

However, to make progress, I need information, not just rumors.  Can
you point me to bug reports?  Bugzillas?  Ways to reproduce the
problems?

Bjorn

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/28/2010 12:31 PM, Bjorn Helgaas wrote:
> On Thursday 28 January 2010 11:20:04 am Yinghai Lu wrote:
>> On 01/28/2010 08:09 AM, Bjorn Helgaas wrote:
>>> On Wednesday 27 January 2010 10:53:51 pm Yinghai Lu wrote:
>>> We should fix that problem rather than just covering it up by
>>> disabling ACPI.  Can you provide any details?
>> that is not covering problem. acpi just cause too many problems.
>>
>> systems using acpi hotplug support, and use acpi aml code to monitor the hotplug status instead of HW
>> and after one or two days will have interrupt storm with sci/acpi interrupt aka 9.
>> ...
>> check many systems have broken acpi?
>> some system acpi code even clear pci bar when just enable acpi at the first point.
> 
> Sorry, let me try to be more constructive.  You mention some things
> above that might be issues with Linux.  I am eager to help fix them.

should be have problem on several parties.
good hw design should let fgpa to monitor that change, instead of have bunch ACPI AML code
on host cpu to do that.

> 
> However, to make progress, I need information, not just rumors.  Can
> you point me to bug reports?  Bugzillas?  Ways to reproduce the
> problems?
I asked our HW engineer to update fpga to handle the problem already.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Matthew Garrett]

On Wed, Jan 27, 2010 at 09:26:02PM -0700, Bjorn Helgaas wrote:

> When ACPI is disabled, I think we just have to accept that we lose some
> functionality.  I don't see the need for alternate ways to accomplish
> everything that ACPI does.  It's becoming less and less useful to
> disable ACPI; I think it's only interesting as a debugging tool, and
> even then it's a sledgehammer.

I'd agree with this. The days where it was plausibly practical to boot 
non-ACPI operating systems on hardware are clearly gone, and people who 
are actually disabling ACPI in the field seem to be doing so in order to 
avoid other bugs - and we're failing to fix those bugs as a result.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Tue, 26 Jan 2010 14:57:31 -0800
Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> On 01/26/2010 10:17 AM, Jesse Barnes wrote:
> 
> > 
> > For 2.6.33 I'd like a minimal fix though, can you disable it for all
> > but the multi-IOH case perhaps?
> > 
> please check,
> 
> [PATCH] x86/pci: don't use ioh resource if only have one ioh
> 
> some system could use reosurce out of IOH resources when only one ioh is there.
> 
> could be BIOS have wrong IOH resources and not enable them.
> 
> Signed-off-by: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

I applied this one to my for-linus branch.  Jeff can you confirm it
works for you?  I'd like to push it to Linus tomorrow.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jeff Garrett]

On Wed, Jan 27, 2010 at 05:35:50PM -0800, Jesse Barnes wrote:
> On Tue, 26 Jan 2010 14:57:31 -0800
> Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 
> > On 01/26/2010 10:17 AM, Jesse Barnes wrote:
> > 
> > > 
> > > For 2.6.33 I'd like a minimal fix though, can you disable it for all
> > > but the multi-IOH case perhaps?
> > > 
> > please check,
> > 
> > [PATCH] x86/pci: don't use ioh resource if only have one ioh
> > 
> > some system could use reosurce out of IOH resources when only one ioh is there.
> > 
> > could be BIOS have wrong IOH resources and not enable them.
> > 
> > Signed-off-by: Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> 
> I applied this one to my for-linus branch.  Jeff can you confirm it
> works for you?  I'd like to push it to Linus tomorrow.
> 
> Thanks,

FWIW, works...

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Linus Torvalds]

On Tue, 26 Jan 2010, Yinghai Lu wrote:
> 
> [PATCH] x86/pci: don't use ioh resource if only have one ioh

Please, no.

This patch is too ugly to live.

And it's totally unacceptable to probe every single possible PCI device 
for something like this.

If we don't know enough about the hardware workings of those Intel bridges 
to know when they are active and how they decode things, then please let's 
just disable intel_bus.c entirely.

There's no excuse for hacky tests like this.

			Linus

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:

> 
> 
> On Tue, 26 Jan 2010, Yinghai Lu wrote:
> > 
> > [PATCH] x86/pci: don't use ioh resource if only have one ioh
> 
> Please, no.
> 
> This patch is too ugly to live.
> 
> And it's totally unacceptable to probe every single possible PCI device 
> for something like this.
> 
> If we don't know enough about the hardware workings of those Intel bridges 
> to know when they are active and how they decode things, then please let's 
> just disable intel_bus.c entirely.
> 
> There's no excuse for hacky tests like this.

Ok, we'll just kill it entirely then.  I'll send a patch tomorrow
unless Yinghai beats me to it.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jeff Garrett]

On Wed, Jan 27, 2010 at 07:24:09PM -0800, Jesse Barnes wrote:
> On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Tue, 26 Jan 2010, Yinghai Lu wrote:
> > > 
> > > [PATCH] x86/pci: don't use ioh resource if only have one ioh
> > 
> > Please, no.
> > 
> > This patch is too ugly to live.
> > 
> > And it's totally unacceptable to probe every single possible PCI device 
> > for something like this.
> > 
> > If we don't know enough about the hardware workings of those Intel bridges 
> > to know when they are active and how they decode things, then please let's 
> > just disable intel_bus.c entirely.
> > 
> > There's no excuse for hacky tests like this.
> 
> Ok, we'll just kill it entirely then.  I'll send a patch tomorrow
> unless Yinghai beats me to it.

What about something like this (works for me, without pci=use_crs)?

---
    Remove intel_bus.c Intel-specific PCI/IOH logic
    
    Signed-off-by: Jeff Garrett <jeff@jgarrett.org>
---
 arch/x86/pci/Makefile    |    2 +-
 arch/x86/pci/intel_bus.c |   94 ----------------------------------------------
 2 files changed, 1 insertions(+), 95 deletions(-)

diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile
index 564b008..39fba37 100644
--- a/arch/x86/pci/Makefile
+++ b/arch/x86/pci/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_X86_NUMAQ)		+= numaq_32.o
 
 obj-y				+= common.o early.o
 obj-y				+= amd_bus.o
-obj-$(CONFIG_X86_64)		+= bus_numa.o intel_bus.o
+obj-$(CONFIG_X86_64)		+= bus_numa.o
 
 ifeq ($(CONFIG_PCI_DEBUG),y)
 EXTRA_CFLAGS += -DDEBUG
diff --git a/arch/x86/pci/intel_bus.c b/arch/x86/pci/intel_bus.c
deleted file mode 100644
index f81a2fa..0000000
--- a/arch/x86/pci/intel_bus.c
+++ /dev/null
@@ -1,94 +0,0 @@
-/*
- * to read io range from IOH pci conf, need to do it after mmconfig is there
- */
-
-#include <linux/delay.h>
-#include <linux/dmi.h>
-#include <linux/pci.h>
-#include <linux/init.h>
-#include <asm/pci_x86.h>
-
-#include "bus_numa.h"
-
-static inline void print_ioh_resources(struct pci_root_info *info)
-{
-	int res_num;
-	int busnum;
-	int i;
-
-	printk(KERN_DEBUG "IOH bus: [%02x, %02x]\n",
-			info->bus_min, info->bus_max);
-	res_num = info->res_num;
-	busnum = info->bus_min;
-	for (i = 0; i < res_num; i++) {
-		struct resource *res;
-
-		res = &info->res[i];
-		printk(KERN_DEBUG "IOH bus: %02x index %x %s: [%llx, %llx]\n",
-			busnum, i,
-			(res->flags & IORESOURCE_IO) ? "io port" :
-							"mmio",
-			res->start, res->end);
-	}
-}
-
-#define IOH_LIO			0x108
-#define IOH_LMMIOL		0x10c
-#define IOH_LMMIOH		0x110
-#define IOH_LMMIOH_BASEU	0x114
-#define IOH_LMMIOH_LIMITU	0x118
-#define IOH_LCFGBUS		0x11c
-
-static void __devinit pci_root_bus_res(struct pci_dev *dev)
-{
-	u16 word;
-	u32 dword;
-	struct pci_root_info *info;
-	u16 io_base, io_end;
-	u32 mmiol_base, mmiol_end;
-	u64 mmioh_base, mmioh_end;
-	int bus_base, bus_end;
-
-	/* some sys doesn't get mmconf enabled */
-	if (dev->cfg_size < 0x120)
-		return;
-
-	if (pci_root_num >= PCI_ROOT_NR) {
-		printk(KERN_DEBUG "intel_bus.c: PCI_ROOT_NR is too small\n");
-		return;
-	}
-
-	info = &pci_root_info[pci_root_num];
-	pci_root_num++;
-
-	pci_read_config_word(dev, IOH_LCFGBUS, &word);
-	bus_base = (word & 0xff);
-	bus_end = (word & 0xff00) >> 8;
-	sprintf(info->name, "PCI Bus #%02x", bus_base);
-	info->bus_min = bus_base;
-	info->bus_max = bus_end;
-
-	pci_read_config_word(dev, IOH_LIO, &word);
-	io_base = (word & 0xf0) << (12 - 4);
-	io_end = (word & 0xf000) | 0xfff;
-	update_res(info, io_base, io_end, IORESOURCE_IO, 0);
-
-	pci_read_config_dword(dev, IOH_LMMIOL, &dword);
-	mmiol_base = (dword & 0xff00) << (24 - 8);
-	mmiol_end = (dword & 0xff000000) | 0xffffff;
-	update_res(info, mmiol_base, mmiol_end, IORESOURCE_MEM, 0);
-
-	pci_read_config_dword(dev, IOH_LMMIOH, &dword);
-	mmioh_base = ((u64)(dword & 0xfc00)) << (26 - 10);
-	mmioh_end = ((u64)(dword & 0xfc000000) | 0x3ffffff);
-	pci_read_config_dword(dev, IOH_LMMIOH_BASEU, &dword);
-	mmioh_base |= ((u64)(dword & 0x7ffff)) << 32;
-	pci_read_config_dword(dev, IOH_LMMIOH_LIMITU, &dword);
-	mmioh_end |= ((u64)(dword & 0x7ffff)) << 32;
-	update_res(info, mmioh_base, mmioh_end, IORESOURCE_MEM, 0);
-
-	print_ioh_resources(info);
-}
-
-/* intel IOH */
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, pci_root_bus_res);

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Wed, 27 Jan 2010 22:02:26 -0600
jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org (Jeff Garrett) wrote:

> On Wed, Jan 27, 2010 at 07:24:09PM -0800, Jesse Barnes wrote:
> > On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
> > Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > > On Tue, 26 Jan 2010, Yinghai Lu wrote:
> > > > 
> > > > [PATCH] x86/pci: don't use ioh resource if only have one ioh
> > > 
> > > Please, no.
> > > 
> > > This patch is too ugly to live.
> > > 
> > > And it's totally unacceptable to probe every single possible PCI device 
> > > for something like this.
> > > 
> > > If we don't know enough about the hardware workings of those Intel bridges 
> > > to know when they are active and how they decode things, then please let's 
> > > just disable intel_bus.c entirely.
> > > 
> > > There's no excuse for hacky tests like this.
> > 
> > Ok, we'll just kill it entirely then.  I'll send a patch tomorrow
> > unless Yinghai beats me to it.
> 
> What about something like this (works for me, without pci=use_crs)?
> 
> ---
>     Remove intel_bus.c Intel-specific PCI/IOH logic
>     
>     Signed-off-by: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>

Yeah, looks good.  I'll push to Linus today.

Thanks,
Jesse

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/28/2010 08:24 AM, Jesse Barnes wrote:
> On Wed, 27 Jan 2010 22:02:26 -0600
> jeff@jgarrett.org (Jeff Garrett) wrote:
> 
>> On Wed, Jan 27, 2010 at 07:24:09PM -0800, Jesse Barnes wrote:
>>> On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
>>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>> On Tue, 26 Jan 2010, Yinghai Lu wrote:
>>>>>
>>>>> [PATCH] x86/pci: don't use ioh resource if only have one ioh
>>>>
>>>> Please, no.
>>>>
>>>> This patch is too ugly to live.
>>>>
>>>> And it's totally unacceptable to probe every single possible PCI device 
>>>> for something like this.
>>>>
>>>> If we don't know enough about the hardware workings of those Intel bridges 
>>>> to know when they are active and how they decode things, then please let's 
>>>> just disable intel_bus.c entirely.
>>>>
>>>> There's no excuse for hacky tests like this.
>>>
>>> Ok, we'll just kill it entirely then.  I'll send a patch tomorrow
>>> unless Yinghai beats me to it.
>>
>> What about something like this (works for me, without pci=use_crs)?
>>
>> ---
>>     Remove intel_bus.c Intel-specific PCI/IOH logic
>>     
>>     Signed-off-by: Jeff Garrett <jeff@jgarrett.org>
> 
> Yeah, looks good.  I'll push to Linus today.
> 

please don't. will send you another patch, to keep the print out so we can cross check the _CRS.

YH

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Thu, 28 Jan 2010 10:13:26 -0800
Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> On 01/28/2010 08:24 AM, Jesse Barnes wrote:
> > On Wed, 27 Jan 2010 22:02:26 -0600
> > jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org (Jeff Garrett) wrote:
> > 
> >> On Wed, Jan 27, 2010 at 07:24:09PM -0800, Jesse Barnes wrote:
> >>> On Wed, 27 Jan 2010 17:50:17 -0800 (PST)
> >>> Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> >>>> On Tue, 26 Jan 2010, Yinghai Lu wrote:
> >>>>>
> >>>>> [PATCH] x86/pci: don't use ioh resource if only have one ioh
> >>>>
> >>>> Please, no.
> >>>>
> >>>> This patch is too ugly to live.
> >>>>
> >>>> And it's totally unacceptable to probe every single possible PCI
> >>>> device for something like this.
> >>>>
> >>>> If we don't know enough about the hardware workings of those
> >>>> Intel bridges to know when they are active and how they decode
> >>>> things, then please let's just disable intel_bus.c entirely.
> >>>>
> >>>> There's no excuse for hacky tests like this.
> >>>
> >>> Ok, we'll just kill it entirely then.  I'll send a patch tomorrow
> >>> unless Yinghai beats me to it.
> >>
> >> What about something like this (works for me, without pci=use_crs)?
> >>
> >> ---
> >>     Remove intel_bus.c Intel-specific PCI/IOH logic
> >>     
> >>     Signed-off-by: Jeff Garrett <jeff-184d8XiO+QJg9hUCZPvPmw@public.gmane.org>
> > 
> > Yeah, looks good.  I'll push to Linus today.
> > 
> 
> please don't. will send you another patch, to keep the print out so
> we can cross check the _CRS.

I don't think there's much point due to the points we discussed
earlier, I'd rather just get rid of it.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Linus Torvalds]

On Tue, 26 Jan 2010, Rafael J. Wysocki wrote:
> 
> Perhaps it would be sufficient to make pci=use_crs the default and leave the
> option to use intel_bus.c for whoever needs that?

Well, 'use_crs' broke other machines. See:

	http://lkml.org/lkml/2009/6/23/715

but maybe that is all fixed..

		Linus

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Linus Torvalds]

On Tue, 26 Jan 2010, Bjorn Helgaas wrote:
> 
> which IS big enough, and we know the bridge is in fact forwarding the
> [mem 0xd0000000-0xdfffffff 64bit pref] region, because the Radeon works
> when Jeff boots with "pci=use_crs".

I bet it's a subtractive decode thing. Sure, it could be just another 
undocumented range register (does anybody have the datasheet for that 
thing?) but Intel tends to often have subtractive decode.

That system in question has three PCI express root ports, but two of them 
have IO and memory disabled according to the lspci info. So maybe it's as 
simple as that "I/O Hub PCI Express Root Port 7" just catching anything 
that nobody else does, and the single IOH host chip doing the same?

> I think we should remove intel_bus.c before .33.  It's breaking boxes
> and we don't know how to fix it.  Even if we do find out how to fix it,
> I think we should move toward using _CRS instead, because that's what
> Windows uses and it's an easy way for the firmware to tell us about
> platform quirks.

I suspect that for 33 it is indeed best to just revert. But somebody is 
bound to have information on how the actual hardware works. Yinghai?

		Linus

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/26/2010 10:16 AM, Linus Torvalds wrote:
> 
> 
> On Tue, 26 Jan 2010, Bjorn Helgaas wrote:
>>
>> which IS big enough, and we know the bridge is in fact forwarding the
>> [mem 0xd0000000-0xdfffffff 64bit pref] region, because the Radeon works
>> when Jeff boots with "pci=use_crs".
> 
> I bet it's a subtractive decode thing. Sure, it could be just another 
> undocumented range register (does anybody have the datasheet for that 
> thing?) but Intel tends to often have subtractive decode.
> 
> That system in question has three PCI express root ports, but two of them 
> have IO and memory disabled according to the lspci info. So maybe it's as 
> simple as that "I/O Hub PCI Express Root Port 7" just catching anything 
> that nobody else does, and the single IOH host chip doing the same?
> 
>> I think we should remove intel_bus.c before .33.  It's breaking boxes
>> and we don't know how to fix it.  Even if we do find out how to fix it,
>> I think we should move toward using _CRS instead, because that's what
>> Windows uses and it's an easy way for the firmware to tell us about
>> platform quirks.
> 
> I suspect that for 33 it is indeed best to just revert. But somebody is 
> bound to have information on how the actual hardware works. Yinghai?

I have asked intel if there is any bit that could be enabled the routing.
there is no info about for their documentations.

Yinghai

Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Jesse Barnes]

On Tue, 26 Jan 2010 10:21:29 -0800
Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> On 01/26/2010 10:16 AM, Linus Torvalds wrote:
> > 
> > 
> > On Tue, 26 Jan 2010, Bjorn Helgaas wrote:
> >>
> >> which IS big enough, and we know the bridge is in fact forwarding the
> >> [mem 0xd0000000-0xdfffffff 64bit pref] region, because the Radeon works
> >> when Jeff boots with "pci=use_crs".
> > 
> > I bet it's a subtractive decode thing. Sure, it could be just another 
> > undocumented range register (does anybody have the datasheet for that 
> > thing?) but Intel tends to often have subtractive decode.
> > 
> > That system in question has three PCI express root ports, but two of them 
> > have IO and memory disabled according to the lspci info. So maybe it's as 
> > simple as that "I/O Hub PCI Express Root Port 7" just catching anything 
> > that nobody else does, and the single IOH host chip doing the same?
> > 
> >> I think we should remove intel_bus.c before .33.  It's breaking boxes
> >> and we don't know how to fix it.  Even if we do find out how to fix it,
> >> I think we should move toward using _CRS instead, because that's what
> >> Windows uses and it's an easy way for the firmware to tell us about
> >> platform quirks.
> > 
> > I suspect that for 33 it is indeed best to just revert. But somebody is 
> > bound to have information on how the actual hardware works. Yinghai?
> 
> I have asked intel if there is any bit that could be enabled the routing.
> there is no info about for their documentations.

I could probably dig something up in our confidential database, but this
is the main problem with intel_bus.c.  It'll always be behind with _CRS
provides.  Sure _CRS may be wrong sometimes, but it'll always work well
enough to bring Windows up, so we ought not to ignore it.

The underlying problems with our _CRS support still aren't fixed
though, so switching that on for 2.6.33 isn't an option.

-- 
Jesse Barnes, Intel Open Source Technology Center