promise controller resource alloc problems with ~2.6.8

promise controller resource alloc problems with ~2.6.8

[CaT]

I have a Promise PDC20267 card in my desktop and whilst it works
in 2.6.8-rc2, it no longer functions beginning with at least 2.6.9-rc2.
Latest kernel I ran is 2.6.9-rc2-bk8 and it was still not available.

dmesg does mention it though as:

PDC20267: IDE controller at PCI slot 0000:00:0d.0
PCI: Found IRQ 11 for device 0000:00:0d.0
PCI: Unable to reserve I/O region #5:40@1080 for device 0000:00:0d.0

And that's as far as it gets.

-- 
    Red herrings strewn hither and yon.

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

On Mon, Sep 27, 2004 at 06:45:51PM +1000, CaT wrote:
> I have a Promise PDC20267 card in my desktop and whilst it works
> in 2.6.8-rc2, it no longer functions beginning with at least 2.6.9-rc2.
> Latest kernel I ran is 2.6.9-rc2-bk8 and it was still not available.
> 
> dmesg does mention it though as:
> 
> PDC20267: IDE controller at PCI slot 0000:00:0d.0
> PCI: Found IRQ 11 for device 0000:00:0d.0
> PCI: Unable to reserve I/O region #5:40@1080 for device 0000:00:0d.0
> 
> And that's as far as it gets.

Just tried it with rc3. Same deal. I can only access half my drives. :/

Any debugging that needs doing that I can do to help resolve this?

-- 
    Red herrings strewn hither and yon.

Re: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Mon, 27 Sep 2004, CaT wrote:
>
> I have a Promise PDC20267 card in my desktop and whilst it works
> in 2.6.8-rc2, it no longer functions beginning with at least 2.6.9-rc2.
> Latest kernel I ran is 2.6.9-rc2-bk8 and it was still not available.
> 
> dmesg does mention it though as:
> 
> PDC20267: IDE controller at PCI slot 0000:00:0d.0
> PCI: Found IRQ 11 for device 0000:00:0d.0
> PCI: Unable to reserve I/O region #5:40@1080 for device 0000:00:0d.0

Please send along /proc/ioports for both the working and the non-working 
version (that's assuming that you can boot far enough in the nw version 
to get it, of course, but the nw version is actually the more interesting 
one, so please try ;).

Also, does the attached patch (written by Shaohua Li based on suggestions 
by me) solve the problem? My suspicion is that ACPI tables do bad things, 
and that this might fix it..

		Linus

-----
===== drivers/acpi/motherboard.c 1.2 vs edited =====
--- 1.2/drivers/acpi/motherboard.c	2004-08-04 11:12:54 +08:00
+++ edited/drivers/acpi/motherboard.c	2004-08-31 11:28:27 +08:00
@@ -170,4 +170,8 @@ static int __init acpi_motherboard_init(
 	return 0;
 }
 
-subsys_initcall(acpi_motherboard_init);
+/**
+ * Reserve motherboard resources after PCI claim BARs,
+ * but before PCI assign resources for uninitialized PCI devices
+ */
+fs_initcall(acpi_motherboard_init);
===== drivers/pnp/system.c 1.10 vs edited =====
--- 1.10/drivers/pnp/system.c	2004-03-21 00:38:56 +08:00
+++ edited/drivers/pnp/system.c	2004-08-31 11:29:35 +08:00
@@ -104,4 +104,8 @@ static int __init pnp_system_init(void)
 	return pnp_register_driver(&system_pnp_driver);
 }
 
-subsys_initcall(pnp_system_init);
+/**
+ * Reserve motherboard resources after PCI claim BARs,
+ * but before PCI assign resources for uninitialized PCI devices
+ */
+fs_initcall(pnp_system_init);
===== arch/i386/pci/i386.c 1.17 vs edited =====
--- 1.17/arch/i386/pci/i386.c	2004-08-25 14:35:30 +08:00
+++ edited/arch/i386/pci/i386.c	2004-08-31 11:34:29 +08:00
@@ -164,7 +164,7 @@ static void __init pcibios_allocate_reso
 	}
 }
 
-static void __init pcibios_assign_resources(void)
+static int __init pcibios_assign_resources(void)
 {
 	struct pci_dev *dev = NULL;
 	int idx;
@@ -204,6 +204,7 @@ static void __init pcibios_assign_resour
 				pci_assign_resource(dev, PCI_ROM_RESOURCE);
 		}
 	}
+	return 0;
 }
 
 void __init pcibios_resource_survey(void)
