Re: 2.6.14-rc1 breaks tg3 on ia64

Re: 2.6.14-rc1 breaks tg3 on ia64

[Mike Habeck]

Jack Steiner wrote:
> On Sat, Sep 17, 2005 at 09:16:17AM -0700, Greg KH wrote:
> > On Sat, Sep 17, 2005 at 11:59:14AM -0400, John W. Linville wrote:
> > > On Sat, Sep 17, 2005 at 08:47:03AM -0700, Tony Luck wrote:
> > > > > >So does reverting this patch solve the problem?
> > > > >
> > > > > I reversing
> > > > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=064b53dbcc977dbf2753a67c2b8fc1c061d74f21,
> > > > > which appears to be the latest version of this patch.  There was a
> > > > > patch reject in sparc64, but the common code was reverted.  IA64 (SGI
> > > > > Altix) with that patch reverted now boots 2.6.14-rc1.
> > > >
> > > > Anyone know anything more about this problem?  I'm not seeing it
> > > > on any of my systems ... so perhaps it only affects cards with a
> > > > PCI bridge on them, or cards that haven't already been initialized
> > > > by EFI.
> > >
> > > I posted a patch on Wednesday:
> > >
> > >     http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html
> > >
> > > The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
> > > patch to fix the problem.
> >
> > Yes, and a number of people objected to that patch.  Care to respond to
> > them?
> 
> We are working on an SN-only workaround. No guarantee, but the person
> working on it is optimistic that we can fix the problem in SN code
> w/o making any generic changes. I should know more on Monday.
> 
> Long term, we are making SN ACPI compliant - or at leeast a lot closer.


As Jack stated above, the issue is that sgi isn't fully ACPI 
compliant yet.  On a SN platform the pci_controller->pci_window's 
are not initialized...so routines like pcibios_resource_to_bus() 
and pcibios_bus_to_resource() will not work.  It is this reason 
why the pci_restore_bars() call, added to pci_set_power_state(), 
is causing a problem on SN platforms. 

SGIs long term goal is to become ACPI compliant, but until that 
happens sgi need to somehow prevent things that rely on the 
pci_controller->pci_window's from being called.  John Linville 
latest patch, the one that "restricts calling pci_restore_bars 
unless the current state is PCI_UNKNOWN and the actual state of 
the device is PCI_D3hot..." does that.  I don't understand why 
this is wrong (why is checking the physical/actual state of the 
device unattractive?  Why restore the BARs if it's unnecessary)?  
Anyhow, if this patch gets pulled then sgi will needs to do 
something quick and dirty in the SN specific code to prevent 
pci_restore_bars() from getting called.  Like hack 
sn_pci_fixup_slot() to set the current_state to PCI_D0:

--- arch/ia64/sn/kernel/io_init.c       2005-09-19 17:11:11 -05:00
+++ arch/ia64/sn/kernel/io_init.c.org   2005-09-19 17:10:40 -05:00
@@ -329,8 +329,6 @@
                SN_PCIDEV_INFO(dev)->pdi_sn_irq_info = NULL;
                kfree(sn_irq_info);
        }
-
-       dev->current_state = PCI_D0;

And yes, I understand this is just putting a Band-Aid on the 
current problem... until the ACPI support is in place to init
the controller's pci_windows we're just asking for future
problems.

So is hacking the SN specific code to initialize the device's 
state to PCI_DO more attractive than keeping John Linville current 
patch?  As I said, I personally see nothing wrong with John 
Linville current patch to check the actual state of the device.

-mike habeck

Re: 2.6.14-rc1 breaks tg3 on ia64

[David S. Miller]

From: Mike Habeck <habeck@sgi.com>
Date: Mon, 19 Sep 2005 17:43:29 -0500

> So is hacking the SN specific code to initialize the device's 
> state to PCI_DO more attractive than keeping John Linville current 
> patch?  As I said, I personally see nothing wrong with John 
> Linville current patch to check the actual state of the device.

I think keeping John's patch in is fine, especially if you guys
do have the longer term strategy of making pci_resource_to_bus()
work properly on this platform.  Because somewhere down the line
something else will depend upon it being correct, and you'll
need to address this properly.

