2.6.33-rc5: Reported regressions from 2.6.32

This message has been generated automatically 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 <[email protected]>
Date : 2009-12-12 13:06 (44 days old)

Handled-By Ben Hutchings <[email protected]>

Patch : http://patchwork.kernel.org/patch/72073/

Quoted 8 lines · 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).

Quoted 6 lines

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 <[email protected]>
Date : 2009-12-12 13:06 (44 days old)

Handled-By Ben Hutchings <ben-/[email protected]>

Patch : http://patchwork.kernel.org/patch/72073/

This should still be listed; I am still waiting for someone to test the proposed patch.

This message has been generated automatically 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=14946
Subject : All kernels after 2.6.32-git10 show only 1 CPU
Submitter : Sid Boyce <[email protected]>
Date : 2009-12-23 16:55 (33 days old)
References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4

Quoted 8 lines · 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).

Quoted 8 lines

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 <[email protected]>
Date : 2009-12-23 16:55 (33 days old)
References : http://marc.info/?l=linux-kernel&m=126158734326801&w=4

Definitely fixed in 2.6.33-rc4, thanks.

This message has been generated automatically 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/[email protected]>
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 <[email protected]>

Patch : http://patchwork.kernel.org/patch/70461/

This message has been generated automatically 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=14924
Subject : Weird hard hangs when rendering 'some' web-sites in Firefox
Submitter : David <[email protected]>
Date : 2009-12-21 21:53 (35 days old)
References : http://marc.info/?l=linux-kernel&m=126143375823340&w=4

Quoted 7 lines · 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

Quoted 9 lines

(either way).

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

Hmm, you have CONFIG_DETECT_SOFTLOCKUP=y, I have no idea what happened, doing a bisect would be appreciated.

Thanks.

Quoted 19 lines · Américo Wang

Quoted 7 lines · 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

Quoted 9 lines

(either way).

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

Quoted 6 lines

Hmm, you have CONFIG_DETECT_SOFTLOCKUP=y, I have no idea what happened, doing a bisect would be appreciated.

Thanks.

I no longer have the offending hardware, but I think that the issue was probably corrected by:

    cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd -

drm/radeon/kms: Schedule host path read cache flush through the ring V2

as the offending ATI graphics was indeed R300.

Quoted 19 lines · Américo Wang

Quoted 7 lines · 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

Quoted 9 lines

(either way).

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

Quoted 6 lines

Hmm, you have CONFIG_DETECT_SOFTLOCKUP=y, I have no idea what happened, doing a bisect would be appreciated.

Thanks.

I no longer have the offending hardware, but I think that the issue was probably corrected by:

   cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd - drm/radeon/kms: Schedule host path read cache flush through the ring V2

as the offending ATI graphics was indeed R300.

This message has been generated automatically 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=14859
Subject : System timer firing too much without cause
Submitter : Shawn Starr <[email protected]>
Date : 2009-12-21 19:16 (35 days old)

Quoted 8 lines · On Sunday 24 January 2010 17:04:33 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).

Quoted 4 lines

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

Continues with -rc5, I really cannot use Dynamic ticks at all, it has to be disabled.

I should probably mention this CPU info:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
stepping : 10
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm

constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida tpr_shadow vnmi flexpriority
bogomips : 5053.40
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Quoted 6 lines · On Sunday 24 January 2010 17:04:33 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).

As a comparsion my quad core box has no such issue: (Running 2.6.32-rc7) x86_64
0: 42 4 1 1 IO-APIC-edge timer

my Lenovo ThinkPad W500 (latest BIOS 3.11) laptop shows the system timer flooding the bus (Running 2.6.33-rc1) x86_64
0: 66775 70429 IO-APIC-edge timer <-- keeps rising, rapidly

Quoted 4 lines

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

Continues with -rc5, I really cannot use Dynamic ticks at all, it has to be disabled.

Quoted 7 lines · Shawn Starr

Quoted 6 lines · On Sunday 24 January 2010 17:04:33 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).

Why is this on the regression list at all ? The report says that this is happening with 33-rcX, but there is no comparison to the behaviour of 32 or earlier kernels on that machine. Instead we have a comparison

of apples and oranges:

Quoted 11 lines

As a comparsion my quad core box has no such issue: (Running 2.6.32-rc7) x86_64

0: 42 4 1 1 IO-APIC-edge
timer

