Bug 646027 - BAR 0: can't assign mem (size 0x10000)
Summary: BAR 0: can't assign mem (size 0x10000)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-23 20:20 UTC by Fabrice Bellet
Modified: 2011-02-06 18:42 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-02-06 18:42:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg without resource_alloc_from_bottom (29.95 KB, text/plain)
2010-10-25 16:30 UTC, Fabrice Bellet
no flags Details
dmesg with resource_alloc_from_bottom (32.11 KB, text/plain)
2010-10-25 16:31 UTC, Fabrice Bellet
no flags Details
/proc/iomem without resource_alloc_from_bottom (931 bytes, text/plain)
2010-10-25 16:32 UTC, Fabrice Bellet
no flags Details
/proc/iomem with resource_alloc_from_bottom (1.13 KB, text/plain)
2010-10-25 16:33 UTC, Fabrice Bellet
no flags Details
replacement for [v4 2/6] patch (7.14 KB, patch)
2010-10-25 20:44 UTC, Bjorn Helgaas
no flags Details | Diff
dmesg with a custom .41 kernel where the modified patch is applied (32.17 KB, text/plain)
2010-10-26 11:13 UTC, Fabrice Bellet
no flags Details

Description Fabrice Bellet 2010-10-23 20:20:17 UTC
Something changed between kernel-2.6.36-0.40.rc8.git0.fc15.i686 and kernel-2.6.36-0.41.rc8.git5.fc15.i686, that prevents pcmcia to work on my old thinkpad 770Z:

 yenta_cardbus 0000:00:02.0: CardBus bridge found [1014:00eb]
+yenta_cardbus 0000:00:02.0: no resource of type 2200 available, trying to continue...
 yenta_cardbus 0000:00:02.0: no resource of type 200 available, trying to continue...
-yenta_cardbus 0000:00:02.0: CardBus bridge to [bus 02-05]
-yenta_cardbus 0000:00:02.0:   bridge window [io  0xf800-0xf8ff]
-yenta_cardbus 0000:00:02.0:   bridge window [io  0xf400-0xf4ff]
-yenta_cardbus 0000:00:02.0:   bridge window [mem 0x14000000-0x143fffff]
 yenta_cardbus 0000:00:02.0: Enabling burst memory read transactions
 yenta_cardbus 0000:00:02.0: Using CSCINT to route CSC interrupts to PCI
 yenta_cardbus 0000:00:02.0: Routing CardBus interrupts to PCI
 yenta_cardbus 0000:00:02.0: TI: mfunc 0xfba97543, devctl 0x62
 yenta_cardbus 0000:00:02.0: ISA IRQ mask 0x0000, PCI irq 11
 yenta_cardbus 0000:00:02.0: Socket status: 30000820
[...]
 yenta_cardbus 0000:00:02.1: Socket status: 30000006
 pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
 pci 0000:02:00.0: reg 10: [mem 0x00000000-0x0000ffff]
