On 10/06/2015 at 08:37 PM, Andreas Hartmann wrote: > On 10/06/2015 at 12:13 PM, Joerg Roedel wrote: >> On Wed, Sep 30, 2015 at 04:52:47PM +0200, Andreas Hartmann wrote: >>>> Alternativly someone who can reproduce it should trace the calls to >>>> __map_single and __unmap_single in the AMD IOMMU driver to find out >>>> whether the addresses which the faults happen on are really mapped, or >>>> at least requested from the AMD IOMMU driver. >>> >>> How can I trace it? >> >> Please apply the attached debug patch on-top of Linux v4.3-rc3 and boot >> the machine. After boot you run (as root): >> >> >> # cat /sys/kernel/debug/tracing/trace_pipe > trace-data >> >> Please run this in a seperate shell an keep it running. >> >> Then trigger the problem while the above command is running. When you >> triggered it, please send me the (compressed) trace-data file, full >> dmesg and output of lspci on the box. > > Hmm, *seems* to work fine w/ 4.3-rc2. But I have to do some more tests > to be really sure. > > > W/ 4.1.10, the problem can be seen most always during boot (systemd) - > but at this point, it is difficult to trace. I have to take a closer > look to find a place to start the trace already during boot process. Got it during a single mount (I booted with massively reduced mounts and did the mount afterwards manually. During the second manually mount, the problem can be seen). I attached the requested files. The mount starts at 80 seconds. Hope this helps. Thanks, Andreas
Attachment:
dmesg.mount.gz
Description: GNU Zip compressed data
Attachment:
trace.xz
Description: application/xz
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
