Thanks Alex, 1. I am not concerned about device functionality but need to verify PCIE interface only by stressing it. 2. But I don't see writes getting reflected for most of addresses. 3. Also very often, it hangs in middle with CPU soft lockup and rcu preempt failures as below: [ 9732.090081] BUG: soft lockup- CPU#0 stuck for 22s! [update-notifier:1319] [ 9742.108839] INFO: rcu_preempt self-detected stall on CPU [ 9742.108848] INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 3, t=366016 jiffies, g=88556, c=88555, q=2037) 4. So query is why above 2 issues? I know it will affect device functionality but at least stress write test suite should work, right? On Thu, Apr 3, 2014 at 8:53 PM, Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > On Thu, 2014-04-03 at 20:38 +0530, shiv prakash Agarwal wrote: >> Hi All, >> >> I have a stress test which write a specific 4B pattern to whole BAR >> space for all BARs of a pcie device. >> >> Query is: >> >> 1. Is it allowed? Or will it have any side-effects? >> 2. If No, is it not allowed for all BARs or some BARs only like BAR0? > > Of course it will have side-effects, it's conceptually the same as > 'cat /dev/random > /dev/mem', but for a device instead of the kernel. > What you're overwriting is device dependent, but in any case you're > trashing something. The test sounds completely invalid to me. Thanks, > > Alex > -- 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