my Lenovo ThinkPad W500 (latest BIOS 3.11) laptop shows the system timer flooding the bus (Running 2.6.33-rc1) x86_64

0: 66775 70429 IO-APIC-edge timer <-- keeps rising,
rapidly

So we look at a quad core desktop machine which probably has no deeper power states and therefor does not use the broadcast timer and compare it to a laptop which has deeper power states and needs to use the broadcast timer, which of course increases the number of IRQ0 events. What a surprise.

Can we please remove this from the regression list unless Shawn confirms that 32 or earlier kernels do not show that behaviour on the laptop?

Quoted 5 lines

Quoted 4 lines

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

Quoted 2 lines

Continues with -rc5, I really cannot use Dynamic ticks at all, it has to be disabled.

Shawn, why can't you use dynamic ticks ? In the bugzilla I just see that you worry about the IRQ0 interrupts (which are correct and necessary when the system is in nohz mode) and the extra rescheduling interrupts. How is the system misbehaving ?

Thanks,

tglx

Quoted 5 lines · On Monday 25 January 2010 05:35:50 Thomas Gleixner wrote:

Shawn, why can't you use dynamic ticks ? In the bugzilla I just see that you worry about the IRQ0 interrupts (which are correct and necessary when the system is in nohz mode) and the extra rescheduling interrupts. How is the system misbehaving ?

Well, this all stems from trying to use Radeon KMS with IRQs on. Doing so I see system stalls and this is quite noticeable however, I am able to show this same stall on the quad core with the

irq issue or a bug in the radeon driver code that is showing these stalls. Since the radeon folks - at the moment - do not think it is a coding problem in their driver

My impression was using dynamic ticks meant ticks were on demand and

not continuous. On the quad core box, with dynamic ticks on, the broadcasts are not increasing IRQ 0 events this only happens on the laptop.

Quoted 9 lines · Shawn Starr

Quoted 4 lines · On Monday 25 January 2010 05:35:50 Thomas Gleixner wrote:

Shawn, why can't you use dynamic ticks ? In the bugzilla I just see that you worry about the IRQ0 interrupts (which are correct and necessary when the system is in nohz mode) and the extra rescheduling interrupts. How is the system misbehaving ?

Well, this all stems from trying to use Radeon KMS with IRQs on. Doing so I see system stalls and this is quite noticeable however, I am able to show this same stall on the quad core with the

x> same GPU. Right now, it is unclear to me if there is a underlying

Quoted 3 lines

irq issue or a bug in the radeon driver code that is showing these stalls. Since the radeon folks - at the moment - do not think it is a coding problem in their driver

Does the stall go away, when you disable dynticks ?

Quoted 1 line

My impression was using dynamic ticks meant ticks were on demand and

Dynamic ticks are providing a continuous tick long as the machine is busy. When a core becomes idle, we programm the timer to go off at the next scheduled timer event, if the event is longer away than the next tick. When the core goes out of idle (due to the timer or some other event) we restart the tick.

So you see less timer interrupts (IRQ0 + Local timer interrupts)

Quoted 4 lines

not continuous. On the quad core box, with dynamic ticks on, the broadcasts are not increasing IRQ 0 events this only happens on the laptop.

Right, that is expected as I explained already. Your desktop does not use deeper power states. Check /proc/acpi/processor/CPU0/power on both machines to see the difference. You _cannot_ compare a desktop and a laptop machine and deduce a regression.

The broadcast mechanism is necessary because the local APIC timer stops in deeper power states. That's a hardware problem. So if the core goes into a deeper power state then we arm the broadcast timer which fires on IRQ0 to wake us up. It is a single timer which is used by all cores in a system to work around this hardware stupidity. It's named broadcast because it broadcasts the event to the other cores when necessary. Your desktop does not use deeper power states, therefor it does not use the broadcast timer either.

So the timer IRQ0 increasing is neither a Linux BUG nor a regression.

Thanks,

tglx

Quoted 11 lines · On Monday 25 January 2010 12:20:38 Thomas Gleixner wrote:

Quoted 9 lines · Shawn Starr

Quoted 4 lines · On Monday 25 January 2010 05:35:50 Thomas Gleixner wrote:

Shawn, why can't you use dynamic ticks ? In the bugzilla I just see that you worry about the IRQ0 interrupts (which are correct and necessary when the system is in nohz mode) and the extra rescheduling interrupts. How is the system misbehaving ?

