Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>

---
No code change on binary level.
Index: linux-2.6.git/arch/x86/kernel/apic_32.c

===================================================================

--- linux-2.6.git.orig/arch/x86/kernel/apic_32.c	2008-07-24 13:40:58.000000000 +0400

+++ linux-2.6.git/arch/x86/kernel/apic_32.c	2008-07-24 13:48:52.000000000 +0400

@@ -226,9 +226,13 @@ int get_physical_broadcast(void)

  */

 int lapic_get_maxlvt(void)

 {

-	unsigned int v = apic_read(APIC_LVR);

+	unsigned int v;
-	/* 82489DXs do not report # of LVT entries. */

+	v = apic_read(APIC_LVR);

+	/*

+	 * - we always have APIC integrated on 64bit mode

+	 * - 82489DXs do not report # of LVT entries

+	 */

 	return APIC_INTEGRATED(GET_APIC_VERSION(v)) ? GET_APIC_MAXLVT(v) : 2;

 }
Index: linux-2.6.git/arch/x86/kernel/apic_64.c

===================================================================

--- linux-2.6.git.orig/arch/x86/kernel/apic_64.c	2008-07-24 13:40:58.000000000 +0400

+++ linux-2.6.git/arch/x86/kernel/apic_64.c	2008-07-24 13:48:38.000000000 +0400

@@ -228,11 +228,14 @@ void __cpuinit enable_NMI_through_LVT0(v

  */

 int lapic_get_maxlvt(void)

 {

-	unsigned int v, maxlvt;

+	unsigned int v;
 	v = apic_read(APIC_LVR);

-	maxlvt = GET_APIC_MAXLVT(v);

-	return maxlvt;

+	/*

+	 * - we always have APIC integrated on 64bit mode

+	 * - 82489DXs do not report # of LVT entries

+	 */

+	return APIC_INTEGRATED(GET_APIC_VERSION(v)) ? GET_APIC_MAXLVT(v) : 2;

 }
 /*
--

--

Right ! And this one is still broken in -rc3:
Subject    : kernel panics on boot (libata-sff)

References : http://lkml.org/lkml/2006/12/3/99

            http://lkml.org/lkml/2006/12/14/153

            http://lkml.org/lkml/2006/12/24/33

Submitter  : Alessandro Suardi <alessandro.suardi@gmail.com>

Caused-By  : Alan Cox <alan@lxorguk.ukuu.org.uk>

            commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f

Handled-By : Alan Cox <alan@lxorguk.ukuu.org.uk>

Status     : people are working on a fix
Happy 2007 everyone,
--alessandro
"...when I get it, I _get_ it"
     (Lara Eidemiller)

-

Jeff,

 what was the resolution to this one? Just revert the offending commit, or

what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a

two-month release rather than the usual dragged-out three months, so I'd

like to get these regressions to be actively fixed. By forcible reverts if

that is what it takes.
		Linus
-

Data points:
* I was unable to argue against Alan's logic behind

368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it.

Regardless of whether or not this truly reflects how the PCI device is

wired, it makes pci_request_regions() and similar resource handling code

behave differently.
* Alan's 368c73d4f689dae0807d0a2aa74c61fd2b9b075f change was IMO

incomplete, because he obviously did not fix all the breakage it caused
* Alan proposed a libata fix patch.  I noted two key breakages in his

fix patch, one of which Alan agreed was a problem.
* Outside of the two bugfix pushes, I've been actively avoiding

computers during the holidays.  It's a shocking concept I'm trying with

the new wife :)  Don't expect anything useful from me until Jan 4th or so.
* This affects a lot of Intel ICH platforms in legacy/combined mode, so

it's definitely high on my post-holiday priority list.  If the patch is

not reverted, then I'll definitely fix it sooner rather than later.
* For 2.6.21, I proposed to yank out all the ugly combined mode hacks

(grep for '____request_resource'), which should make Alan's change a bit

easier... but nonetheless stirs the IDE quirks code again.
* I am lazy and would rather not touch the fragile ata_pci_init_one()

code now /and/ in 2.6.21.
So I vote for revert, for 2.6.20, but I know Alan will squawk loudly.

Also NOTE thoughfb0f2b40faff41f03acaa2ee6e6231fc96ca497c which fixes

fallout from Alan's change, too.
	Jeff
-

This is a slight variant on the patch I posted December 16th to fix

libata combined mode handling. The only real change is that we now

correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native one channel

legacy. 
This is a silly complaint because the SFF layer in libata doesn't handle

this case yet anyway.
2. The case where combined mode is in use and IDE=n. 
In this case the libata quirk code reserves the resources in question

correctly already.
Once the combined mode stuff is redone properly (2.6.21) then the entire

mess turns into a single pci_request_regions() for all cases and all the

ugly resource hackery goes away.
I'm sending this now rather than after running full test suites so that

it can get the maximal testing in a short time. I'll be running tests on

this after lunch. 
Signed-off-by: Alan Cox <alan@redhat.com>
--- linux.vanilla-2.6.20-rc3/drivers/ata/libata-sff.c	2007-01-01 21:43:27.000000000 +0000

+++ linux-2.6.20-rc3/drivers/ata/libata-sff.c	2007-01-02 11:15:53.000000000 +0000

@@ -1027,13 +1027,15 @@

 #endif

 	}
-	rc = pci_request_regions(pdev, DRV_NAME);

-	if (rc) {

-		disable_dev_on_err = 0;

-		goto err_out;

-	}

-

-	if (legacy_mode) {

+	if (!legacy_mode) {

+		rc = pci_request_regions(pdev, DRV_NAME);

+		if (rc) {

+			disable_dev_on_err = 0;

+			goto err_out;

+		}

+	} else {

+		/* Deal with combined mode hack. This side of the logic all

+		   goes away once the combined mode hack is killed in 2.6.21 */

 		if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {

 			struct resource *conflict, res;

 			res.start = ATA_PRIMARY_CMD;

@@ -1071,6 +1073,13 @@

 			}

 		} else

 			legacy_mode |= ATA_PORT_SECONDARY;

