linux-kernel - Re: Linux 2.6.31-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Aug 2009 15:07:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	mailing54 <mailing54@...k.org>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...hat.com>,
	Eric Anholt <eric@...olt.net>, dri-devel@...ts.sourceforge.net,
	Ma Ling <ling.ma@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Zhenyu Wang <zhenyuw@...ux.intel.com>
Subject: Re: Linux 2.6.31-rc7

On Tue, 25 Aug 2009, mailing54 wrote:

> Linus Torvalds schrieb:
> > Are you using the same config? It sounds very much like your -rc7 problems
> > are due to the Intel KMS (kernel mode setting) driver, which I know has had
> > problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used
> > different config options and didn't enable KMS, for example. Because I don't
> > think anything actually changed in the KMS code itself between rc6 and rc7.
>   
> Not sure what settings to look for, but this looks like you are completely
> correct:
> 
> tobias@...x:~$ cat /boot/config-2.6.31-020631rc6-generic | grep KMS
> # CONFIG_DRM_I915_KMS is not set
> # CONFIG_DRM_RADEON_KMS is not set
> tobias@...x:~$ cat /boot/config-2.6.31-020631rc7-generic | grep KMS
> CONFIG_DRM_I915_KMS=y
> CONFIG_DRM_RADEON_KMS=y

Yeah, so it's i915 kms.

You can disable it dynamically at boot time with the 

	i915.modeset=0

kernel command line (or I guess with "nomodeset" too, for that matter, 
which should disable both i915 and radeom kms).

However, the problem remains that KMS gets the output wrong, in ways that 
clearly X does not. Eric - it's clearly not just Mac Mini and my 
experimental machine that have problems, but also a Macbook 2.1.

I wonder why the Intel KMS logic doesn't look at which output was driven 
before it got invoked. Instead, it seems to want to try to detect 
everything from scratch, even though we should be able to assume that if 
you boot from BIOS (or EFI, for that matter), the current state of the 
graphics pipeline is likely meaningful.

And clearly distros are trying to enable this. Which means that this is 
getting way more important to solve.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/