[lkml]   [2011]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PCI BAR1 Unassigned
    On Thu, May 19, 2011 at 4:20 PM, Jan Zwiegers <> wrote:
    > On 2011-05-20 12:13 AM, Bjorn Helgaas wrote:
    >> On Thu, May 19, 2011 at 2:27 PM, Jan Zwiegers<>
    >>  wrote:
    >>> On 2011-05-19 08:50 PM, Bjorn Helgaas wrote:
    >>>> On Thu, May 19, 2011 at 10:28 AM, Jan Zwiegers<>
    >>>>  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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-05-20 00:41    [W:0.027 / U:98.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site