linux-kernel - Re: [git pull] drm: previous pull req + 1.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <cb0375e10906211705q382f5211lf09e39ff637c1c0d@mail.gmail.com>
Date:	Sun, 21 Jun 2009 20:05:36 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...ux.ie>, dri-devel@...ts.sf.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jerome Glisse <jglisse@...hat.com>,
	Alex Deucher <alexdeucher@...il.com>
Subject: Re: [git pull] drm: previous pull req + 1.

On Sun, Jun 21, 2009 at 5:14 PM, Andrew Lutomirski<luto@....edu> wrote:
> On Sun, Jun 21, 2009 at 3:47 PM, Linus
> Torvalds<torvalds@...ux-foundation.org> wrote:
>>
>>
>> What *has* changed is that we have a newradeon driver, and it looks like
>> that new radeon driver is crap, and does this:
>>
>>        info->fix.smem_start = (unsigned long)fbptr;
>>
>> which is totally screwed up. It assigns a _virtual_ address to that
>> "smem_start" thing, even though it should be a physical one.
>>
>> I don't know the radeon driver, so I don't know where to find the physical
>> address.  It's also possible that there is no good single physical
>> address, and the radeon driver should implement a "fb_mmap" function.
>>
>> Does this patch make the warning and the oops at least go away? Obviously
>> it won't result in a working frame buffer, but that's a separate issue
>>
>
> I haven't tried your patch, but I hacked up the one below instead,
> which also fixes the oops.  It still doesn't boot, though -- plymouth
> hangs (or otherwise dies), preventing my initramfs from finishing.
> The same kernel image boots fine with radeon.modeset=0.

My patch is no good -- plymouthd just dies more silently with it.
Returning -EINVAL from radeonfb_mmap prevents plymouthd's splash
screen from working (of course) but lets the system boot.  (Not only
does the system boot, but this is the first modesetting kernel I've
ever seen work on this hardware.)  Linus's patch works and even lets
me start X.

David -- there are still plenty of bugs.  The kernel gets my monitor's
resolution wrong (X reads it off DDC correctly but I have to use
xrandr to force the resolution).  And glxgears triggers the kernel's
command verification and dies.  But this is still a huge improvement
over modesetting on the F11 kernel, which is unusable for me (image is
garbled beyond recognition once I start X).

--Andy
--
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/