Recent x86-64 patch causes many devices to disappear

Recent x86-64 patch causes many devices to disappear

[Jeff Garzik]

The following patch made A TON of devices disappear on my HP XW9300 
system.  I complained the day it was committed, but alas...

> commit 5491d0f3e206beb95eeb506510d62a1dab462df1
> Author: Andi Kleen <ak@suse.de>
> Date:   Mon May 15 18:19:41 2006 +0200
> 
>     [PATCH] i386/x86_64: Force pci=noacpi on HP XW9300
> 
>     This is needed to see all devices.


Finally, I was able to get to testing it, and provide proof that a 
shitload of devices do indeed disappear:

	http://gtf.org/garzik/dammit/

Files:
*.rc4		- rc4, plus some libata changes, PCI domains disabled
*.rc5		- rc5-git1, PCI domains disabled
*.rc5-pcidom	- rc5-git1, PCI domains enabled

As the patch doesn't work, and the description is proven patently false, 
maybe we can now consider reverting it and making a better patch?  My 
Marvell SATA and MPT Fusion devices are no longer available, as a diff 
between lspci.rc5 and lspci.rc5-pcidom demonstrates.

	Jeff

Re: Recent x86-64 patch causes many devices to disappear

[Andi Kleen]

On Friday 26 May 2006 11:53, Jeff Garzik wrote:
> 
> The following patch made A TON of devices disappear on my HP XW9300 
> system.  I complained the day it was committed, but alas...
> 
> > commit 5491d0f3e206beb95eeb506510d62a1dab462df1
> > Author: Andi Kleen <ak@suse.de>
> > Date:   Mon May 15 18:19:41 2006 +0200
> > 
> >     [PATCH] i386/x86_64: Force pci=noacpi on HP XW9300
> > 
> >     This is needed to see all devices.
> 
> 
> Finally, I was able to get to testing it, and provide proof that a 
> shitload of devices do indeed disappear:
> 
> 	http://gtf.org/garzik/dammit/
> 
> Files:
> *.rc4		- rc4, plus some libata changes, PCI domains disabled
> *.rc5		- rc5-git1, PCI domains disabled
> *.rc5-pcidom	- rc5-git1, PCI domains enabled
> 
> As the patch doesn't work, and the description is proven patently false, 
> maybe we can now consider reverting it and making a better patch?  My 
> Marvell SATA and MPT Fusion devices are no longer available, as a diff 
> between lspci.rc5 and lspci.rc5-pcidom demonstrates.

Do you have PCI segmentation disabled in your BIOS? 

iirc what the original submitters claimed is that it didn't boot
without that and this option. Maybe they didn't tell me the whole
story.

The problem is that most people cannot figure out how 
to disable this in the BIOS so we needed a way to make it boot
out of the box.

Booting without PCI-X is better than booting with it.

Maybe we should only do this if PCI segmentation is disabled? 

Folks, I would like to have a full confirmation what actually
doesn't work without pci=noacpi.

Thanks.

-Andi

Re: Recent x86-64 patch causes many devices to disappear

[Jeff Garzik]

Andi Kleen wrote:
> On Friday 26 May 2006 11:53, Jeff Garzik wrote:
>> *.rc4		- rc4, plus some libata changes, PCI domains disabled
>> *.rc5		- rc5-git1, PCI domains disabled
>> *.rc5-pcidom	- rc5-git1, PCI domains enabled

> Do you have PCI segmentation disabled in your BIOS? 

The strings "PCI domains disabled" and "PCI domains enabled" indicate 
the state of the BIOS setting, at the time the dumps were taken.

	Jeff

Re: Recent x86-64 patch causes many devices to disappear

[Jeff Garzik]

Jeff Garzik wrote:
> Andi Kleen wrote:
>> On Friday 26 May 2006 11:53, Jeff Garzik wrote:
>>> *.rc4        - rc4, plus some libata changes, PCI domains disabled
>>> *.rc5        - rc5-git1, PCI domains disabled
>>> *.rc5-pcidom    - rc5-git1, PCI domains enabled
> 
>> Do you have PCI segmentation disabled in your BIOS? 
> 
> The strings "PCI domains disabled" and "PCI domains enabled" indicate 
> the state of the BIOS setting, at the time the dumps were taken.

