On Thu, May 21, 2015 at 07:00:31PM -0700, Greg Kroah-Hartman wrote: > On Thu, May 21, 2015 at 10:00:50AM +0200, Thierry Reding wrote: > > On Wed, May 20, 2015 at 09:26:38PM -0700, Greg Kroah-Hartman wrote: > > > On Wed, May 20, 2015 at 02:36:17PM +0200, Thierry Reding wrote: > > > > On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote: > > > > > On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote: > > > > > > On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote: > > > > > > > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding > > > > > > > <thierry.red...@gmail.com> wrote: > > > > > > > > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote: > > > > > > > >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle > > > > > > > >> <lkm...@scotdoyle.com> wrote: > > > > > > > >> > vt now provides a cursor blink interval via vc_data. Use this > > > > > > > >> > interval instead of the currently hardcoded 200 msecs. Store > > > > > > > >> > it in > > > > > > > >> > fbcon_ops to avoid locking the console in > > > > > > > >> > cursor_timer_handler(). > > > > > > > >> > > > > > > > > >> > Signed-off-by: Scot Doyle <lkm...@scotdoyle.com> > > > > > > > >> > Acked-by: Pavel Machek <pa...@ucw.cz> > > > > > > > >> > > > > > > > >> This patch hit next-20150519 in the form of commit 27a4c827c34a > > > > > > > >> (fbcon: use the cursor blink interval provided by vt) and has > > > > > > > >> caused > > > > > > > >> boot failure on a handful of ARM platforms when booting a MMC > > > > > > > >> root > > > > > > > >> filesystem. This error was spotted by the kernelci.org bot on > > > > > > > >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen > > > > > > > >> it on > > > > > > > >> some tegra platforms too. > > > > > > > >> > > > > > > > >> Thierry spotted this commit as a potential cause, and both > > > > > > > >> Daniel and > > > > > > > >> I have reverted and boot tested on exynos5 and tegra > > > > > > > >> respectively and > > > > > > > >> the boot panics disappear. > > > > > > > > > > > > > > > > FWIW, if I apply the below on top of next-20150519 things seem > > > > > > > > to be > > > > > > > > back to normal as well: > > > > > > > > > > > > > > > > diff --git a/drivers/video/console/fbcon.c > > > > > > > > b/drivers/video/console/fbcon.c > > > > > > > > index 05b1d1a71ef9..658c34bb9076 100644 > > > > > > > > --- a/drivers/video/console/fbcon.c > > > > > > > > +++ b/drivers/video/console/fbcon.c > > > > > > > > @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data > > > > > > > > *vc, int mode) > > > > > > > > return; > > > > > > > > > > > > > > > > ops->cur_blink_jiffies = > > > > > > > > msecs_to_jiffies(vc->vc_cur_blink_ms); > > > > > > > > - fbcon_del_cursor_timer(info); > > > > > > > > - if (!(vc->vc_cursor_type & 0x10)) > > > > > > > > + if (vc->vc_cursor_type & 0x10) > > > > > > > > + fbcon_del_cursor_timer(info); > > > > > > > > + else > > > > > > > > fbcon_add_cursor_timer(info); > > > > > > > > > > > > > > > > ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1; > > > > > > > > > > > > > > Applying this on next-20150519 makes my exynos board happily boot > > > > > > > again as well. > > > > > > > > > > > > > > Tested-by: Kevin Hilman <khil...@linaro.org> > > > > > > > > > > > > Excellent. Greg, Scot, any opinions on whether or not this is the > > > > > > right > > > > > > thing to do? It restores a bit that looks suspiciously like it > > > > > > snuck in > > > > > > in the original (at least it isn't documented in the commit > > > > > > message). > > > > > > > > > > > > Greg, feel free to squash this in if everybody agrees this is good > > > > > > to > > > > > > go. If you prefer a patch on top let me know and I'll come up with a > > > > > > proper commit message. > > > > > > > > > > Please send a real patch and I'll apply it on top, as I can't rebase > > > > > my > > > > > public tree. > > > > > > > > Attached. > > > > > > Ugh, no, please resend it as a stand-alone patch, I can't easily apply > > > attachments. > > > > Really? Your MUA can't dissect multipart messages? Anyway, sent > > separately for your convenience. > > "git am" doesn't do that. I apply patches in huge chunks of mbox files.
What I frequently end up doing is apply patches straight from mutt by piping the mail or an attached patch to git am. I guess I had expected that you'd have something similar to simplify applying patches. > Remember, if I have to hand-edit, or do something special with your > patch, I will not do it, you need to do it correctly to make > maintainer's lives easier, not harder, given that maintainers are the > limited resouce, not developers. I understand. I'll make a mental note to never send you patches as attachment again. Thierry
pgpELUw41mne2.pgp
Description: PGP signature
