Bug 646027
| Summary: | BAR 0: can't assign mem (size 0x10000) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fabrice Bellet <fabrice> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | bjorn.helgaas, dougsland, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, sreenivasa-reddy.berahalli |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-02-06 18:42:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Fabrice Bellet
2010-10-23 20:20:17 UTC
... and adding 'resource_alloc_from_bottom' makes it work. 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. Created attachment 455573 [details]
dmesg without resource_alloc_from_bottom
Created attachment 455574 [details]
dmesg with resource_alloc_from_bottom
Created attachment 455575 [details]
/proc/iomem without resource_alloc_from_bottom
Created attachment 455576 [details]
/proc/iomem with resource_alloc_from_bottom
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
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 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.
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? Is this bug fixed? 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! |