Well, this all stems from trying to use Radeon KMS with IRQs on. Doing so I see system stalls and this is quite noticeable however, I am able to show this same stall on the quad core with the

Quoted 8 lines

x> same GPU. Right now, it is unclear to me if there is a underlying

Quoted 3 lines

irq issue or a bug in the radeon driver code that is showing these stalls. Since the radeon folks - at the moment - do not think it is a coding problem in their driver

Does the stall go away, when you disable dynticks ?

It does not, no.

Quoted 9 lines

Quoted 1 line

My impression was using dynamic ticks meant ticks were on demand and

Dynamic ticks are providing a continuous tick long as the machine is busy. When a core becomes idle, we programm the timer to go off at the next scheduled timer event, if the event is longer away than the next tick. When the core goes out of idle (due to the timer or some other event) we restart the tick.

So you see less timer interrupts (IRQ0 + Local timer interrupts)

With dynamic ticks on or off, LOC increments rapidly, but I assume that is normal behavour.

So if none of this really is a kernel issue, I defer it to the radeon folks to comment further.

Please remove from regression list, I'll close the original bug.

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

Quoted 3 lines · Rafael J. Wysocki

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

I'm not using 2.6.33 anymore since this bug is a showstopper to me (it's on a production system), so I'm unable to check if it's fixed or not.

This message has been generated automatically 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=15017
Subject         : kexec regression, radeon/kms irq related (bisected)
Submitter       : Markus Trippelsdorf <[email protected]>
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

Quoted 8 lines · 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).

Quoted 8 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15017
Subject : kexec regression, radeon/kms irq related (bisected)
Submitter : Markus Trippelsdorf <[email protected]>
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

That bug has patches which fix the issue attached and queued for 2.6.33.

This message has been generated automatically 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=15038
Subject : drm/ksm: fbdev blanking regression
Submitter : Johan Hovold <[email protected]>
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 <[email protected]>

Quoted 8 lines · 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).

Quoted 7 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15038
Subject : drm/ksm: fbdev blanking regression
Submitter : Johan Hovold <[email protected]>
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 <[email protected]>

Issue remains in rc5.

Quoted 17 lines · Johan Hovold

Quoted 15 lines · 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=15038
Subject : drm/ksm: fbdev blanking regression
Submitter : Johan Hovold <[email protected]>
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 <[email protected]>

Quoted 1 line

Issue remains in rc5.

Thanks for the update.

OK, we know what commit broke things, we don't seem to know how to fix it, so perhaps it's time to revert that commit?

Quoted 18 lines · Rafael J. Wysocki

Quoted 17 lines · Johan Hovold

Quoted 15 lines · 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=15038
Subject : drm/ksm: fbdev blanking regression
Submitter : Johan Hovold <[email protected]>
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 <[email protected]>

Quoted 6 lines

Quoted 1 line

Issue remains in rc5.

Thanks for the update.

OK, we know what commit broke things, we don't seem to know how to fix it, so perhaps it's time to revert that commit?

Just sent revert of the broken bit to Linus.

This message has been generated automatically 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
Submitter : Soeren Sonnenburg <[email protected]>
Date : 2010-01-10 20:09 (15 days old)
References : http://marc.info/?l=linux-kernel&m=126315457519505&w=4

Quoted 8 lines · On Sun, 24 Jan 2010 23:04:37 +0100 (CET) "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).

Quoted 5 lines

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

If this isn't fixed yet, I hope David's patch fixes it. See "[Bug #14897] i915: Commit 0e442c60 causes flickering".

Quoted 8 lines · On Sun, 24 Jan 2010 23:04:37 +0100 (CET) "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).

Quoted 5 lines

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

If this isn't fixed yet, I hope David's patch fixes it. See "[Bug #14897] i915: Commit 0e442c60 causes flickering".

This message has been generated automatically 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<[email protected]>
Date : 2010-01-10 21:47 (15 days old)
References : http://marc.info/?l=linux-kernel&m=126316012025978&w=4

Quoted 8 lines · 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).

Quoted 7 lines

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

Not an easy one to recreate. Should probably remain listed for now.

Quoted 18 lines · Michael Breuer

Quoted 16 lines · 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<[email protected]>
Date : 2010-01-10 21:47 (15 days old)
References : http://marc.info/?l=linux-kernel&m=126316012025978&w=4