Further clarification:  the rc4 kernel was built and running prior to 
your pci=noacpi commit.

	Jeff

Re: Recent x86-64 patch causes many devices to disappear

[Jeff Garzik]

Andi Kleen wrote:
> The problem is that most people cannot figure out how 
> to disable this in the BIOS so we needed a way to make it boot
> out of the box.

Agreed.


> Booting without PCI-X is better than booting with it.

May I suppose you mean "booting without PCI-X is better than not booting 
at all" ?  Booting with PCI-X is obviously better.


> Maybe we should only do this if PCI segmentation is disabled? 

May I suppose you mean "only do pci=noacpi if PCI segmentation is 
enabled" ?  That was my original proposal in the thread, in fact.....

	Jeff

Re: Recent x86-64 patch causes many devices to disappear

[Andi Kleen]

On Friday 26 May 2006 12:29, Jeff Garzik wrote:
> Andi Kleen wrote:
> > The problem is that most people cannot figure out how 
> > to disable this in the BIOS so we needed a way to make it boot
> > out of the box.
> 
> Agreed.

Do you use SCSI on your box? According to Joachim booting with 
segmentation on and not pci=noacpi SCSI is not seen. And that's the 
default setup on the machine which made it unusable.

> 
> 
> > Booting without PCI-X is better than booting with it.
> 
> May I suppose you mean "booting without PCI-X is better than not booting 
> at all" ?  Booting with PCI-X is obviously better.

Yes.


-Andi

Re: Recent x86-64 patch causes many devices to disappear

[Jeff Garzik]

Andi Kleen wrote:
> On Friday 26 May 2006 12:29, Jeff Garzik wrote:
>> Andi Kleen wrote:
>>> The problem is that most people cannot figure out how 
>>> to disable this in the BIOS so we needed a way to make it boot
>>> out of the box.
>> Agreed.
> 
> Do you use SCSI on your box? According to Joachim booting with 
> segmentation on and not pci=noacpi SCSI is not seen. And that's the 
> default setup on the machine which made it unusable.

Here, I see:

	segmentation on + pci=noacpi == no SCSI
and additionally
	segmentation on + pci=noacpi == no sata_mv
and thus overall
	segmentation on + pci=noacpi == no PCI-X bus

(as the posted output on gtf.org shows)

Regards,

	Jeff

Re: Recent x86-64 patch causes many devices to disappear

[Thomas Renninger]

On Fri, 2006-05-26 at 07:08 -0400, Jeff Garzik wrote:
> Andi Kleen wrote:
> > On Friday 26 May 2006 12:29, Jeff Garzik wrote:
> >> Andi Kleen wrote:
> >>> The problem is that most people cannot figure out how 
> >>> to disable this in the BIOS so we needed a way to make it boot
> >>> out of the box.
> >> Agreed.
> > 
> > Do you use SCSI on your box? According to Joachim booting with 
> > segmentation on and not pci=noacpi SCSI is not seen. And that's the 
> > default setup on the machine which made it unusable.
> 
> Here, I see:
> 
> 	segmentation on + pci=noacpi == no SCSI
> and additionally
> 	segmentation on + pci=noacpi == no sata_mv
> and thus overall
> 	segmentation on + pci=noacpi == no PCI-X bus
> 
> (as the posted output on gtf.org shows)

Here are the results from Joachim (without the patch):
(from novell.bugzilla.com bug #82986):

segmentation enablee with no extra kernel params = not working
segmentation enabled with pci=noacpi = working
segmentation disabled with no extra kernel params = working
segmentation disabled with pci=noacpi = working

I'd say that only disabling when segmentation is enabled makes sense...,
however the devices should still appear.
I know there are a lot BIOS versions of this machines flying around.
Maybe everybody should check that the latest version is running, first?
I have:
BIOS Information
        Vendor: Hewlett-Packard
        Version: 786B9 v2.05
        Release Date: 01/26/2006

        Thomas