Re: 2.6.27-rc8-git8: oops in process hald-addon-dell-backlight (intel iommu related?)

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday, 25 of October 2008, Frederik Himpe wrote:
> On vr, 2008-10-24 at 23:49 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, 8 of October 2008, Frederik Himpe wrote:
> > > On Wed, 08 Oct 2008 20:15:37 +0000, Frederik Himpe wrote:
> > > 
> > > > On my Dell Latitude E6400 system with Intel chipset and graphics, I get
> > > > this oops in my 2.6.27-rc8-git8 based kernel, which probably happens
> > > > when hald-addon-dell-backlight is started.
> > > > 
> > > > Complete dmesg and lspci info:
> > > > https://qa.mandriva.com/show_bug.cgi?id=44711
> > > 
> > > Booting with intel_iommu=off seems to fix this issue, and seems to make my 
> > > e1000e based network card stop from giving "transmit timed out" errors 
> > > after which it stopped working.
> > 
> > Is it necessary to boot 2.6.27 final on this box with intel_iommu=off, and if
> > so, is it still necessary in mainline?
> 
> I just tested stock 2.6.27.3 and this machine (Dell Latitude E6400) is
> totally unusable without intel_iommu=off if Intel VT is enabled in the
> BIOS. During the boot process, stack traces start scrolling over the
> screen. In the end, it goes on starting X, and from that moment, the
> machine locks up completely. Booting in runlevel 3, I see lots of stack
> traces (too much to even be able to read them).
> 
> In the past (with Mandriva's 2.6.27-rc) it would at least succeed in
> booting (with one or a few backtraces), but even then the e1000e network
> card would timeout a few seconds after when starting to transfer some
> data, after which the network was totally unusable until a reboot. A
> reader of my blog confirmed having the same problem on this same type of
> laptop and also solving it by using intel_iommu=off.
> 
> I entered some more information here:
> http://bugzilla.kernel.org/show_bug.cgi?id=11821

OK, thanks.

I won't consider this as a regression, then.

Rafael