Quoted 2 lines

Not an easy one to recreate. Should probably remain listed for now.

Thanks for the update.

Rafael

This message has been generated automatically 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 <[email protected]>
Date : 2010-01-13 5:37 (12 days old)
References : http://marc.info/?l=linux-kernel&m=126336296600307&w=4

Handled-By Yinghai Lu <[email protected]>

Bjorn Helgaas <[email protected]>

Quoted 8 lines · 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).

Quoted 7 lines

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 <[email protected]>
Date : 2010-01-13 5:37 (12 days old)
References : http://marc.info/?l=linux-kernel&m=126336296600307&w=4

Handled-By Yinghai Lu <[email protected]>

Bjorn Helgaas <[email protected]>

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

Quoted 13 lines · Jeff Garrett

Quoted 11 lines · Rafael J. Wysocki

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 <[email protected]>
Date : 2010-01-13 5:37 (12 days old)
References : http://marc.info/?l=linux-kernel&m=126336296600307&w=4

Handled-By Yinghai Lu <[email protected]>

Bjorn Helgaas <[email protected]>

Quoted 1 line

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

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

Quoted 14 lines · Rafael J. Wysocki

Quoted 13 lines · Jeff Garrett

Quoted 11 lines · Rafael J. Wysocki

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 <[email protected]>
Date : 2010-01-13 5:37 (12 days old)
References : http://marc.info/?l=linux-kernel&m=126336296600307&w=4

Handled-By Yinghai Lu <[email protected]>

Bjorn Helgaas <[email protected]>

Quoted 3 lines

Quoted 1 line

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.

Quoted 10 lines

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.

Quoted 5 lines

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?

Quoted 10 lines · On Tue, 26 Jan 2010 19:02:13 +0100 "Rafael J. Wysocki" <[email protected]> wrote:

Quoted 10 lines

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.

Quoted 8 lines

Quoted 5 lines

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?

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

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

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

Index: linux-2.6/arch/x86/pci/intel_bus.c
===================================================================

arch/x86/pci/intel_bus.c +86 -0

@@ -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);
+

Quoted 5 lines · Yinghai Lu

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

Quoted 23 lines · On Wed, 27 Jan 2010 09:45:15 -0700 Bjorn Helgaas…

Quoted 5 lines · Yinghai Lu

