Re: Writing to BARs of PCIE device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux