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: <20131112022256.GC4341@dhcp-16-126.nay.redhat.com>
Date:	Tue, 12 Nov 2013 10:22:56 +0800
From:	Dave Young <dyoung@...hat.com>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	matt.fleming@...el.com, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, x86@...nel.org, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] efi earlyprintk fix

On 11/11/13 at 04:13pm, Matt Fleming wrote:
> On Sat, 09 Nov, at 11:44:29AM, Dave Young wrote:
> > Hi, Matt
> > 
> > Confirmed, your patch work ok for the pr_cont issue.
>  
> Excellent, thanks for testing.
> 
> > Actually I mixed two problems in my report, one is there's always one blank line
> > at the bottom of screen, the other is the pr_cont issue. For the second problem
> > change >= to > looks better. For the previous problem still need to move the
> > hunk below to the beginning point of early_efi_write function. It just works for me
> > but I'm not sure why this is not necessary for other machines. 
> > 
> > +		if (efi_y + font->height > si->lfb_height) {
> > +			u32 i;
> > +
> > +			efi_y -= font->height;
> > +			early_efi_scroll_up();
> > +
> > +			for (i = 0; i < font->height; i++)
> > +				early_efi_clear_scanline(efi_y + i);
> > +		}
> 
> Dave, unfortunately you're going to need to debug this further because
> it doesn't make any sense that your patch is needed, unless there's a
> bug in the existing code.

Ok, will dig more about this and find out why it only happens on this machine.

> 
> You may also want to rule out that your boot_delay patches are not
> inserting delays after printing pr_fmt().

In fact with or without the delay testing results are same. There's might be
something wrong in the setup as you said. I will update once I have got something.

Thanks
Dave
--
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