* RE: promise controller resource alloc problems with ~2.6.8 @ 2004-10-10 5:28 Li, Shaohua 2004-10-10 17:00 ` Linus Torvalds 0 siblings, 1 reply; 19+ messages in thread From: Li, Shaohua @ 2004-10-10 5:28 UTC (permalink / raw) To: CaT, Linus Torvalds Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz >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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: promise controller resource alloc problems with ~2.6.8 2004-10-10 5:28 promise controller resource alloc problems with ~2.6.8 Li, Shaohua @ 2004-10-10 17:00 ` Linus Torvalds 2004-10-12 12:52 ` CaT 0 siblings, 1 reply; 19+ messages in thread From: Linus Torvalds @ 2004-10-10 17:00 UTC (permalink / raw) To: Li, Shaohua; +Cc: CaT, Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-10 17:00 ` Linus Torvalds @ 2004-10-12 12:52 ` CaT 2004-10-12 16:03 ` Greg KH 0 siblings, 1 reply; 19+ messages in thread From: CaT @ 2004-10-12 12:52 UTC (permalink / raw) To: Linus Torvalds Cc: Li, Shaohua, Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-12 12:52 ` CaT @ 2004-10-12 16:03 ` Greg KH 0 siblings, 0 replies; 19+ messages in thread From: Greg KH @ 2004-10-12 16:03 UTC (permalink / raw) To: CaT Cc: Linus Torvalds, Li, Shaohua, Kernel Mailing List, Bartlomiej Zolnierkiewicz 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* promise controller resource alloc problems with ~2.6.8
@ 2004-09-27 8:45 CaT
2004-09-30 23:03 ` CaT
2004-09-30 23:21 ` Linus Torvalds
0 siblings, 2 replies; 19+ messages in thread
From: CaT @ 2004-09-27 8:45 UTC (permalink / raw)
To: linux-kernel; +Cc: greg, B.Zolnierkiewicz
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: promise controller resource alloc problems with ~2.6.8 2004-09-27 8:45 CaT @ 2004-09-30 23:03 ` CaT 2004-09-30 23:21 ` Linus Torvalds 1 sibling, 0 replies; 19+ messages in thread From: CaT @ 2004-09-30 23:03 UTC (permalink / raw) To: linux-kernel; +Cc: greg, B.Zolnierkiewicz 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-09-27 8:45 CaT 2004-09-30 23:03 ` CaT @ 2004-09-30 23:21 ` Linus Torvalds 2004-09-30 23:30 ` CaT 1 sibling, 1 reply; 19+ messages in thread From: Linus Torvalds @ 2004-09-30 23:21 UTC (permalink / raw) To: CaT; +Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua 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) { ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-09-30 23:21 ` Linus Torvalds @ 2004-09-30 23:30 ` CaT 2004-09-30 23:56 ` Linus Torvalds 0 siblings, 1 reply; 19+ messages in thread From: CaT @ 2004-09-30 23:30 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-09-30 23:30 ` CaT @ 2004-09-30 23:56 ` Linus Torvalds 2004-10-01 0:14 ` Greg KH ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Linus Torvalds @ 2004-09-30 23:56 UTC (permalink / raw) To: CaT; +Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-09-30 23:56 ` Linus Torvalds @ 2004-10-01 0:14 ` Greg KH 2004-10-01 1:23 ` CaT 2004-10-01 10:30 ` CaT 2 siblings, 0 replies; 19+ messages in thread From: Greg KH @ 2004-10-01 0:14 UTC (permalink / raw) To: Linus Torvalds Cc: CaT, Kernel Mailing List, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-09-30 23:56 ` Linus Torvalds 2004-10-01 0:14 ` Greg KH @ 2004-10-01 1:23 ` CaT 2004-10-01 10:30 ` CaT 2 siblings, 0 replies; 19+ messages in thread From: CaT @ 2004-10-01 1:23 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua [-- 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-09-30 23:56 ` Linus Torvalds 2004-10-01 0:14 ` Greg KH 2004-10-01 1:23 ` CaT @ 2004-10-01 10:30 ` CaT 2004-10-01 14:34 ` Linus Torvalds 2 siblings, 1 reply; 19+ messages in thread From: CaT @ 2004-10-01 10:30 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, 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)); 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-01 10:30 ` CaT @ 2004-10-01 14:34 ` Linus Torvalds 2004-10-02 4:57 ` CaT 0 siblings, 1 reply; 19+ messages in thread From: Linus Torvalds @ 2004-10-01 14:34 UTC (permalink / raw) To: CaT; +Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-01 14:34 ` Linus Torvalds @ 2004-10-02 4:57 ` CaT 2004-10-02 19:17 ` Linus Torvalds 0 siblings, 1 reply; 19+ messages in thread From: CaT @ 2004-10-02 4:57 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua [-- 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-02 4:57 ` CaT @ 2004-10-02 19:17 ` Linus Torvalds 2004-10-10 2:19 ` CaT 0 siblings, 1 reply; 19+ messages in thread From: Linus Torvalds @ 2004-10-02 19:17 UTC (permalink / raw) To: CaT; +Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-02 19:17 ` Linus Torvalds @ 2004-10-10 2:19 ` CaT 2004-10-10 3:15 ` Linus Torvalds 0 siblings, 1 reply; 19+ messages in thread From: CaT @ 2004-10-10 2:19 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua [-- 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) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-10 2:19 ` CaT @ 2004-10-10 3:15 ` Linus Torvalds 2004-10-10 3:30 ` Linus Torvalds 2004-10-10 4:51 ` Greg KH 0 siblings, 2 replies; 19+ messages in thread From: Linus Torvalds @ 2004-10-10 3:15 UTC (permalink / raw) To: CaT; +Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-10 3:15 ` Linus Torvalds @ 2004-10-10 3:30 ` Linus Torvalds 2004-10-10 4:51 ` Greg KH 1 sibling, 0 replies; 19+ messages in thread From: Linus Torvalds @ 2004-10-10 3:30 UTC (permalink / raw) To: CaT; +Cc: Kernel Mailing List, Greg KH, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: promise controller resource alloc problems with ~2.6.8 2004-10-10 3:15 ` Linus Torvalds 2004-10-10 3:30 ` Linus Torvalds @ 2004-10-10 4:51 ` Greg KH 1 sibling, 0 replies; 19+ messages in thread From: Greg KH @ 2004-10-10 4:51 UTC (permalink / raw) To: Linus Torvalds Cc: CaT, Kernel Mailing List, Bartlomiej Zolnierkiewicz, Li, Shaohua 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2004-10-12 16:05 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-10-10 5:28 promise controller resource alloc problems with ~2.6.8 Li, Shaohua 2004-10-10 17:00 ` Linus Torvalds 2004-10-12 12:52 ` CaT 2004-10-12 16:03 ` Greg KH -- strict thread matches above, loose matches on Subject: below -- 2004-09-27 8:45 CaT 2004-09-30 23:03 ` CaT 2004-09-30 23:21 ` Linus Torvalds 2004-09-30 23:30 ` CaT 2004-09-30 23:56 ` Linus Torvalds 2004-10-01 0:14 ` Greg KH 2004-10-01 1:23 ` CaT 2004-10-01 10:30 ` CaT 2004-10-01 14:34 ` Linus Torvalds 2004-10-02 4:57 ` CaT 2004-10-02 19:17 ` Linus Torvalds 2004-10-10 2:19 ` CaT 2004-10-10 3:15 ` Linus Torvalds 2004-10-10 3:30 ` Linus Torvalds 2004-10-10 4:51 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox