On Tue, Feb 22, 2011 at 1:51 AM, Chris Wright <chrisw@xxxxxxxxxxxx> wrote: > * James Neave (roboj1m@xxxxxxxxx) wrote: >> Finally, here is the very latest dmesg: >> http://pastebin.com/9HE61K62 > > OK, this is an AMD IOMMU box. > > [ 0.000000] ACPI: IVRS 00000000cfcf9830 000E0 (v01 AMD RD890S 00202031 AMD 00000000) > > It's discovered and enalbed properly: > > [ 0.698992] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 > [ 0.710287] AMD-Vi: Lazy IO/TLB flushing enabled > >> Does anybody know the debug kernel switches for iommu? > > Two helpful kernel commandline options are: > > amd_iommu_dump debug (and drop "quiet") > > The problem is when you attach the device (function) you're getting > stuck up in conflicts with the existing domain for that function. > > My guess is that all the functions are behind a PCI to PCI bridge, so the alias > lookup is finding a conflict. > > thanks, > -chris > Hi, Yes, it's behind a PCI-PCI bridge I think, here's the blurb from an earlier email: cat /proc/interruts http://pastebin.com/LQdB3hms lspci -vvv http://pastebin.com/GJDkC8B4 lspci -t -v http://pastebin.com/Ftx8Hfjt I'll be interested to see whether the error messages revert to this -ebusy now that the machine has been powered off. Last thinh last night I got this: [ 5813.048427] assign device 0:8:6.0 [ 5813.048463] type=1400 audit(1298331555.057:42): apparmor="DENIED" operation="capable" parent=1 profile="libvirt-307bfcd2-9dec-29b7-1b4d-c46cd9d7cdbc" pid=3236 comm="kvm" capability=17 capname="sys_rawio" [ 5813.048505] deassign device 0:8:6.0 I added "capability sys_rawio" to the libvirtd apparmor profile, restarted apparmor and libvirt-bin and it just complained about the apparmor profile. The only other thing I did was compile the latest virt-manager 0.8.6, don't see how that would have made any difference. Many Thank, James. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