+

+		if (legacy_mode & ATA_PORT_PRIMARY)

+			pci_request_region(pdev, 1, DRV_NAME);

+		if (legacy_mode & ATA_PORT_SECONDARY)

+			pci_request_region(pdev, 3, DRV_NAME);

+		/* If there is a DMA resource, allocate it...
[ message continues ]

On Tue, 2007-01-02 at 11:58 +0000, Alan wrote:
This patch works for me too.
Steve.
-

Appears to work just fine here (compiles, boots and I'm

 typing this email :).  The build warnings below seem new

 to me - but I guess they're harmless...
  CC      drivers/ata/libata-sff.o

drivers/ata/libata-sff.c: In function 'ata_pci_init_one':

drivers/ata/libata-sff.c:1078: warning: ignoring return value of

'pci_request_region', declared with attribute warn_unused_result

drivers/ata/libata-sff.c:1080: warning: ignoring return value of

'pci_request_region', declared with attribute warn_unused_result

drivers/ata/libata-sff.c:1082: warning: ignoring return value of

'pci_request_region', declared with attribute warn_unused_result
Thanks, ciao,
--alessandro
 "but I thought that I should let you know

  the things that I don't always show

  might not be worth the time it took"
     (Steve Wynn, 'If My Life Was An Open Book')

-

They are harmless. For the 2.6.21 code base they will go away as well.

-

Yes, it's "silly" people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of.  They only needed 
Not /all/ the resources.  And YOU were the person harping me about

acquiring all resources, so that even races no one cares about[1] are

avoided.
But those two items were just from my five-minute, on-vacation review.

Obvious bug #3:
The code no long reserves resources for the "extra" PCI BAR that often

exists on PCI controllers regardless of legacy/native mode.  Previously,

the code called pci_request_regions() to reserve ALL regions attached to

the PCI device.
You have suddenly decided that it's OK to --not reserve at all-- these

additional regions.
Proof:  The AHCI PCI BAR (#5, zero-based) is clearly NOT reserved, even

though we talk to it, in piix_disable_ahci() of ata_piix.c.
	Jeff
-

We use BAR5 on two devices in legacy mode. Both of those reserve all the

other resources. We can fix BAR5 in .21 when all the combined mode crap
We always claim the other BARs so catch a collision.
Alan

-

Translation:  You want to hand-wave away an obvious regression that YOU 
Translation:  Problems disappear in 2.6.21 because Jeff will revert the

code I touched to its previous state -- always calling

pci_request_regions() -- and all the problems I introduced by avoiding

pci_request_regions() will go away.
Where?  AFAICS, it is crystal clear the behavior:
* Prior to your patch, ata_piix in legacy mode calls

pci_request_regions() to intentionally reserve ALL regions on the PCI

device.
* After your patch, the code explicitly calls pci_request_region() for

BARs 0-4, but never for BAR5.
Another driver is now free to claim a PCI BAR, and start running the

hardware in AHCI mode, whee!
	Jeff
-

To fix the problem I introduced ? and because that patch to do so is
Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because

of the PCI resource mismanagement in the old tree. So you take your pick.

BAR1 and BAR3 were used on all devices and not reserved, BAR5 is used on

two. Neither case is actually a problem in the current tree and driver

set. Both will be fixed when the combined mode junk gets fired into

hyperspace.
Alan

-

I pick old bugs over new regressions.
	Jeff
-

False:
2.6.0 - 2.6.19:  libata guarantees that all PCI BARs are reserved to the

libata driver.
2.6.20:  no guarantee that all PCI BARs are reserved to libata driver.

Real-life ata_piix example already provided, where a PCI BAR is no

longer reserved to the driver.
2.6.21 - infinity:  libata guarantees that all PCI BARs are reserved to

the driver.
	Jeff
-

Please read the code Jeff. The old IDE quirk code in the PCI layer blanked

BAR 0 to BAR 3 of a compatibility mode controller
You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You

never request the legacy BAR 1 and BAR 3 because they were erased by the

PCI quirk code and thus never claim the other port. Thats been a bug since

day one but it never seemed worth fixing in the short term.
Alan

-

Or maybe this rephrase helps:
Regardless of how the IDE quirks have configured the PCI BARs, libata is

written to assume that /all/ struct pci_dev resources for a single PCI

device are reserved to the libata driver.
Thus, if you avoid calling pci_request_regions (as your patch does), you

must manually provide the same guarantees that pci_request_regions

provides to its callers.
	Jeff
-

pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the

fact the resources are mashed and eventually cleaare by the existing (pre

2.6.20-rc) PCI code. The new code does provide that guarantee which is

(unfortunately) precisely why you get the problem - because the combined

mode hack currently relies on it failing to do so.
Alan

-

(a) I'm well of aware of this, and (b) that changes nothing.
I said "PCI BARs" for a reason.  libata was written according to the

following model:
	1) Programmatically reserve /all/ resources associated with

	   our PCI device

	2) Manually reserve resources associated with our PCI device,

	   but are not listed in struct pci_dev.
You have changed this to:
	1) Manually reserve /some/ resources associated with PCI device

	2) Manually reserve resources associated with our PCI device,

	   but are not listed in struct pci_dev.
But then 2.6.21 goes back to:
	1) Programmatically reserve /all/ resources associated with

	   our PCI device

	2) Manually reserve resources associated with our PCI device,

	   but are not listed in struct pci_dev.
Maybe I can say it more clearly by telling you how to fix the regression

you have introduced:  Loop through all BAR resources in struct pci_dev,

and reserve them if they are not already reserved by libata earlier in

the code.  There.  Regression fixed.
Yes -- that's a bug, one that existed prior to the "it doesn't boot"

combined mode regression everybody complained about.  I'm talking about

a new regression just introduced via

dc3c3377f03634d351fafdfe35b237b283586c04, not a old bug that existed

prior to the regression introduced in

368c73d4f689dae0807d0a2aa74c61fd2b9b075f.
	Jeff
-

Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the

other register. BTW on unload you forget to release 0x1F0-7 too. I've not

fixed that as its not a regression just a bug. It's just another symptom
Nope. You are either very confused about how PCI bus resources work or

you are trying to implement the future code in a very very peculiar way 8)
Remember with the resource tree now correct all the resources for an IDE

controller *are* in the pci_dev struct properly - the special cases are

all gone in libata and in drivers/ide.
Once combined mode is fixed not to abuse resources (and it originally

did it that way for a good reason I grant and am not criticising that) the

entire management for legacy mode, mixed mode and native mode resources

for an ATA device (including 0x170, 0x3F6 and other wacky magic) becomes
	if (pci_request_regions(pdev, "libata")) ...
You'll note:

- No special cases for differing modes

- No libata knowledge of PCI legacy mapping rules and addresses

- The death of the magic ATA_PRIMARY/SECONDARY constants and their magic

numbers

- Support for platforms that map legacy space differently

- Trivial cleanup from failure unlike the current code
all in one line. This will also fix all the existing bugs where unloading

a libata driver fails to free resources as pci_release_regions() will also

now do the correct thing.
*That* is one key reason why getting the PCI resource map right is so

important. We turn fifty lines of bug ridden hard to debug code into one

line of code that actually does more than the original, and gets it

right. For free we get the leaked resources after rmmod fixed, we get the

mixed mode resources fixed, we get all this stuff for free. We get to

shoot a chunk of code in drivers/ide if we want as well.
If we want to keep a combined mode in 2.6.21 with drivers/ide (which

seems dumb as libata has progressed far beyond the need for it) then the

-mm tree has a pci_request_regions_mask() function which we can push

to .21 d...
[ message continues ]

Yes.  For 2.6.21.  As I've always said.
But for 2.6.20, we are only HALFWAY there, and all these /new/ bugs

exist as a result.
Your patch makes far more sense for 2.6.21, where the "halfway to

salvation" state, and associated rough edges, is not exposed to users.
Fixing the resource tree was only half the solution, since the drivers

that /use/ the resource tree now need updating.
	Jeff
-

Without checking for failures, I might add.
Let's call that regression/obvious bug #4, because the previous code 
I agree this is one way to avoid conflicts!  ;-)
	Jeff
-

On Tue, 02 Jan 2007 16:32:01 -0500
I did actually go through and verify that there are no drivers where this

would cause a problem including reading some of the painful crap in

drivers/ide to double check.
Is it perfection - no, does it fix 2.6.20 - yes, is it causing any

problems for a 2.6.21 roadmap - no.
Alan

-

Thanks,
I can confirm that with this patch applied, I can boot 2.6.20-rc3 on

my Thinkpad T60p.  My primary laptop is now running the with the

patch, and I'll start pushing it through its paces.  If start losing

any files or seeing any disk corruption I'll let folks now.
					- Ted

-

Correctly: The resource tree is no longer corrupt for example and

pci_* resource functions actually now do the right thing. The old code

works by chance due to link order, not because anything was "broken" by
I'm very concerned about what that will break that depends upon it - eg

all the work done for suspend/resume PCI handling has not been tested

without the patch. Thus I'd rather fix it given the fix is trivial.
Want a fix Linus given Jeff is away ?
Alan

-

Send it over, and please cc Alessandro and others that can test it. Things

obviously aren't broken on _my_ machines ;)
And if we end up having more problems related to this in -rc4, I'll just

revert both your fix and the original one. No hair lost over this one, I

think.
		Linus

-

Can I get a copy of the fix for testing as well?  I can confirm that

Alan's 368c73d4f689dae0807d0a2aa74c61fd2b9b075f breaks for me on my

T60 thinkpad.  Unfortunately I missed the earlier discussion on this,

and I didn't have time to test -rc1 and -rc2, so I spent a few hours

doing the git bisection in order to determine that it was Alan's

2b9b075f patch which was breaking -rc3 for me.
My current plan for testing -rc3 was to back out Alan's patch

(attached below for others' convenience), but I'm happy to test an

alternative fix.
						- Ted
Revert "PCI: quirks: fix the festering mess that claims to handle IDE quirks"
This reverts commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f.
This is needed to fix booting on a Thinkpad T60.  Without this patch,

we see the following error messages, and the SATA drive in the laptop

isn't detected, with the following messages printed during the boot

sequence:
ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]

ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 16

PCI: Unable to reserve I/O Region #1:8@1f0 for device 0000:00:1f.2

ata_piix: probe of 0000:00:1f.2 failed with error -16
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

---

 arch/i386/pci/fixup.c |   46 ++++++++++++++++++++++++++++++++++++++

 drivers/pci/probe.c   |   27 ----------------------

 drivers/pci/quirks.c  |   59 ++++++++++++++++++++++++++++++++++++++++++++++--

 3 files changed, 102 insertions(+), 30 deletions(-)
diff --git a/arch/i386/pci/fixup.c b/arch/i386/pci/fixup.c

index 8053b17..422483e 100644

--- a/arch/i386/pci/fixup.c

+++ b/arch/i386/pci/fixup.c

@@ -74,6 +74,52 @@ static void __devinit  pci_fixup_ncr53c810(struct pci_dev *d)

 }

 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NCR, PCI_DEVICE_ID_NCR_53C810, pci_fixup_ncr53c810);
+static void __devinit pci_fixup_ide_bases(struct pci_dev *d)

+{

+	int i;

+

+	/*

+	 * PCI IDE controllers use non-standard I/O port decoding, respect it.

+	 */

+	if ((d->class >> 8) != PCI_CLASS_STORA...
[ message continues ]

On Mon, 1 Jan 2007 12:13:08 -0800 (PST)
If you revert the commit you end with all the PCI resource tree breakage
The patch I sent ages back is perfectly adequate for 2.6.20-rc/2.6.20

final. Jeff is correct that it isn't perfection in all cases but it does

no real harm and the right fix (removing the whole bogus combined mode

garbage) is short and simple.
If Jeff doesn't get you a patch please let me know before reverting it

and I'll send you the one I'm using that folks have tested and works.
Alan

-

Which weren't a regression or anything new.
Alan: regressions are what we don't do. Ever. If your second patch is

found to have some other problems, we revert them both. It's that simple.

It's better to stay in place than walk backwards, even if the "backwards"

is just for a few people.
So far, it fixed at least Alessandro's problems, so here's to hoping there

aren't any others..
		Linus

-