-pci 0000:02:00.0: BAR 0: assigned [mem 0x143f0000-0x143fffff]
-pci 0000:02:00.0: BAR 0: set to [mem 0x143f0000-0x143fffff] (PCI address [0x143f0000-0x143fffff]
+pci 0000:02:00.0: BAR 0: can't assign mem (size 0x10000)
[...]

Comment 1 Fabrice Bellet 2010-10-23 20:45:12 UTC
... and adding 'resource_alloc_from_bottom' makes it work.

Comment 2 Bjorn Helgaas 2010-10-25 15:27:19 UTC
Thanks, Fabrice.  Would you mind attaching the complete dmesg logs from .41, with and without "resource_alloc_from_bottom"?  Also, the /proc/iomem contents would be useful.

We failed to assign resources to the CardBus bridge, and that probably depends on how other resources are being assigned.

Comment 3 Fabrice Bellet 2010-10-25 16:30:59 UTC
Created attachment 455573 [details]
dmesg without resource_alloc_from_bottom

Comment 4 Fabrice Bellet 2010-10-25 16:31:37 UTC
Created attachment 455574 [details]
dmesg with resource_alloc_from_bottom

Comment 5 Fabrice Bellet 2010-10-25 16:32:29 UTC
Created attachment 455575 [details]
/proc/iomem without resource_alloc_from_bottom

Comment 6 Fabrice Bellet 2010-10-25 16:33:10 UTC
Created attachment 455576 [details]
/proc/iomem with resource_alloc_from_bottom

Comment 7 Bjorn Helgaas 2010-10-25 20:40:19 UTC
Is this a 32-bit kernel with CONFIG_X86_PAE=n?  That would make resource_size_t a 32-bit item, and the ALIGN() in find_resource_from_top() would wrap around.

I think this is a problem with the original find_resource(), too, but it'd be really hard to hit it there.

Why are you booting with "acpi=off"?  We don't really support that, and I'm interested in whether that's really required on this box.  I suspect that if you boot with ACPI enabled and "pci=use_crs", it would probably mask this pcmcia problem.

But that's a separate issue, and this allocation failure is a real bug I need to fix.  What's the best way to test a fix?  I'd like to test it on your box before reposting the upstream series, in case I don't get it right the first time.

Basically I want this pigdin patch in kernel/resource.c, find_resource_from_top():

-                tmp.start = ALIGN(tmp.start, align);
+                start = ALIGN(tmp.start, align);
+                if (start >= tmp.start)
+                        tmp.start = start;
+                else
+                        tmp.start = tmp.end;    /* wrapped around; fail */

I'll attach a proper patch that replaces this one:

    [PATCH v4 2/6] resources: support allocating space within a region from the top down

Comment 8 Bjorn Helgaas 2010-10-25 20:44:01 UTC
Created attachment 455621 [details]
replacement for [v4 2/6] patch

Here it is.  This is a replacement for patch [v4 2/6]:
http://marc.info/?l=linux-pci&m=128709839905614&w=2

Comment 9 Fabrice Bellet 2010-10-26 11:13:03 UTC
Created attachment 455738 [details]
dmesg with a custom .41 kernel where the modified patch is applied

I confirm that this updated patch works for me! 

About acpi=off, I have to disable acpi because it causes problems with PCI interrupts, reported as value 0 by the BIOS, and (consequently?) it fails to setup the CardBus support properly:

ACPI: PCI Interrupt Link [LNKA] disabled and referenced, BIOS bug
ACPI: PCI Interrupt Link [LNKA] BIOS reported IRQ 0, using IRQ 9
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 9
[...]
yenta_cardbus 0000:00:02.1: TI: probing PCI interrupt failed, trying to fix
yenta_cardbus 0000:00:02.1: TI: no PCI interrupts. Fish. Please report.
yenta_cardbus 0000:00:02.1: no PCI IRQ, CardBus support disabled for this socket.
yenta_cardbus 0000:00:02.1: check your BIOS CardBus, BIOS IRQ or ACPI settings.
yenta_cardbus 0000:00:02.1: ISA IRQ mask 0x0000, PCI irq 0
yenta_cardbus 0000:00:02.1: Socket status: 30000006

I could eventually open a separate bug report for this case. But as this laptop is almost an antiquity thing (a thinkpad of the 1999 era!), it is not a surprise to me, if acpi support on this box is buggy.

Comment 10 Bjorn Helgaas 2010-10-26 12:55:49 UTC
Great, thanks a lot for testing this!  I will repost the series today.

Re: acpi=off, it is hard to justify working on such an old platform.  However, it's still interesting because we have to assume that Windows does work on it and does use ACPI.  That would mean Windows interprets the PCI interrupt links differently than Linux, and that could be an issue even on newer boxes.

Do you have any clues about whether Windows on that box uses ACPI?

Comment 11 Chuck Ebbert 2011-02-02 06:46:00 UTC
Is this bug fixed?

Comment 12 Fabrice Bellet 2011-02-06 11:10:49 UTC
Yes, it works fine with kernel-2.6.38-0.rc3.git4.1.fc15.i686, without adding the resource_alloc_from_bottom option. Thanks to all the people who worked on this case!


Note You need to log in before you can comment on or make changes to this bug.