LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: cloos@jhcloos.com
Cc: linux-kernel@vger.kernel.org, benh@kernel.crashing.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	khc@pm.waw.pl, linux-fbdev-devel@lists.sourceforge.net
Subject: Re: radeonfb lockup in .28-rc (bisected)
Date: Mon, 27 Oct 2008 17:00:08 -0700 (PDT)	[thread overview]
Message-ID: <20081027.170008.112856238.davem@davemloft.net> (raw)
In-Reply-To: <m31vy1k3ea.fsf@lugabout.jhcloos.org>

From: James Cloos <cloos@jhcloos.com>
Date: Mon, 27 Oct 2008 19:45:58 -0400

> Commit b1ee26bab1 breaks radeonfb on my inspiron 8100 (P3-M with a
> Mobility M7 LW [7500] (1002:4c57 1028:00e6)).

Please quote at least the headerline of the commit so that it can
come into our memory quickly when reading your report.

Here it is for the others:

commit b1ee26bab14886350ba12a5c10cbc0696ac679bf
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Wed Oct 15 22:03:46 2008 -0700

    radeonfb: accelerate imageblit and other improvements
    
    Implement support for HW color expansion of 1bpp images, along with some
    improvements to the FIFO handling and other accel operations.
    
    The offset fixup code is now unnecessary as the fbcon core will call our
    set_par upon switch back from KD_GRAPHICS before anything else happens.  I
    removed it as it would slow down accel operations.
    
    The fifo wait has been improved to avoid hitting the HW register as often,
    and the various accel ops are now performing better caching of register
    values.
    
    Overall, this improve accel performances.  The imageblit acceleration does
    result in a small overall regression in performances on some machines (on
    the order of 5% on some x86), probably becaus the SW path provides a
    better bus utilisation, but I decided to ingnore that as the performances
    is still very good, and on the other hand, some machines such as some
    sparc64 get a 3 fold performance improvement.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Acked-by: David S. Miller <davem@davemloft.net>
    Cc: Krzysztof Halasa <khc@pm.waw.pl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

> The boot is OK until init(8) starts; after init outputs its version info
> it calls rc(8), which starts by setting the fb font.  At that point any
> kernel with b1ee26bab1 locks hard.  The cursor stops flashing, magic
> sysrq stops working and the fan starts up after a few seconds.  (I can't
> tell whether it is the CPU or the GPU that heats up.)
> 
> If it is relevant, I use a 10x20 font, so the font change means the
> console converts from 200x75, 8x16 to 160x60, 10x20.

The actual key here is that when setfont runs, the framebuffer layer sets
the acceleration options for the framebuffer for the first time to their
final settings.

> The differences between rc2 and rc2+revert are limited
> to some changes in the size of the kernel:
> 
> -Memory: 512232k/524200k available (4376k kernel code, 11428k reserved, 1707k data, 320k init, 0k highmem)
> +Memory: 512272k/524200k available (4354k kernel code, 11388k reserved, 1693k data, 316k init, 0k highmem)

That's just all due to the text size change because of the different
acceleration code.

       reply	other threads:[~2008-10-28  0:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m31vy1k3ea.fsf@lugabout.jhcloos.org>
2008-10-28  0:00 ` David Miller [this message]
2008-10-28  1:46   ` James Cloos
2008-10-28  0:05 ` Benjamin Herrenschmidt
2008-10-28  1:50   ` James Cloos
2008-10-28  9:24   ` James Cloos
2008-11-02 21:48     ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2008-11-03  7:01       ` Paul Collins
2008-11-03  7:34         ` Benjamin Herrenschmidt
2008-11-04  6:49           ` Paul Collins
2008-11-04 21:33             ` Benjamin Herrenschmidt
2008-11-06  6:00               ` Paul Collins
2008-11-06  7:52                 ` Benjamin Herrenschmidt
2008-11-04 21:36             ` Benjamin Herrenschmidt
2008-11-05  8:39         ` Benjamin Herrenschmidt
2008-11-05 10:28           ` Paul Collins
2008-11-05 20:31             ` Benjamin Herrenschmidt
2008-11-06  3:49             ` Benjamin Herrenschmidt
2008-11-06  4:49               ` Paul Collins
2008-11-03 15:33       ` James Cloos
2008-11-03 20:22         ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081027.170008.112856238.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=cloos@jhcloos.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: radeonfb lockup in .28-rc (bisected)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).