On 2011-05-20 12:38 AM, Bjorn Helgaas wrote:
On Thu, May 19, 2011 at 4:20 PM, Jan Zwiegers<jan@xxxxxxxxxxxxxxxxxxxx> wrote:
On 2011-05-20 12:13 AM, Bjorn Helgaas wrote:
On Thu, May 19, 2011 at 2:27 PM, Jan Zwiegers<jan@xxxxxxxxxxxxxxxxxxxx>
wrote:
On 2011-05-19 08:50 PM, Bjorn Helgaas wrote:
On Thu, May 19, 2011 at 10:28 AM, Jan Zwiegers<jan@xxxxxxxxxxxxxxxxxxxx>
wrote:
I have the problem below where my PCI card's second BAR does not get
assigned.
What can be the cause of this problem?
The last kernel I tested on which worked OK was 2.6.27.
My current problematic kernel 2.6.35.
05:01.0 Unassigned class [ff00]: Eagle Technology PCI-703 Analog I/O
Card
(rev 5c)
Flags: bus master, slow devsel, latency 32, IRQ 22
Memory at 93b00000 (type 3, prefetchable) [size=2K]
Memory at<unassigned> (type 3, prefetchable)
Capabilities: [80] #00 [0600]
Kernel modules: pci703drv
Could be resource exhaustion or, more likely, we ran out because we
now assign resource to things that don't need them, leaving none for
things that *do* need them. This sounds like a regression, so we
should open a bugzilla for it and attach dmesg logs from 2.6.27 and
2.6.35.
Does this problem keep the driver from working? (Sometimes drivers
don't actually use all the BARs a device supports.)
I'm the maintainer of the driver and was involved in the development of
the
board as well in 2003. The board uses two BARS and the second BAR is the
most important. The board worked fine since the 2.4 days and only
recently
became problematic. I suspect it works on even later kernels than 27,
maybe
2.6.32.
My knowledge is too little to actually determine if the problem is
because
the FPGA based PCI interface is not within spec or something that changed
in
the kernel, because of the post .30 releases becoming more strict to PCI
specification, i.e. BIOS / Kernel interaction.
Well, let's at least look at the working and broken dmesg logs. My
money is on kernel breakage. If it used to work, it should still
work.
What do you need from me? I have at least 3 machines on which it used to
work and is now running a later kernel. I can post dmesg from both .27 and
.35. Will do tomorrow when I'm back at the office.
Since you don't have continuous access to the machines, maybe you can
collect the /proc/iomem and "lspci -v" output at the same time you
collect the dmesg logs. That should be enough to get started.
Thanks,
Bjorn
OK I will do.
Should I post the whole dmesg log, or just the relevant sections?
Thanks!!
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