Actually, some PCI quirk fixups use pcibios_bus_to_resource(), but the
one's that do this are probably not relevant on ia64.

2.6.14-rc1 breaks tg3 on ia64

[Keith Owens]

2.6.14-rc1 + kdb on ia64 (SGI Altix).

tg3.c:v3.39 (September 5, 2005)
ACPI: PCI Interrupt 0001:01:04.0[A]: no GSI
BRIDGE ERR_STATUS 0x800
BRIDGE ERR_STATUS 0x800
PCI BRIDGE ERROR: int_status is 0x800 for 011c32:slab0:widget15:bus0
    Dumping relevant 011c32:slab0:widget15:bus0 registers for each bit set...
        11: PCI bus device select timeout
            PCI Error Address Register: 0x3000000316808
            PCI Error Address: 0x316808
    PIC Multiple Interrupt Register is 0x800
        11: PCI bus device select timeout

Followed by a machine check and reboot :(  2.6.13 worked fine.  Any
ideas which patch to backout this time?

Re: 2.6.14-rc1 breaks tg3 on ia64

[David S. Miller]

From: Keith Owens <kaos@sgi.com>
Date: Tue, 13 Sep 2005 15:22:17 +1000

> 2.6.14-rc1 + kdb on ia64 (SGI Altix).
> 
> tg3.c:v3.39 (September 5, 2005)
> ACPI: PCI Interrupt 0001:01:04.0[A]: no GSI
> BRIDGE ERR_STATUS 0x800
> BRIDGE ERR_STATUS 0x800
> PCI BRIDGE ERROR: int_status is 0x800 for 011c32:slab0:widget15:bus0
>     Dumping relevant 011c32:slab0:widget15:bus0 registers for each bit set...
>         11: PCI bus device select timeout
>             PCI Error Address Register: 0x3000000316808
>             PCI Error Address: 0x316808
>     PIC Multiple Interrupt Register is 0x800
>         11: PCI bus device select timeout
> 
> Followed by a machine check and reboot :(  2.6.13 worked fine.  Any
> ideas which patch to backout this time?

Does copying over the 2.6.13 tg3.[ch] driver over into your
2.6.14-rc1 tree make it work?

Re: 2.6.14-rc1 breaks tg3 on ia64

[Keith Owens]

On Mon, 12 Sep 2005 22:37:55 -0700 (PDT), 
"David S. Miller" <davem@davemloft.net> wrote:
>From: Keith Owens <kaos@sgi.com>
>Date: Tue, 13 Sep 2005 15:22:17 +1000
>
>> 2.6.14-rc1 + kdb on ia64 (SGI Altix).
>> 
>> tg3.c:v3.39 (September 5, 2005)
>> ACPI: PCI Interrupt 0001:01:04.0[A]: no GSI
>> BRIDGE ERR_STATUS 0x800
>> BRIDGE ERR_STATUS 0x800
>> PCI BRIDGE ERROR: int_status is 0x800 for 011c32:slab0:widget15:bus0
>>     Dumping relevant 011c32:slab0:widget15:bus0 registers for each bit set...
>>         11: PCI bus device select timeout
>>             PCI Error Address Register: 0x3000000316808
>>             PCI Error Address: 0x316808
>>     PIC Multiple Interrupt Register is 0x800
>>         11: PCI bus device select timeout
>> 
>> Followed by a machine check and reboot :(  2.6.13 worked fine.  Any
>> ideas which patch to backout this time?
>
>Does copying over the 2.6.13 tg3.[ch] driver over into your
>2.6.14-rc1 tree make it work?

No, the 2.6.13 driver in 2.6.14-rc1 has exactly the same problem.

The last time that tg3 broke like this, it was because of the patch
below, in 2.6.13-rc6.  That was backed out in 2.6.13-rc7.  Was the PCI
patch (or equivalent) reinstated in 2.6.14-rc1?

From: John W. Linville <linville@tuxdriver.com>
Date: Fri, 5 Aug 2005 01:06:10 +0000 (-0700)
Subject: [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it
X-Git-Tag: v2.6.13-rc6
X-Git-Url: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fec59a711eef002d4ef9eb8de09dd0a26986eb77

Re: 2.6.14-rc1 breaks tg3 on ia64

[David S. Miller]

From: Keith Owens <kaos@sgi.com>
Date: Tue, 13 Sep 2005 16:17:33 +1000

> No, the 2.6.13 driver in 2.6.14-rc1 has exactly the same problem.
> 
> The last time that tg3 broke like this, it was because of the patch
> below, in 2.6.13-rc6.  That was backed out in 2.6.13-rc7.  Was the PCI
> patch (or equivalent) reinstated in 2.6.14-rc1?

It was reinstated, with a fix for the sparc64 problems it caused.
I wasn't aware of any ia64 regressions introduced by it.

Re: 2.6.14-rc1 breaks tg3 on ia64

[Keith Owens]

On Tue, 13 Sep 2005 16:17:33 +1000, 
Keith Owens <kaos@sgi.com> wrote:
>On Mon, 12 Sep 2005 22:37:55 -0700 (PDT), 
>"David S. Miller" <davem@davemloft.net> wrote:
>>From: Keith Owens <kaos@sgi.com>
>>Date: Tue, 13 Sep 2005 15:22:17 +1000
>>
>>> 2.6.14-rc1 + kdb on ia64 (SGI Altix).
>>> 
>>> tg3.c:v3.39 (September 5, 2005)
>>> ACPI: PCI Interrupt 0001:01:04.0[A]: no GSI
>>> BRIDGE ERR_STATUS 0x800
>>> BRIDGE ERR_STATUS 0x800
>>> PCI BRIDGE ERROR: int_status is 0x800 for 011c32:slab0:widget15:bus0
>>>     Dumping relevant 011c32:slab0:widget15:bus0 registers for each bit set...
>>>         11: PCI bus device select timeout
>>>             PCI Error Address Register: 0x3000000316808
>>>             PCI Error Address: 0x316808
>>>     PIC Multiple Interrupt Register is 0x800
>>>         11: PCI bus device select timeout
>>> 
>>> Followed by a machine check and reboot :(  2.6.13 worked fine.  Any
>>> ideas which patch to backout this time?
>>
>>Does copying over the 2.6.13 tg3.[ch] driver over into your
>>2.6.14-rc1 tree make it work?
>
>No, the 2.6.13 driver in 2.6.14-rc1 has exactly the same problem.
>
>The last time that tg3 broke like this, it was because of the patch
>below, in 2.6.13-rc6.  That was backed out in 2.6.13-rc7.  Was the PCI
>patch (or equivalent) reinstated in 2.6.14-rc1?
>
>From: John W. Linville <linville@tuxdriver.com>
>Date: Fri, 5 Aug 2005 01:06:10 +0000 (-0700)
>Subject: [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it
>X-Git-Tag: v2.6.13-rc6
>X-Git-Url: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fec59a711eef002d4ef9eb8de09dd0a26986eb77

Another data point.  Omit the tg3 from the build and then it breaks on
the SCSI qla2300 driver.  It is a PCI/ACPI specific problem on ia64,
not just network.

qla1280: QLA12160 found on PCI bus 1, dev 3
ACPI: PCI Interrupt 0001:01:03.0[A]: no GSI
BRIDGE ERR_STATUS 0x800
BRIDGE ERR_STATUS 0x800
PCI BRIDGE ERROR: int_status is 0x800 for 011c32:slab0:widget15:bus0
    Dumping relevant 011c32:slab0:widget15:bus0 registers for each bit set...
        11: PCI bus device select timeout
            PCI Error Address Register: 0x3000000302008
            PCI Error Address: 0x302008
    PIC Multiple Interrupt Register is 0x800
        11: PCI bus device select timeout

Re: 2.6.14-rc1 breaks tg3 on ia64

[Greg KH]

On Tue, Sep 13, 2005 at 04:17:33PM +1000, Keith Owens wrote:
> On Mon, 12 Sep 2005 22:37:55 -0700 (PDT), 
> "David S. Miller" <davem@davemloft.net> wrote:
> >From: Keith Owens <kaos@sgi.com>
> >Date: Tue, 13 Sep 2005 15:22:17 +1000
> >
> >> 2.6.14-rc1 + kdb on ia64 (SGI Altix).
> >> 
> >> tg3.c:v3.39 (September 5, 2005)
> >> ACPI: PCI Interrupt 0001:01:04.0[A]: no GSI
> >> BRIDGE ERR_STATUS 0x800
> >> BRIDGE ERR_STATUS 0x800
> >> PCI BRIDGE ERROR: int_status is 0x800 for 011c32:slab0:widget15:bus0
> >>     Dumping relevant 011c32:slab0:widget15:bus0 registers for each bit set...
> >>         11: PCI bus device select timeout
> >>             PCI Error Address Register: 0x3000000316808
> >>             PCI Error Address: 0x316808
> >>     PIC Multiple Interrupt Register is 0x800
> >>         11: PCI bus device select timeout
> >> 
> >> Followed by a machine check and reboot :(  2.6.13 worked fine.  Any
> >> ideas which patch to backout this time?
> >
> >Does copying over the 2.6.13 tg3.[ch] driver over into your
> >2.6.14-rc1 tree make it work?
> 
> No, the 2.6.13 driver in 2.6.14-rc1 has exactly the same problem.
> 
> The last time that tg3 broke like this, it was because of the patch
> below, in 2.6.13-rc6.  That was backed out in 2.6.13-rc7.  Was the PCI
> patch (or equivalent) reinstated in 2.6.14-rc1?
> 
> From: John W. Linville <linville@tuxdriver.com>
> Date: Fri, 5 Aug 2005 01:06:10 +0000 (-0700)
> Subject: [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it
> X-Git-Tag: v2.6.13-rc6
> X-Git-Url: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fec59a711eef002d4ef9eb8de09dd0a26986eb77

So does reverting this patch solve the problem?

thanks,

greg k-h

Re: 2.6.14-rc1 breaks tg3 on ia64

[Keith Owens]

On Mon, 12 Sep 2005 23:59:37 -0700, 
Greg KH <greg@kroah.com> wrote:
>On Tue, Sep 13, 2005 at 04:17:33PM +1000, Keith Owens wrote:
>> The last time that tg3 broke like this, it was because of the patch
>> below, in 2.6.13-rc6.  That was backed out in 2.6.13-rc7.  Was the PCI
>> patch (or equivalent) reinstated in 2.6.14-rc1?
>> 
>> From: John W. Linville <linville@tuxdriver.com>
>> Date: Fri, 5 Aug 2005 01:06:10 +0000 (-0700)
>> Subject: [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it
>> X-Git-Tag: v2.6.13-rc6
>> X-Git-Url: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fec59a711eef002d4ef9eb8de09dd0a26986eb77
>
>So does reverting this patch solve the problem?

I reversing
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=064b53dbcc977dbf2753a67c2b8fc1c061d74f21,
which appears to be the latest version of this patch.  There was a
patch reject in sparc64, but the common code was reverted.  IA64 (SGI
Altix) with that patch reverted now boots 2.6.14-rc1.

Re: 2.6.14-rc1 breaks tg3 on ia64

[Tony Luck]

> >So does reverting this patch solve the problem?
> 
> I reversing
> http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=064b53dbcc977dbf2753a67c2b8fc1c061d74f21,
> which appears to be the latest version of this patch.  There was a
> patch reject in sparc64, but the common code was reverted.  IA64 (SGI
> Altix) with that patch reverted now boots 2.6.14-rc1.

Anyone know anything more about this problem?  I'm not seeing it
on any of my systems ... so perhaps it only affects cards with a
PCI bridge on them, or cards that haven't already been initialized
by EFI.

-Tony

Re: 2.6.14-rc1 breaks tg3 on ia64

[John W. Linville]

On Sat, Sep 17, 2005 at 08:47:03AM -0700, Tony Luck wrote:
> > >So does reverting this patch solve the problem?
> > 
> > I reversing
> > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=064b53dbcc977dbf2753a67c2b8fc1c061d74f21,
> > which appears to be the latest version of this patch.  There was a
> > patch reject in sparc64, but the common code was reverted.  IA64 (SGI
> > Altix) with that patch reverted now boots 2.6.14-rc1.
> 
> Anyone know anything more about this problem?  I'm not seeing it
> on any of my systems ... so perhaps it only affects cards with a
> PCI bridge on them, or cards that haven't already been initialized
> by EFI.

I posted a patch on Wednesday:

	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html

The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
patch to fix the problem.

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: 2.6.14-rc1 breaks tg3 on ia64

[Greg KH]

On Sat, Sep 17, 2005 at 11:59:14AM -0400, John W. Linville wrote:
> On Sat, Sep 17, 2005 at 08:47:03AM -0700, Tony Luck wrote:
> > > >So does reverting this patch solve the problem?
> > > 
> > > I reversing
> > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=064b53dbcc977dbf2753a67c2b8fc1c061d74f21,
> > > which appears to be the latest version of this patch.  There was a
> > > patch reject in sparc64, but the common code was reverted.  IA64 (SGI
> > > Altix) with that patch reverted now boots 2.6.14-rc1.
> > 
> > Anyone know anything more about this problem?  I'm not seeing it
> > on any of my systems ... so perhaps it only affects cards with a
> > PCI bridge on them, or cards that haven't already been initialized
> > by EFI.
> 
> I posted a patch on Wednesday:
> 
> 	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html
> 
> The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
> patch to fix the problem.

Yes, and a number of people objected to that patch.  Care to respond to
them?

thanks,

greg k-h

Re: 2.6.14-rc1 breaks tg3 on ia64

[Jack Steiner]

On Sat, Sep 17, 2005 at 09:16:17AM -0700, Greg KH wrote:
> On Sat, Sep 17, 2005 at 11:59:14AM -0400, John W. Linville wrote:
> > On Sat, Sep 17, 2005 at 08:47:03AM -0700, Tony Luck wrote:
> > > > >So does reverting this patch solve the problem?
> > > > 
> > > > I reversing
> > > > http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=064b53dbcc977dbf2753a67c2b8fc1c061d74f21,
> > > > which appears to be the latest version of this patch.  There was a
> > > > patch reject in sparc64, but the common code was reverted.  IA64 (SGI
> > > > Altix) with that patch reverted now boots 2.6.14-rc1.
> > > 
> > > Anyone know anything more about this problem?  I'm not seeing it
> > > on any of my systems ... so perhaps it only affects cards with a
> > > PCI bridge on them, or cards that haven't already been initialized
> > > by EFI.
> > 
> > I posted a patch on Wednesday:
> > 
> > 	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html
> > 
> > The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
> > patch to fix the problem.
> 
> Yes, and a number of people objected to that patch.  Care to respond to
> them?

We are working on an SN-only workaround. No guarantee, but the person
working on it is optimistic that we can fix the problem in SN code
w/o making any generic changes. I should know more on Monday.

Long term, we are making SN ACPI compliant - or at leeast a lot closer.


> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.

Re: 2.6.14-rc1 breaks tg3 on ia64

[John W. Linville]

On Sat, Sep 17, 2005 at 11:34:34AM -0500, Jack Steiner wrote:

> We are working on an SN-only workaround. No guarantee, but the person
> working on it is optimistic that we can fix the problem in SN code
> w/o making any generic changes. I should know more on Monday.
> 
> Long term, we are making SN ACPI compliant - or at leeast a lot closer.

Well, there you go... :-)

John
-- 
John W. Linville
linville@tuxdriver.com

Re: 2.6.14-rc1 breaks tg3 on ia64

[John W. Linville]

On Sat, Sep 17, 2005 at 09:16:17AM -0700, Greg KH wrote:
> On Sat, Sep 17, 2005 at 11:59:14AM -0400, John W. Linville wrote:
> > On Sat, Sep 17, 2005 at 08:47:03AM -0700, Tony Luck wrote:

> > > Anyone know anything more about this problem?  I'm not seeing it
> > > on any of my systems ... so perhaps it only affects cards with a
> > > PCI bridge on them, or cards that haven't already been initialized
> > > by EFI.
> > 
> > I posted a patch on Wednesday:
> > 
> > 	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html
> > 
> > The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
> > patch to fix the problem.
> 
> Yes, and a number of people objected to that patch.  Care to respond to
> them?

Care to check your email? :-)

	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2267.html

Basically, the concerns raised are non-issues.	The new patch
merely limits the BAR restoration to those situations where it is
truly needed.  Anything broken in that situation was broken before
the original patch as well.

The only other point was that this particular ia64 hardware is
broken if you can't rewrite its BARs.  That may well be, but we can
accomodate it w/o losing the intent of the original patch.

Tony's post indicates that this is not a generic ia64 problem.  If you
want a patch along the lines of what Dave Miller and Ivan Kokshaysky
advocate (i.e. something in the pci access routines for this box),
then Keith or someone else w/ knowledge of (and access to) this box
will need to step forward w/ a patch or at least some information.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: 2.6.14-rc1 breaks tg3 on ia64

[David S. Miller]

From: "John W. Linville" <linville@tuxdriver.com>
Date: Sat, 17 Sep 2005 11:59:14 -0400

> I posted a patch on Wednesday:
> 
> 	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html
> 
> The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
> patch to fix the problem.

It fixes the problem, but it's a hack, and I, perhaps like Tony,
personally would like to know why the these IA64 systems break for
such a simple operation such as writing some base registers with
values we've probed already.

Re: 2.6.14-rc1 breaks tg3 on ia64

[Tony Luck]

> It fixes the problem, but it's a hack, and I, perhaps like Tony,
> personally would like to know why the these IA64 systems break for
> such a simple operation such as writing some base registers with
> values we've probed already.

It does sound odd[1] that you can't rewrite the BARs to the values that
they should already have.  But I'm willing to wait to see what SGI's
solution that fixes this inside arch/ia64/sn/ looks like before making
any judgements.

-Tony

[1] odd == PCI spec violating?

Re: 2.6.14-rc1 breaks tg3 on ia64

[Jack Steiner]

On Sat, Sep 17, 2005 at 11:23:04PM -0700, David S. Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Sat, 17 Sep 2005 11:59:14 -0400
> 
> > I posted a patch on Wednesday:
> > 
> > 	http://www.ussg.iu.edu/hypermail/linux/kernel/0509.1/2193.html
> > 
> > The original reporter (Keith Owens <kaos@sgi.com>) confirmed this
> > patch to fix the problem.
> 
> It fixes the problem, but it's a hack, and I, perhaps like Tony,
> personally would like to know why the these IA64 systems break for
> such a simple operation such as writing some base registers with
> values we've probed already.

Here is the mail from Mike Habeck (sgi) - he understands the problem
muck better than I do:

(from Mike....)
The problem is we (sgi) don't support the ACPI pci_window stuff that
is setup via ACPI (see: add_window() code).  And as a result when
pci_restore_bars() is called to restore the BARs, instead of the BARs
getting "restored" they get wiped out.  (pci_restore_bars() calls
pci_update_resource() which calls pcibios_resource_to_bus()... it
is that routine that is expecting the pci_window stuff being set up
from the ACPI path... I think... (I don't know much about how the ACPI
stuff works, John or Aaron could probably prove me right or wrong)...
So John (or Aaron) is it ACPI that is suppose to setup this pci_window
stuff?

I still question why this code path is taken... I don't know anything
about the PCI Power Management stuff, but we shouldn't be in any power
state that results in us needing our BARs restored.  But I guess that
really isn't the issue since sooner or later something else will end
up using this pci_window stuff and we'll get burned them.

I suppose for a quick fix (to workaround this power management patch)
could be to set the PCI_PM_CTRL_NO_SOFT_RESET in the cards PM capability
down in PROM thus bypassing this "need_restore" code.

I suppose for a quick fix (to workaround this power management patch)
could be to set the PCI_PM_CTRL_NO_SOFT_RESET in the cards PM capability
down in PROM thus bypassing this "need_restore" code.

        /* If we're in D3, force entire word to 0.
         * This doesn't affect PME_Status, disables PME_En, and
         * sets PowerState to 0.
         */
        if (dev->current_state >= PCI_D3hot) {
                if (!(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET))
                        need_restore = 1;
                pmcsr = 0;
        } else {
                pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
                pmcsr |= state;
        }

Or in the kernel sgi device fixup code change the current_state to D0?
It looks like it get's init'd to PCI_UNKNOWN (which is > PCI_D3hot)
I don't know... will investigate more tomorrow

-mike

-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.