You'll need to add some
debugging to the cg6 case as I can't find any problems with the blanking
code there. If the cg6 is not the primary console, probably the blank
function simply isn't being invoked.
Tried it with some printks and cg6 as the primary console. These printks
show that when blank
Actually I spotted the cg3 problem already. You'll need to add some
debugging to the cg6 case as I can't find any problems with the blanking
code there. If the cg6 is not the primary console, probably the blank
function simply isn't being invoked.
Anyways, here is the cg3 fix:
Thanks, this indeed
On Wed, 16 Feb 2005 03:27:51 +0100
Frans Pop <[EMAIL PROTECTED]> wrote:
> Excellent!
> Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the
> old behavior. I guess that solves the regression since 2.6.10-rc2.
>
> Please let me know if this patch will be submitted for inclus
On Tue, 15 Feb 2005 20:37:23 -0600
Bob Breuer <[EMAIL PROTECTED]> wrote:
> Somehow everything I tested compiled fine without it.
Right, some other header is bringing it in indirectly.
> Updated patch is attached. The patch only cleans up the
> include/asm-sparc and arch/sparc directories.
App
David S. Miller wrote:
Can I ask you to do two things please?
1) Add include/linux/compiler.h to oplib.h, that is needed for the
__must_check declaration.
Ok, I've added it. Somehow everything I tested compiled fine without it.
2) Please include your patch as an attachment. Something in your
On Tuesday 15 February 2005 17:49, David S. Miller wrote:
> On sparc, when "mode" is NULL, we should always use default_var as
> setup by PROM probed values.
>
> Here is the fix:
Excellent!
Tested the patch with 2.6.11-rc3-bk2 and AFAICT it completely restores the
old behavior. I guess that solve
On Tuesday 15 February 2005 13:10, Antonino A. Daplas wrote:
> Can you verify if this is the case? Insert a bunch of printk's in and
> around this line "if (node == pcp->prom_node) {" in
> atyfb_setup_sparc(). For the 2.6.8 kernel, this line is in
> atyfb_init().
Tested that and output is identi
On Tue, Feb 15, 2005 at 09:40:57AM -0800, David S. Miller wrote:
> I've modified your patch to only do this in the SMP case.
> Here is how the two mechanisms work:
[...]
> The SMP case works in that each thread, when scheduled(), has
> it's PSR_EF flag cleared.
> This fork() bug takes away that inv
On Sun, 06 Feb 2005 22:42:19 -0600
Bob Breuer <[EMAIL PROTECTED]> wrote:
> Since I brought the subject up, I felt compelled to put some effort
> toward the cleanup. I have appended the cleanups for the asm-sparc
> and arch/sparc directories.
>
> I noticed that Art Haas sent a patch for tree.c.
On Sun, 6 Feb 2005 16:23:39 -0600
"Art Haas" <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 04, 2005 at 09:41:42PM -0800, David S. Miller wrote:
> > That would be a great idea. In particular, things like
> > tree.c:prom_nodematch() should check (and return "0" when
> > error occurs).
>
> How does this
On Wed, 26 Jan 2005 09:24:42 +0100
"Krzysztof Helt" <[EMAIL PROTECTED]> wrote:
> Here is a patch for FPU context switching in SMP.
>
> A copy_thread() function clears PF_USEDFPU flag for a new thread,
> but it does not clear the PSR_EF bit. Thus, a first FPU exception
> called from the child thre
On Tue, 15 Feb 2005 20:10:21 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
> Okay. It seems that in the working kernel, the default mode, 1152x900, was
> taken from the prom (since there is no 1152x900 in the mode database) if you
> did not specify any boot mode option.
>
> In the non-wo
On Tue, 15 Feb 2005 08:02:21 -0800
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Feb 2005 12:33:15 +0200 (EET)
> Meelis Roos <[EMAIL PROTECTED]> wrote:
>
> > I have cg3 and cg6 framebuffers in my SS5. Current snapshot kernel makes
> > both work well for fb console (haven't tried X).
On Tue, 15 Feb 2005 12:33:15 +0200 (EET)
Meelis Roos <[EMAIL PROTECTED]> wrote:
> I have cg3 and cg6 framebuffers in my SS5. Current snapshot kernel makes
> both work well for fb console (haven't tried X). There is only one
> strange thing left - console blanking.
>
> Both cg3 and cg6 behave th
On Tuesday 15 February 2005 14:22, Frans Pop wrote:
> Hi Tony,
>
> I've tried your suggestions and the one about using fbset resulted in a
> breakthrough. 'fbset -depth' gave no results, but comparing the output of
> 'fbset -i' from a working kernel and a new one gave me something to try.
>
Okay.
I have cg3 and cg6 framebuffers in my SS5. Current snapshot kernel makes
both work well for fb console (haven't tried X). There is only one
strange thing left - console blanking.
Both cg3 and cg6 behave the same: when it's blanking time, cursor is
turned off but all the text stays. When I press
On Tue, 15 Feb 2005, Frans Pop wrote:
> These values also tell that the old default mode was 1152x900-66,
> resulting in a 144x56 textconsole. My personal opinion is that that is
> very high for a default mode. The 1024x768-70 (resulting in 128x48) I've
> been using now (or maybe even something
17 matches
Mail list logo