@@ -212,8 +213,13 @@ void __init pcibios_resource_survey(void
 	pcibios_allocate_bus_resources(&pci_root_buses);
 	pcibios_allocate_resources(0);
 	pcibios_allocate_resources(1);
-	pcibios_assign_resources();
 }
+
+/**
+ * called in fs_initcall (one below subsys_initcall),
+ * give a chance for motherboard reserve resources
+ */
+fs_initcall(pcibios_assign_resources);
 
 int pcibios_enable_resources(struct pci_dev *dev, int mask)
 {

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

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

On Thu, Sep 30, 2004 at 04:21:10PM -0700, Linus Torvalds wrote:
> On Mon, 27 Sep 2004, CaT wrote:
> > dmesg does mention it though as:
> > 
> > PDC20267: IDE controller at PCI slot 0000:00:0d.0
> > PCI: Found IRQ 11 for device 0000:00:0d.0
> > PCI: Unable to reserve I/O region #5:40@1080 for device 0000:00:0d.0
> 
> Please send along /proc/ioports for both the working and the non-working 
> version (that's assuming that you can boot far enough in the nw version 
> to get it, of course, but the nw version is actually the more interesting 
> one, so please try ;).

I have the one from 2.6.9-rc2-bk8 available to me (last time I booted I
had time to grab lots of things) so I've attached that and the current
one. If you need the rc3 it'll need to wait another 8 hours or so as I'm
currently away from the PC.

> Also, does the attached patch (written by Shaohua Li based on suggestions 
> by me) solve the problem? My suspicion is that ACPI tables do bad things, 
> and that this might fix it..

Will try when I get home.

-- 
    Red herrings strewn hither and yon.

[-- Attachment #2: ioports-2.6.8-rc2 --]
[-- Type: text/plain, Size: 860 bytes --]

2.6.8-rc2:

0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-107f : 0000:00:0e.0
  1000-107f : 0000:00:0e.0
1080-10bf : 0000:00:0d.0
  1080-1087 : ide2
  1088-108f : ide3
  1090-10bf : PDC20267
10c0-10cf : 0000:00:14.1
  10c0-10c7 : ide0
  10c8-10cf : ide1
10f0-10f7 : 0000:00:0d.0
  10f0-10f7 : ide2
10f8-10ff : 0000:00:0d.0
  10f8-10ff : ide3
1400-14ff : 0000:00:0f.0
  1400-14ff : tulip
1800-1803 : 0000:00:0d.0
  1802-1802 : ide2
1804-1807 : 0000:00:0d.0
  1806-1806 : ide3
1820-183f : 0000:00:14.2
f800-f83f : 0000:00:14.3
fc00-fc1f : 0000:00:14.3

[-- Attachment #3: ioports-2.6.9-rc2-bk8 --]
[-- Type: text/plain, Size: 753 bytes --]

2.6.9-rc2-bk8:

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-107f : 0000:00:0e.0
  1000-107f : 0000:00:0e.0
1080-10bf : 0000:00:0d.0
  10a0-10af : 0000:00:14.1
    10a0-10a7 : ide0
    10a8-10af : ide1
10c0-10df : 0000:00:14.2
10f0-10f7 : 0000:00:0d.0
10f8-10ff : 0000:00:0d.0
1400-14ff : 0000:00:0f.0
  1400-14ff : tulip
1800-1803 : 0000:00:0d.0
1804-1807 : 0000:00:0d.0
f800-f83f : 0000:00:14.3
fc00-fc1f : 0000:00:14.3

Re: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Fri, 1 Oct 2004, CaT wrote:
> 
> I have the one from 2.6.9-rc2-bk8 available to me (last time I booted I
> had time to grab lots of things) so I've attached that and the current
> one. If you need the rc3 it'll need to wait another 8 hours or so as I'm
> currently away from the PC.

This is enough, I think, although I'd also like to get the output from 
/sbin/lspci just to clarify what the devices are.

In 2.6.8 (working), you had:

	1080-10bf : 0000:00:0d.0
	  1080-1087 : ide2
	  1088-108f : ide3
	  1090-10bf : PDC20267
	10c0-10cf : 0000:00:14.1
	  10c0-10c7 : ide0
	  10c8-10cf : ide1

while in the nonworking setup the PCI code allowed 0:14.1 to be allocated 
_inside_ device 0:0d.0, like this:

	1080-10bf : 0000:00:0d.0
	  10a0-10af : 0000:00:14.1
	    10a0-10a7 : ide0
	    10a8-10af : ide1

which looks rather bogus. In fact, it looks like the device was mis-setup 
by the BIOS, and that the PCI resource changes allowed that broken setup.

The reason for that is the change in "arch/i386/pci/i386.c" to use 
"insert_resource()" instead of "request_resource()", which in turn is 
because we wanted to insert PCI resources _inside_ the system resources 
reserved by ACPI.

HOWEVER, we do _not_ want to allow insertion of PCI resources inside other 
PCI resources, and while this normally shouldn't happen, it definitely can 
happen if the BIOS has set things up incorrectly in the first place. As 
appears to be the case in your setup.

Now, the reason for using "insert_resource()" in arch/i386/pci/i386.c 
should go away with Shaohua Li's patch, so I'd love to hear if applying 
Li's patch _and_ making the "insert_resource()" be a "request_resource()" 
fixes the problem for you.

I bet it will.

Greg, we kind of left the ACPI resource management breakage pending, and 
clearly we need some resolution. Comments?

		Linus

Re: promise controller resource alloc problems with ~2.6.8

[Greg KH]

On Thu, Sep 30, 2004 at 04:56:21PM -0700, Linus Torvalds wrote:
> 
> Greg, we kind of left the ACPI resource management breakage pending, and 
> clearly we need some resolution. Comments?

I added that patch to my bk trees, and it's sitting in the -mm tree now.
I wanted some testing, which I guess has happened, and no one has
complained yet, so if this proves to be another case where this patch
fixes things, I have no problem with it being applied.

But let's see the result of testing on this box first :)

thanks,

greg k-h

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

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

On Thu, Sep 30, 2004 at 04:56:21PM -0700, Linus Torvalds wrote:
> On Fri, 1 Oct 2004, CaT wrote:
> > 
> > I have the one from 2.6.9-rc2-bk8 available to me (last time I booted I
> > had time to grab lots of things) so I've attached that and the current
> > one. If you need the rc3 it'll need to wait another 8 hours or so as I'm
> > currently away from the PC.
> 
> This is enough, I think, although I'd also like to get the output from 
> /sbin/lspci just to clarify what the devices are.

Ok. I've got lspci -vvv for both bk8 and 8-rc2. They are slightly
different so I'm including them both.

> Now, the reason for using "insert_resource()" in arch/i386/pci/i386.c 
> should go away with Shaohua Li's patch, so I'd love to hear if applying 
> Li's patch _and_ making the "insert_resource()" be a "request_resource()" 
> fixes the problem for you.
> 
> I bet it will.

No problem. 7hrs to go. :)

-- 
    Red herrings strewn hither and yon.

[-- Attachment #2: lspci-2.6.8-rc2 --]
[-- Type: text/plain, Size: 5436 bytes --]

2.6.8-rc2:

0000:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
	Latency: 64
	Region 0: Memory at 44000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

0000:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	Memory behind bridge: 40000000-408fffff
	Prefetchable memory behind bridge: 41000000-41ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+

0000:00:0d.0 Unknown mass storage controller: Promise Technology, Inc. PDC20267 (FastTrak100/Ultra100) (rev 02)
	Subsystem: Promise Technology, Inc. Ultra100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 10f0 [size=8]
	Region 1: I/O ports at 1800 [size=4]
	Region 2: I/O ports at 10f8 [size=8]
	Region 3: I/O ports at 1804 [size=4]
	Region 4: I/O ports at 1080 [size=64]
	Region 5: Memory at 42000000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [58] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 1000 [size=128]
	Region 1: Memory at 40900000 (32-bit, non-prefetchable) [size=128]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0f.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
	Subsystem: Netgear FA310TX
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 66
	Interrupt: pin A routed to IRQ 9
	Region 0: I/O ports at 1400 [size=256]
	Region 1: Memory at 42100000 (32-bit, non-prefetchable) [size=256]

0000:00:14.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

0000:00:14.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Region 4: I/O ports at 10a0 [size=16]

0000:00:14.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin D routed to IRQ 0
	Region 4: I/O ports at 10c0 [disabled] [size=32]

0000:00:14.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin ? routed to IRQ 9

0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc. Millennium G200 AGP
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at 41000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at 40800000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at 40000000 (32-bit, non-prefetchable) [size=8M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>


[-- Attachment #3: lspci-2.6.9-rc2-bk8 --]
[-- Type: text/plain, Size: 5440 bytes --]

2.6.9-rc2-bk8:

0000:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
	Latency: 64
	Region 0: Memory at 44000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

0000:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	Memory behind bridge: 40000000-408fffff
	Prefetchable memory behind bridge: 41000000-41ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+

0000:00:0d.0 Unknown mass storage controller: Promise Technology, Inc. PDC20267 (FastTrak100/Ultra100) (rev 02)
	Subsystem: Promise Technology, Inc. Ultra100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 10f0 [size=8]
	Region 1: I/O ports at 1800 [size=4]
	Region 2: I/O ports at 10f8 [size=8]
	Region 3: I/O ports at 1804 [size=4]
	Region 4: I/O ports at 1080 [size=64]
	Region 5: Memory at 42000000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [58] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 1000 [size=128]
	Region 1: Memory at 40900000 (32-bit, non-prefetchable) [size=128]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0f.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
	Subsystem: Netgear FA310TX
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 66
	Interrupt: pin A routed to IRQ 9
	Region 0: I/O ports at 1400 [size=256]
	Region 1: Memory at 42100000 (32-bit, non-prefetchable) [size=256]

0000:00:14.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

0000:00:14.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Region 4: I/O ports at 10a0 [size=16]

0000:00:14.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin D routed to IRQ 0
	Region 4: I/O ports at 10c0 [disabled] [size=32]

0000:00:14.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin ? routed to IRQ 9

0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc. Millennium G200 AGP
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (4000ns min, 8000ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at 41000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at 40800000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at 40000000 (32-bit, non-prefetchable) [size=8M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

On Thu, Sep 30, 2004 at 04:56:21PM -0700, Linus Torvalds wrote:
> Now, the reason for using "insert_resource()" in arch/i386/pci/i386.c 
> should go away with Shaohua Li's patch, so I'd love to hear if applying 
> Li's patch _and_ making the "insert_resource()" be a "request_resource()" 
> fixes the problem for you.

You meant this, right?

if (!pr || insert_resource(pr, r) < 0)
	printk(KERN_ERR "PCI: Cannot allocate resource region %d of bridge %s\n", idx, pci_name(dev));

If so then the patch + the above did not work. :/

> Greg, we kind of left the ACPI resource management breakage pending, and 
> clearly we need some resolution. Comments?

BTW. I just realised (and I apologise for not doing so earlier) that I'm
not using ACPI on this box.

-- 
    Red herrings strewn hither and yon.

Re: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Fri, 1 Oct 2004, CaT wrote:
>
> You meant this, right?
> 
> if (!pr || insert_resource(pr, r) < 0)
> 	printk(KERN_ERR "PCI: Cannot allocate resource region %d of bridge %s\n", idx, pci_name(dev));

Yup.

> If so then the patch + the above did not work. :/

Damn. 

> BTW. I just realised (and I apologise for not doing so earlier) that I'm
> not using ACPI on this box.

For you, the bigger patch shouldn't have made any difference. But it's 
needed for some other people who have BIOS'es that mark PCI regions as 
being reserved for the motherboard, and they get resource conflicts 
otherwise (resource conflicts that largely go away with 
"insert_resource()", but if we want to change that to "request_resource()" 
then that other patch is needed).

Can you send me your ioports from 2.6.9-rc3 _with_ the 
"request_resource()" change..

		Linus

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

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

On Fri, Oct 01, 2004 at 07:34:34AM -0700, Linus Torvalds wrote:
> > BTW. I just realised (and I apologise for not doing so earlier) that I'm
> > not using ACPI on this box.
> 
> For you, the bigger patch shouldn't have made any difference. But it's 
> needed for some other people who have BIOS'es that mark PCI regions as 
> being reserved for the motherboard, and they get resource conflicts 
> otherwise (resource conflicts that largely go away with 
> "insert_resource()", but if we want to change that to "request_resource()" 
> then that other patch is needed).

Aha.

> Can you send me your ioports from 2.6.9-rc3 _with_ the 
> "request_resource()" change..

Diff says that the file is thesame as the one without patch+change
that doesn't work.

Attached none-the-less.

-- 
    Red herrings strewn hither and yon.

[-- Attachment #2: ioports.2.6.9-rc3 --]
[-- Type: text/plain, Size: 737 bytes --]

0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-107f : 0000:00:0e.0
  1000-107f : 0000:00:0e.0
1080-10bf : 0000:00:0d.0
  10a0-10af : 0000:00:14.1
    10a0-10a7 : ide0
    10a8-10af : ide1
10c0-10df : 0000:00:14.2
10f0-10f7 : 0000:00:0d.0
10f8-10ff : 0000:00:0d.0
1400-14ff : 0000:00:0f.0
  1400-14ff : tulip
1800-1803 : 0000:00:0d.0
1804-1807 : 0000:00:0d.0
f800-f83f : 0000:00:14.3
fc00-fc1f : 0000:00:14.3

Re: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Sat, 2 Oct 2004, CaT wrote:
> 
> > Can you send me your ioports from 2.6.9-rc3 _with_ the 
> > "request_resource()" change..
> 
> Diff says that the file is thesame as the one without patch+change
> that doesn't work.

That's really wrong. Hmm.. Can you enable debugging for the PCI resource 
stuff? It's DEBUG_CONFIG in drivers/pci/setup-res.c, and DEBUG in 
arch/i386/pci/pci.h, and now your dmesg should be a lot more verbose about 
the bootup resources..

Also (independently - I really do want to see the debug info) can you try
making the "drivers/pci/setup-res.c" version of "insert_resource()" be a
request_resource() too?

Thanks,

		Linus

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

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

Sorry for the delay in getting back. Long weekend + RL tied things up.

On Sat, Oct 02, 2004 at 12:17:48PM -0700, Linus Torvalds wrote:
> On Sat, 2 Oct 2004, CaT wrote:
> > > Can you send me your ioports from 2.6.9-rc3 _with_ the 
> > > "request_resource()" change..
> > 
> > Diff says that the file is thesame as the one without patch+change
> > that doesn't work.
> 
> That's really wrong. Hmm.. Can you enable debugging for the PCI resource 
> stuff? It's DEBUG_CONFIG in drivers/pci/setup-res.c, and DEBUG in 
> arch/i386/pci/pci.h, and now your dmesg should be a lot more verbose about 
> the bootup resources..

I did this:

./setup-res.c:#define DEBUG_CONFIG 1
./pci.h:#define DEBUG

dmesg attached.

> Also (independently - I really do want to see the debug info) can you try
> making the "drivers/pci/setup-res.c" version of "insert_resource()" be a
> request_resource() too?

No change. :/

-- 
    Red herrings strewn hither and yon.

[-- Attachment #2: dmesg.debug --]
[-- Type: text/plain, Size: 8707 bytes --]

Linux version 2.6.9-rc3 (root@nessie) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #12 Fri Oct 8 09:58:38 EST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001c000000 (usable)
 BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
448MB LOWMEM available.
On node 0 totalpages: 114688
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 110592 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.1 present.
Built 1 zonelists
Kernel command line: auto BOOT_IMAGE=l ro root=302
Initializing CPU#0
CPU 0 irqstacks, hard=c04f6000 soft=c04f5000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 348.301 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 449816k/458752k available (2713k kernel code, 8456k reserved, 917k data, 396k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 686.08 BogoMIPS (lpj=343040)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000
CPU: After vendor identify, caps:  0183f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps:        0183f9ff 00000000 00000000 00000040
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
NET: Registered protocol family 16
PCI: BIOS32 Service Directory structure at 0xc00fa000
PCI: BIOS32 Service Directory entry at 0xec700
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xed728, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: IDE base address fixup for 0000:00:14.1
PCI: Scanning for ghost devices on bus 0
PCI: Scanning for ghost devices on bus 1
PCI: Peer bridge fixup
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f7050
00:0d slot=01 0:60/0ef8 1:61/0ef8 2:62/0ef8 3:63/0ef8
00:0e slot=02 0:61/0ef8 1:62/0ef8 2:63/0ef8 3:60/0ef8
00:0f slot=03 0:62/0ef8 1:63/0ef8 2:60/0ef8 3:61/0ef8
00:10 slot=04 0:63/0ef8 1:60/0ef8 2:61/0ef8 3:62/0ef8
00:14 slot=00 0:00/0000 1:00/0000 2:00/0000 3:63/0ef8
00:01 slot=00 0:62/0ef8 1:63/0ef8 2:00/0000 3:00/0000
PCI: Attempting to find IRQ router for 0000:0000
PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:14.0
PCI: IRQ fixup
0000:00:14.2: ignoring bogus IRQ 255
IRQ for 0000:00:14.2:3 -> PIRQ 63, mask 0ef8, excl 0000<4>PCI: IRQ 0 for device 0000:00:14.2 doesn't match PIRQ mask - try pci=usepirqmask
 -> newirq=0 ... failed
PCI: Allocating resources
PCI: Resource 44000000-47ffffff (f=1208, d=0, p=0)
PCI: Resource 000010f0-000010f7 (f=101, d=0, p=0)
PCI: Resource 00001800-00001803 (f=101, d=0, p=0)
PCI: Resource 000010f8-000010ff (f=101, d=0, p=0)
PCI: Resource 00001804-00001807 (f=101, d=0, p=0)
PCI: Resource 00001080-000010bf (f=101, d=0, p=0)
PCI: Resource 42000000-4201ffff (f=200, d=0, p=0)
PCI: Resource 00001000-0000107f (f=101, d=0, p=0)
PCI: Resource 40900000-4090007f (f=200, d=0, p=0)
PCI: Resource 00001400-000014ff (f=101, d=0, p=0)
PCI: Resource 42100000-421000ff (f=200, d=0, p=0)
PCI: Resource 000010a0-000010af (f=101, d=0, p=0)
PCI: Resource 41000000-41ffffff (f=1208, d=0, p=0)
PCI: Resource 40800000-40803fff (f=200, d=0, p=0)
PCI: Resource 40000000-407fffff (f=200, d=0, p=0)
PCI: Sorting device list...
TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca)
  got res [10c0:10df] bus [10c0:10df] flags 101 for BAR 4 of 0000:00:14.2
PCI: moved device 0000:00:14.2 resource 4 (101) to 10c0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
lp0: console ready
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
loop: loaded (max 8 devices)
IRQ for 0000:00:0e.0:0 -> PIRQ 61, mask 0ef8, excl 0000 -> newirq=10 -> got IRQ 10
PCI: Found IRQ 10 for device 0000:00:0e.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:00:0e.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
e100: Intel(R) PRO/100 Network Driver, 3.0.27-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
NET: Registered protocol family 24
Linux Tulip driver version 1.1.13 (May 11, 2002)
IRQ for 0000:00:0f.0:0 -> PIRQ 62, mask 0ef8, excl 0000 -> newirq=9 -> got IRQ 9
PCI: Found IRQ 9 for device 0000:00:0f.0
tulip0:  MII transceiver #1 config 3000 status 7829 advertising 01e1.
eth1: Lite-On 82c168 PNIC rev 32 at 0xdc80e000, 00:A0:CC:64:35:FF, IRQ 9.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20267: IDE controller at PCI slot 0000:00:0d.0
IRQ for 0000:00:0d.0:0 -> PIRQ 60, mask 0ef8, excl 0000 -> newirq=11 -> got IRQ 11
PCI: Found IRQ 11 for device 0000:00:0d.0
PCI: Unable to reserve I/O region #5:40@1080 for device 0000:00:0d.0
PIIX4: IDE controller at PCI slot 0000:00:14.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x10a0-0x10a7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x10a8-0x10af, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: SAMSUNG SV1022D, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: AOPEN CD-RW CRW3248 1.12 20020417, ATAPI CD/DVD-ROM drive
hdd: QUANTUM FIREBALLlct20 10, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 19931184 sectors (10204 MB) w/472KiB Cache, CHS=19773/16/63
hda: cache flushes not supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 >
hdd: max request size: 128KiB
hdd: 20044080 sectors (10262 MB) w/418KiB Cache, CHS=19885/16/63
hdd: cache flushes not supported
 hdd: hdd1 hdd2
hdc: ATAPI 48X CD-ROM CD-R/RW drive, 8192kB Cache
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
GACT probability on
u32 classifier
    Perfomance counters on
    Actions configured 
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
ip_conntrack version 2.1 (3584 buckets, 28672 max) - 332 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.  http://snowman.net/projects/ipt_recent/
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
ip6_tables: (C) 2000-2002 Netfilter core team
registering ipv6 mark target
NET: Registered protocol family 17
NET: Registered protocol family 15
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 396k freed
Adding 506008k swap on /dev/hda5.  Priority:-1 extents:1
EXT3 FS on hda2, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdd1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdd2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Disabled Privacy Extensions on device c0426840(lo)

Re: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Sun, 10 Oct 2004, CaT wrote:
> > 
> > That's really wrong. Hmm.. Can you enable debugging for the PCI resource 
> > stuff? It's DEBUG_CONFIG in drivers/pci/setup-res.c, and DEBUG in 
> > arch/i386/pci/pci.h, and now your dmesg should be a lot more verbose about 
> > the bootup resources..
> 
> I did this:
> 
> ./setup-res.c:#define DEBUG_CONFIG 1
> ./pci.h:#define DEBUG
> 
> dmesg attached.

Thanks. This is really _really_ confusing. Your dmesg clearly says:

	PCI: Resource 44000000-47ffffff (f=1208, d=0, p=0)
	PCI: Resource 000010f0-000010f7 (f=101, d=0, p=0)
	PCI: Resource 00001800-00001803 (f=101, d=0, p=0)
	PCI: Resource 000010f8-000010ff (f=101, d=0, p=0)
	PCI: Resource 00001804-00001807 (f=101, d=0, p=0)
	PCI: Resource 00001080-000010bf (f=101, d=0, p=0)	*****
	PCI: Resource 42000000-4201ffff (f=200, d=0, p=0)
	PCI: Resource 00001000-0000107f (f=101, d=0, p=0)
	PCI: Resource 40900000-4090007f (f=200, d=0, p=0)
	PCI: Resource 00001400-000014ff (f=101, d=0, p=0)
	PCI: Resource 42100000-421000ff (f=200, d=0, p=0)
	PCI: Resource 000010a0-000010af (f=101, d=0, p=0)	*****
	PCI: Resource 41000000-41ffffff (f=1208, d=0, p=0)
	PCI: Resource 40800000-40803fff (f=200, d=0, p=0)
	PCI: Resource 40000000-407fffff (f=200, d=0, p=0)

note how the two resources I marked should have clashed, and if you had a
"request_resource()" in the loop that prints this out, then the code
_should_ have looked like this:

				....
                                DBG("PCI: Resource %08lx-%08lx (f=%lx, d=%d, p=%d)\n",
                                    r->start, r->end, r->flags, disabled, pass);
                                pr = pci_find_parent_resource(dev, r);
                                if (!pr || request_resource(pr, r) < 0) {
                                        printk(KERN_ERR "PCI: Cannot allocate resource region %d of device %s\n", idx, pci_name(dev));
                                        /* We'll assign a new address later */
                                        r->end -= r->start;
                                        r->start = 0;
				....

ie _immediately_ after the thing that prints out the resource, you have a 
"request_resource()" that should have _clashed_ with an earlier one, 
dammit!

And "request_resource()" hasn't actually changed lately (insert_resource() 
_did_ change), so I don't understand why it's now broken for you.

Can you add another DBG() statement to just after the

	pr = pci_find_parent_resource(..)

line? One that proints out the parent resource, ie just something like

	DBG("Parent resource: %08lx-%08lx (%lx)", pr->start, pr->end, pr->flags);

to see if the code somehow gets _really_ confused, and thinks that the
earlier clashing resource is actually the parent resource (it's definitely
not - the resource at 1080 is PCI device 0:0d.0, which is your promise IDE
controller).

I wonder if request_resource() is broken. "insert_resource()" had been 
broken for a _loong_ time (since its inception), maybe 
"request_resource()" also is. Hmm..

Greg, do you see something I've missed? I feel stupid.

		Linus

Re: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Sat, 9 Oct 2004, Linus Torvalds wrote:
> 
> I wonder if request_resource() is broken. "insert_resource()" had been 
> broken for a _loong_ time (since its inception), maybe 
> "request_resource()" also is. Hmm..

I tested your resource list with my user-level resource test harness, and 
it definitely returned EBUSY for the clashing resource. So either you have 
something strange going on with finding the parent resource (the DBG() 
statement in the previous email should hopefully tell), or there's 
something else going on.

I'd suspect you had some clock drift problems and the i386.c file didn't
actually get recompiled when you changed it to "request_resource()", but
since the DBG() output shows up in your dmesg, that doesn't seem to
explain it either - the file clearly _did_ get recompiled for the debug
output.

Maybe the parent resource thing shows some smoking gun.

		Linus

Re: promise controller resource alloc problems with ~2.6.8

[Greg KH]

On Sat, Oct 09, 2004 at 08:15:07PM -0700, Linus Torvalds wrote:
> 
> I wonder if request_resource() is broken. "insert_resource()" had been 
> broken for a _loong_ time (since its inception), maybe 
> "request_resource()" also is. Hmm..
> 
> Greg, do you see something I've missed? I feel stupid.

I don't see anything either :(

greg k-h

RE: promise controller resource alloc problems with ~2.6.8

[Li, Shaohua]

>On Thu, Sep 30, 2004 at 04:56:21PM -0700, Linus Torvalds wrote:
>> Now, the reason for using "insert_resource()" in arch/i386/pci/i386.c
>> should go away with Shaohua Li's patch, so I'd love to hear if
applying
>> Li's patch _and_ making the "insert_resource()" be a
"request_resource()"
>> fixes the problem for you.
>
>You meant this, right?
>
>if (!pr || insert_resource(pr, r) < 0)
>	printk(KERN_ERR "PCI: Cannot allocate resource region %d of
bridge
 
^^^^^^^^^
>%s\n", idx, pci_name(dev));
I go through the thread again and I guess you changed the wrong place. 
in line 114:
				if (!pr || request_resource(pr, r) < 0)
					printk(KERN_ERR "PCI: Cannot
allocate resource region %d of bridge %s\n", idx, pci_name(dev));

In line 145:
		if (!pr || insert_resource(pr, r) < 0) {
					printk(KERN_ERR "PCI: Cannot
allocate resource region %d of device %s\n", idx, pci_name(dev));
Please don't touch line 114, and change 'insert_resource' to '
request_resource' in line 145. Sorry for my bad mail client.

Thanks,
Shaohua

RE: promise controller resource alloc problems with ~2.6.8

[Linus Torvalds]

On Sun, 10 Oct 2004, Li, Shaohua wrote:

> >On Thu, Sep 30, 2004 at 04:56:21PM -0700, Linus Torvalds wrote:
> >> Now, the reason for using "insert_resource()" in arch/i386/pci/i386.c
> >> should go away with Shaohua Li's patch, so I'd love to hear if
> applying
> >> Li's patch _and_ making the "insert_resource()" be a
> "request_resource()"
> >> fixes the problem for you.
> >
> >You meant this, right?
> >
> >if (!pr || insert_resource(pr, r) < 0)
> >	printk(KERN_ERR "PCI: Cannot allocate resource region %d of bridge
>  
> ^^^^^^^^^
> >%s\n", idx, pci_name(dev));
> I go through the thread again and I guess you changed the wrong place. 

Ahh.. Yes. I was confused, because there is only one "insert_region()" 
ain arch/i386/pci/i386.c, so I just automatically assumed CaT changed that 
one without looking at the details.

So if CaT changed the "request_resource()" in to an "insert_resource()"
in pcibios_allocate_bus_resources(), then that explains the impossible
dmesg.

Cat: change that one back, and the function to look at is
"pcibios_allocate_resources()" (almost the same name, but no "bus" in it),
which has a "insert_resource()" in it. That "insert_resource()" should be
a "request_resource()" (and for you it won't matter, but other people will
likely want to additionally apply Shaohua's patch to put in ACPI resources
last).

Hope this clears it all up. Knock wood.

		Linus

Re: promise controller resource alloc problems with ~2.6.8

[CaT]

On Sun, Oct 10, 2004 at 10:00:32AM -0700, Linus Torvalds wrote:
> which has a "insert_resource()" in it. That "insert_resource()" should be
> a "request_resource()" (and for you it won't matter, but other people will
> likely want to additionally apply Shaohua's patch to put in ACPI resources
> last).
> 
> Hope this clears it all up. Knock wood.

Well with all the fun and the mind bendiness of the results of my
earlier tests I thought that there might be a slim chance that something
got buggered up with the lifetime of patching that particular kernel
tree got on my system and since rc4 was out I decided to start afresh.

I untarred 2.6.5, patched to 2.6.9-rc4, turned on the PCI debugging as
per request, compiled and rebooted. End result?

PDC20267: IDE controller at PCI slot 0000:00:0d.0
IRQ for 0000:00:0d.0:0 -> PIRQ 60, mask 0ef8, excl 0000 -> newirq=11 -> got IRQ 11
PCI: Found IRQ 11 for device 0000:00:0d.0
PDC20267: chipset revision 2
PDC20267: 100% native mode on irq 11
PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
    ide2: BM-DMA at 0x1080-0x1087, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0x1088-0x108f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: IC35L060AVV207-0, ATA DISK drive
ide2 at 0x10f0-0x10f7,0x1802 on irq 11
Probing IDE interface ide3...
hdh: ST3200822A, ATA DISK drive
ide3 at 0x10f8-0x10ff,0x1806 on irq 11

It worked!

Now thinking that I may have just right royally buggered up I compiled
rc3 again, starting from a totally fresh tree like I did with rc4 and
the problem was still there. No promise card. (phew... kinda)

So basically, something got fixed between rc3 and rc4. Personally, I
call shenanigans.

-- 
    Red herrings strewn hither and yon.

Re: promise controller resource alloc problems with ~2.6.8

[Greg KH]

On Tue, Oct 12, 2004 at 10:52:02PM +1000, CaT wrote:
> 
> So basically, something got fixed between rc3 and rc4. Personally, I
> call shenanigans.

Heh, no, Linus applied the patch to the tree for rc4, so you just proved
that the fix works for your box :)

thanks,

greg k-h