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.
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.
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)
{
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.
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
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
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.
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.
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
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.
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
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.
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
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
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
>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
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
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.
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