On Sat, Apr 26, 2014 at 12:09 PM, shiv prakash Agarwal <chhotu.shiv@xxxxxxxxx> wrote: > Thanks Bjorn, > > 1. I see PCI core setting this bit while enumeration. > 2. Avoiding this setting allows successful enumeration, otherwise hang > occurs in any subsequent device config space write. > 3. Yes, no dma operation happening but hang happens on device config space > write. OK, let me know when you figure out where the core is turning on Bus Master and what config access we're doing when the hang occurs. > On Fri, Apr 25, 2014 at 8:08 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> >> 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