[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

Quoted 6 lines

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.

Quoted 4 lines · Bjorn Helgaas

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?

Quoted 18 lines · On Wed, 27 Jan 2010 12:50:12 -0800 (PST) Linus Torvalds…

Quoted 4 lines · Bjorn Helgaas

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.

Quoted 1 line

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

Quoted 21 lines · On Wed, 27 Jan 2010 12:59:05 -0800 Jesse Barnes <[email protected]>…

Quoted 18 lines · On Wed, 27 Jan 2010 12:50:12 -0800 (PST) Linus Torvalds…

Quoted 4 lines · Bjorn Helgaas

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 4 lines · Bjorn Helgaas

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?

Quoted 13 lines · Linus Torvalds

Quoted 4 lines · Bjorn Helgaas

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.

Quoted 5 lines

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.

Quoted 27 lines · Bjorn Helgaas

Quoted 13 lines · Linus Torvalds

Quoted 4 lines · Bjorn Helgaas

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.

Quoted 5 lines

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.

Quoted 3 lines

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?

Quoted 28 lines · Yinghai Lu

Quoted 27 lines · Bjorn Helgaas

Quoted 13 lines · Linus Torvalds

Quoted 4 lines · Bjorn Helgaas

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.

Quoted 5 lines

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 43 lines · Bjorn Helgaas

Quoted 28 lines · Yinghai Lu

Quoted 27 lines · Bjorn Helgaas

Quoted 13 lines · Linus Torvalds

Quoted 4 lines · Bjorn Helgaas

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.

Quoted 5 lines

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

2. how about when apci is disabled?

Quoted 5 lines

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.

Quoted 4 lines · Bjorn Helgaas

Quoted 1 line · Yinghai Lu

2. how about when apci is disabled?

Quoted 5 lines

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.

Quoted 11 lines · Yinghai Lu

Quoted 9 lines · Bjorn Helgaas

Quoted 1 line · Yinghai Lu

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.

Quoted 2 lines

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.

Quoted 15 lines · Bjorn Helgaas

Quoted 13 lines · Yinghai Lu

Quoted 9 lines · Bjorn Helgaas

Quoted 1 line · Yinghai Lu

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.

Quoted 2 lines

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.

Quoted 20 lines · On Thu, 28 Jan 2010 10:20:04 -0800 Yinghai Lu <[email protected]> wrote:

Quoted 12 lines · Bjorn Helgaas

Quoted 11 lines · Yinghai Lu

Quoted 9 lines · Bjorn Helgaas

Quoted 1 line · Yinghai Lu

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 3 lines

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

Quoted 3 lines

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

Quoted 23 lines · Jesse Barnes

Quoted 20 lines · On Thu, 28 Jan 2010 10:20:04 -0800 Yinghai Lu <[email protected]> wrote:

Quoted 12 lines · Bjorn Helgaas

Quoted 11 lines · Yinghai Lu

Quoted 9 lines · Bjorn Helgaas

Quoted 1 line · Yinghai Lu

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

Quoted 3 lines

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

Quoted 3 lines

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.

Quoted 7 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 15 lines · Bjorn Helgaas

Quoted 13 lines · Yinghai Lu

Quoted 9 lines · Bjorn Helgaas

Quoted 1 line · Yinghai Lu

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.

Quoted 2 lines

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.

Quoted 3 lines · Bjorn Helgaas

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.

Quoted 6 lines · Yinghai Lu

Quoted 3 lines · Bjorn Helgaas

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.

Quoted 5 lines

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?

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.

Quoted 4 lines · Jesse Barnes

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

Quoted 12 lines · On Tue, 26 Jan 2010 14:57:31 -0800 Yinghai Lu…

Quoted 4 lines · Jesse Barnes

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.

Quoted 3 lines

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

Signed-off-by Yinghai Lu <[email protected]>

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,

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

Quoted 2 lines · Yinghai Lu

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

Quoted 11 lines · On Wed, 27 Jan 2010 17:50:17 -0800 (PST) Linus Torvalds…

Quoted 2 lines · Yinghai Lu

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

Quoted 5 lines

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.

Quoted 13 lines · Jesse Barnes

Quoted 11 lines · On Wed, 27 Jan 2010 17:50:17 -0800 (PST) Linus Torvalds…

Quoted 2 lines · Yinghai Lu

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

Quoted 8 lines

Quoted 5 lines

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

Quoted 23 lines · On Wed, 27 Jan 2010 22:02:26 -0600 [email protected] (Jeff Garrett) wrote:

Quoted 21 lines · Jesse Barnes

Quoted 8 lines · On Wed, 27 Jan 2010 17:50:17 -0800 (PST) Linus Torvalds…

Quoted 2 lines · Yinghai Lu

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

Please, no.

This patch is too ugly to live.

Quoted 8 lines

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.

Quoted 6 lines

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

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

Quoted 31 lines · Jesse Barnes

Quoted 28 lines · On Wed, 27 Jan 2010 22:02:26 -0600 [email protected]…

Quoted 13 lines · Jesse Barnes

Quoted 11 lines · On Wed, 27 Jan 2010 17:50:17 -0800 (PST) Linus Torvalds…

Quoted 2 lines · Yinghai Lu

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

Quoted 8 lines

Quoted 5 lines

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

Quoted 4 lines

Quoted 1 line

Signed-off-by Jeff Garrett <[email protected]>

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.

don't use them for peer pci root bus resource yet. so could cross check _CRS results

-v2: dont put info struct in stack according to Linus.
because that is kbytes big

Quoted 6 lines · Yinghai Lu

don't use them for peer pci root bus resource yet. so could cross check _CRS results

-v2: dont put info struct in stack according to Linus.
because that is kbytes big

No kfree?

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?

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

Quoted 4 lines · Bjorn Helgaas

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?

Quoted 5 lines

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?

Quoted 23 lines · Linus Torvalds

Quoted 4 lines · Bjorn Helgaas

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?

Quoted 5 lines

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.

Quoted 2 lines

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.

This message has been generated automatically 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=15126
Subject : REGRESSION for RT2561/RT61 in 2.6.33
Submitter : Alan Stern <stern-nwvwT67g6+6dFdvTe/[email protected]>
Date : 2010-01-11 14:54 (14 days old)
References : http://marc.info/?l=linux-kernel&m=126322167427159&w=4

Handled-By Johannes Berg <[email protected]>

Quoted 8 lines · 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).

