On Thu, Apr 24, 2014 at 11:40 PM, shiv prakash Agarwal <chhotu.shiv@xxxxxxxxx> wrote: > Thanks Bjorn, > > On furthur debug, I found that this hang happens on enabling Bus Master > Enable bit(bit 2) of command register (offset 0x4) in config space of > device. On disabling this bit, no hang occurs. > > Any idea on this behaviour? It'd be easier if you gave a few more details. Where exactly did you remove the Bus Master enable? The PCI core should not enable Bus Master for an endpoint at all unless the driver requests it, and based on the dmesg fragment you posted, I don't think the driver is involved yet. Bus mastering affects transactions originated by the device, of course. So if the hang only happens if Bus Master is enabled, it sounds like the hang happens when the device performs a DMA or other transaction. But if the driver hasn't claimed the device yet, the device shouldn't be doing anything at all, even if Bus Master is enabled. There might be more clues if you would post the *entire* dmesg log instead of just a fragment. > On Thu, Apr 24, 2014 at 10:07 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> >> On Thu, Apr 24, 2014 at 1:47 AM, shiv prakash Agarwal >> <chhotu.shiv@xxxxxxxxx> wrote: >> > Hi Bjorn, >> > >> > Below is the hang: >> > >> > >> > PCI host bridge to bus 0000:00 >> > >> > pci_bus 0000:00: root bus resource [mem 0x32100000-0x3fffffff] >> > >> > pci_bus 0000:00: root bus resource [mem 0x12100000-0x320fffff pref] >> > >> > pci_bus 0000:00: root bus resource [io 0x1000-0xffff] >> > >> > pci_bus 0000:00: No busn resource found for root bus, will use [bus >> > 00-ff] >> > >> > pci 0000:00:00.0: [10de:0e12] type 01 class 0x060400 >> > >> > pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold >> > >> > PCI: bus0: Fast back to back transfers disabled >> > >> > pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), >> > reconfiguring >> > >> > pci 0000:01:00.0: [8086:1533] type 00 class 0x020000 >> > >> > pci 0000:01:00.0: reg 10: [mem 0x00000000-0x000fffff] >> > >> > Unhandled fault: imprecise external abort (0x1406) at 0x00000000 >> > >> > Internal error: : 1406 [#1] PREEMPT SMP ARM >> > >> > Modules linked in: >> > >> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.24 #2 >> > >> > task: ef06fa40 ti: ef0b2000 task.ti: ef0b2000 >> >> This looks like it's happening before the igb driver is involved. >> There must be a bridge from bus 0000:00 to bus 0000:01. It looks like >> 0000:00:00.0 might be the bridge, but we haven't finished enumerating >> it yet. So it seems likely that this is happening in the PCI core. >> >> Can you get a backtrace at the point of the fault? Maybe add a >> dump_stack() there? >> >> The 01:00.0 BAR contains zero, which is not itself a problem. Zero is >> what you'd expect after power-up if no firmware or anything had >> programmed it. The PCI core should notice that this is invalid (it's >> not inside any of the root bus resources) and reprogram it, but we >> haven't gotten that far yet. >> >> > On Tue, Apr 22, 2014 at 9:31 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> >> > wrote: >> >> On Tue, Apr 22, 2014 at 3:50 AM, shiv prakash Agarwal >> >> <chhotu.shiv@xxxxxxxxx> wrote: >> >>> Hi All, >> >>> >> >>> Has anybody tested below Intel I210 NIC card using igb driver on ARM? >> >>> >> >>> >> >>> http://www.intel.com/content/www/us/en/ethernet-controllers/ethernet-controller-i210-i211-family.html >> >>> >> >>> It hangs during configuration stage for me. Actually it shows BAR0 >> >>> requirement as 0 which is non-zero for x86. >> >> >> >> Can you give any more details about this, e.g., a complete dmesg log, >> >> which should contain details about enumeration and resource >> >> allocation? > > -- 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
