On 14 July 2011 00:14, Chris Wright <chr...@sous-sol.org> wrote: > * Chris Wright (chr...@sous-sol.org) wrote: >> > On Wed, 13 Jul 2011 14:32:42 GMT >> > bugzilla-dae...@bugzilla.kernel.org wrote: >> > > https://bugzilla.kernel.org/show_bug.cgi?id=39312 >> > > >> > > URL: https://bugs.gentoo.org/show_bug.cgi?id=373109 >> > > Summary: intel-iommu: Dont cache iova above 32bit - network >> > > copy freezes system >> > > Product: Drivers >> > > Version: 2.5 >> > > Kernel Version: 2.6.39.2 >> > > Platform: All >> > > OS/Version: Linux >> > > Tree: Mainline >> > > Status: NEW >> > > Severity: normal >> > > Priority: P1 >> > > Component: Other >> > > AssignedTo: drivers_ot...@kernel-bugs.osdl.org >> > > ReportedBy: marcus.d...@gmail.com >> > > Regression: No >> > > >> > > >> > > Created an attachment (id=65422) >> > > --> (https://bugzilla.kernel.org/attachment.cgi?id=65422) >> > > dmesg >> >> Can you send a dmesg from boot, and an lspci? > > Two things worth trying: > > 1) boot with intel_iommu=strict (to disable batching of unmaps, should > keep the number of outstanding mappings much lower) > > 2) boot with intel_iommu=forcedac (to disable the current behaviour > which tries to map < 32bit, then if that fails, maps >32bit). > > The hangs sounds like the iova allocation is looping excessively under > spin_lock_irqsave() >
Hi, as Marc stated in the bug report, first method is the same behavior as before and the second method made my input delay at first and then later locked up as method 1. On first boot with method one, my external USB-keyboard refused to work (funny flashing keys) so I used the laptop keyboard. I rebooted again using the command option and it worked... Hope that helps, Marcus _______________________________________________ stable mailing list stable@linux.kernel.org http://linux.kernel.org/mailman/listinfo/stable