Quoted 6 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15126
Subject : REGRESSION for RT2561/RT61 in 2.6.33
Submitter : Alan Stern <[email protected]>
Date : 2010-01-11 14:54 (14 days old)
References : http://marc.info/?l=linux-kernel&m=126322167427159&w=4

Handled-By Johannes Berg <[email protected]>

This bug entry can be removed from the list. It turned out not to be a bug at all, just a kernel config error I made when updating to 2.6.33-rc1.

This message has been generated automatically 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=15129
Subject : [drm:i915_gem_execbuffer] *ERROR* i915_gem_do_execbuffer returns -512
Submitter : Miles Lane <[email protected]>
Date : 2010-01-14 23:18 (11 days old)
References : http://lkml.org/lkml/2010/1/14/570

Handled-By Chris Wilson <[email protected]>

Quoted 8 lines · On Sun, 24 Jan 2010 23:04:39 +0100 (CET) "Rafael J. Wysocki" <[email protected]>…

This message has been generated automatically 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).

Quoted 7 lines

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 <[email protected]>
Date : 2010-01-14 23:18 (11 days old)
References : http://lkml.org/lkml/2010/1/14/570

Handled-By Chris Wilson <[email protected]>

I think this message has been rightly killed. Getting -ERESTARTSYS from this function is perfectly normal, so we shouldn't bother printing a message about it.

This message has been generated automatically 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=15132
Subject : OOPS's with large initramfs
Submitter : Nigel Kukard <nkukard-pYARk8SH/[email protected]>
Date : 2010-01-16 11:12 (9 days old)
References : http://marc.info/?l=linux-kernel&m=126364100321603&w=4

Verified. I have tested this as far back as 2.6.30 with the same problem with "very" large initramfs's.

This message has been generated automatically 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=15137
Subject : NULL pointer dereference in vlan_skb_recv
Submitter : Bruno Prémont <[email protected]>
Date : 2010-01-23 15:56 (2 days old)
References : http://marc.info/?l=linux-kernel&m=126426286507497&w=4

Handled-By Eric Dumazet <[email protected]>

Patch : http://patchwork.kernel.org/patch/74999/

		  http://patchwork.kernel.org/patch/75002/

Quoted 8 lines · 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).

Quoted 9 lines

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15137
Subject : NULL pointer dereference in vlan_skb_recv
Submitter : Bruno Prémont <[email protected]>
Date : 2010-01-23 15:56 (2 days old)
References : http://marc.info/?l=linux-kernel&m=126426286507497&w=4

Handled-By Eric Dumazet <[email protected]>

Patch : http://patchwork.kernel.org/patch/74999/

		  http://patchwork.kernel.org/patch/75002/

This one can be closed, patch from Eric is already applied by David Miller.

Quoted 19 lines · Rafael J. Wysocki

Quoted 17 lines

This message has been generated automatically 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=15137
Subject : NULL pointer dereference in vlan_skb_recv
Submitter : Bruno Prémont <[email protected]>
Date : 2010-01-23 15:56 (2 days old)
References : http://marc.info/?l=linux-kernel&m=126426286507497&w=4

Handled-By Eric Dumazet <[email protected]>

Patch : http://patchwork.kernel.org/patch/74999/

		  http://patchwork.kernel.org/patch/75002/

Quoted 1 line

This one can be closed, patch from Eric is already applied by David Miller.

Is it in the Linus' tree already?

From: "Rafael J. Wysocki" <[email protected]>
Date: Mon, 25 Jan 2010 22:07:52 +0100

Quoted 20 lines · Américo Wang

Quoted 19 lines · Rafael J. Wysocki

Quoted 17 lines

This message has been generated automatically 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=15137
Subject : NULL pointer dereference in vlan_skb_recv
Submitter : Bruno Prémont <[email protected]>
Date : 2010-01-23 15:56 (2 days old)
References : http://marc.info/?l=linux-kernel&m=126426286507497&w=4

Handled-By Eric Dumazet <[email protected]>

Patch : http://patchwork.kernel.org/patch/74999/

		  http://patchwork.kernel.org/patch/75002/

Quoted 3 lines

Quoted 1 line

This one can be closed, patch from Eric is already applied by David Miller.

Is it in the Linus' tree already?

No, but it will be there soon, I'll push it to him today. :-)