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] [day] [month] [year] [list]
Date:	Thu, 05 Nov 2009 13:02:03 +0200
From:	Mehmet Giritli <mehmet@...itli.eu>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Faulty MTRR setups in Toshiba laptops crash video drivers

On Wed, 2009-11-04 at 17:48 -0600, Robert Hancock wrote:
> On Tue, Nov 3, 2009 at 7:08 AM, Mehmet Giritli <mehmet@...itli.eu> wrote:
> > On Mon, 2009-11-02 at 18:06 -0600, Robert Hancock wrote:
> >> On 11/02/2009 10:28 AM, Mehmet Giritli wrote:
> >> > Hello all,
> >> >
> >> > On some laptops using ATI 3650HD radeon chipsets and 4GB ram (and may be
> >> > others as well), it is impossible to start any xserver due to (faulty?)
> >> > mtrr setups on the machine. The computer locks up or just gives an
> >> > unresponsive black screen. There are various drivers for radeon cards
> >> > and the crash occurs in all of these drivers in the very same way!
> >> >
> >> > This bug seems to occur mostly on Toshiba laptops with ATI graphic
> >> > cards. For some people, CONFIG_MTRR_SANITIZER seemed to cure the issue
> >> > but made no difference for many others like me.
> >> >
> >> > RadeonHD people seem to have problems in understanding the nature of
> >> > this bug. Please have a look at the threads:
> >> >
> >> > http://lists.opensuse.org/radeonhd/2009-05/msg00040.html
> >> >
> >> > and,
> >> >
> >> > http://bugs.freedesktop.org/show_bug.cgi?id=20645
> >> >
> >> > for problem reports and dev responses. RadeonHD devs suggest that some
> >> > laptops have weird mtrr setups and this must be fixed in the kernel code
> >> > and not the driver code.
> >>
> >> Unfortunately I don't see enough details to be able to tell what lead
> >> them to this conclusion. Can you post the output of:
> >>
> >> lspci -vv
> >> cat /proc/mtrr
> >
> > lspci -vv
> > http://bugzilla.kernel.org/attachment.cgi?id=23634
> >
> > /proc/mtrr when 4GB installed
> > http://bugzilla.kernel.org/attachment.cgi?id=23632
> >
> > /proc/mtrr when 2GB installed
> > http://bugzilla.kernel.org/attachment.cgi?id=23633
> >
> > There is also a bug report that I opened a while back here:
> > http://bugzilla.kernel.org/show_bug.cgi?id=14054
> 
> So it appears that your machine has an MTRR entry which marks the
> first 16MB of the video card's video RAM BAR area as "write-through",
> which seems quite clearly wrong. However, all that I would expect to
> see this do would be to cause X to be unable to map the BAR as
> write-combining (which you can see from dmesg is indeed occurring)
> causing a loss of performance. And the same MTRR is there in the 2GB
> case as in the 4GB case. So I don't think the question of why it works
> with 2GB and not with 4GB is anything to do with MTRRs..

I was using vesafb driver for framebuffer splashscreen and after
removing it from the kernel command line, that 16MB mtrr entry is now
gone. And yes, X was very slow at startup before, now that seems to be
rectified. I don't know if thats another bug or not regarding kernel or
the radeonhd driver.

I should thank you and perhaps especially Yinghai Lu for suggesting it
in the above mentioned bug report.

However, removing vesafb did not make any improvements.

Now I'm wondering if radeonhd developers have anything specific to say
about this...

I will ask on the radeonhd list...


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