| Message ID | 20150520123615.GA24016@ulmo.nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.reding@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 <lkml14@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 <lkml14@scotdoyle.com> > > > > >> > Acked-by: Pavel Machek <pavel@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 <khilman@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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.reding@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 <lkml14@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 <lkml14@scotdoyle.com> > > > > > >> > Acked-by: Pavel Machek <pavel@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 <khilman@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. Thierry
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.reding@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 <lkml14@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 <lkml14@scotdoyle.com> > > > > > > >> > Acked-by: Pavel Machek <pavel@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 <khilman@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. 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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.reding@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 <lkml14@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 <lkml14@scotdoyle.com> > > > > > > > >> > Acked-by: Pavel Machek <pavel@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 <khilman@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
On Friday 22 May 2015 12:00:03 Thierry Reding wrote: > > > 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. > Better make that a general rule. My workflow is different from Greg's but also doesn't cope well with attachments. A lot of people in turn have problems quoting from an attachment when replying to the patch, which happens to work for me. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote: > On Friday 22 May 2015 12:00:03 Thierry Reding wrote: > > > > > 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. > > > > Better make that a general rule. My workflow is different from Greg's > but also doesn't cope well with attachments. A lot of people in turn > have problems quoting from an attachment when replying to the patch, > which happens to work for me. Okay. Any hints on how to simplify sending out such patches with the same list of recipients? I find it very annoying to have to manually copy each recipient into the git send-email command-line, but I don't know of a better way to do it. Replying to an email from the MUA will at least do that automatically. Thierry
On Fri, May 22, 2015 at 1:49 PM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote: >> On Friday 22 May 2015 12:00:03 Thierry Reding wrote: >> > >> > > 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. >> > >> >> Better make that a general rule. My workflow is different from Greg's >> but also doesn't cope well with attachments. A lot of people in turn >> have problems quoting from an attachment when replying to the patch, >> which happens to work for me. > > Okay. Any hints on how to simplify sending out such patches with the > same list of recipients? I find it very annoying to have to manually > copy each recipient into the git send-email command-line, but I don't > know of a better way to do it. Replying to an email from the MUA will > at least do that automatically. You can write your recipients to the "To:" header of the patch you generated using git format-patch. git send-email will pick all recipients thus specified up automatically. In later iterations you can just copy the "To:" line. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 22 May 2015 13:49:58 Thierry Reding wrote: > On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote: > > On Friday 22 May 2015 12:00:03 Thierry Reding wrote: > > > > > > > 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. > > > > > > > Better make that a general rule. My workflow is different from Greg's > > but also doesn't cope well with attachments. A lot of people in turn > > have problems quoting from an attachment when replying to the patch, > > which happens to work for me. > > Okay. Any hints on how to simplify sending out such patches with the > same list of recipients? I find it very annoying to have to manually > copy each recipient into the git send-email command-line, but I don't > know of a better way to do it. Replying to an email from the MUA will > at least do that automatically. You can have a line starting with 8<------ (the scissors symbol) after your reply, and then paste the patch below. I usually use 'git show --format=email | xclip' to copy the patch into the X clipboard and paste it into the email window from there. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 22, 2015 at 01:49:58PM +0200, Thierry Reding wrote: > On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote: > > On Friday 22 May 2015 12:00:03 Thierry Reding wrote: > > > > > > > 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. > > > > > > > Better make that a general rule. My workflow is different from Greg's > > but also doesn't cope well with attachments. A lot of people in turn > > have problems quoting from an attachment when replying to the patch, > > which happens to work for me. > > Okay. Any hints on how to simplify sending out such patches with the > same list of recipients? I find it very annoying to have to manually > copy each recipient into the git send-email command-line, but I don't > know of a better way to do it. Replying to an email from the MUA will > at least do that automatically. Reply from the MUA and then just put the patch in the email body. If you have a good MUA it should be trivial to do[1] thanks, greg k-h 1) mutt drops you to your editor, and then you can just read in the patch file directly to that buffer. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 22, 2015 at 03:24:30PM +0200, Arnd Bergmann wrote: > On Friday 22 May 2015 13:49:58 Thierry Reding wrote: > > On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote: > > > On Friday 22 May 2015 12:00:03 Thierry Reding wrote: > > > > > > > > > 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. > > > > > > > > > > Better make that a general rule. My workflow is different from Greg's > > > but also doesn't cope well with attachments. A lot of people in turn > > > have problems quoting from an attachment when replying to the patch, > > > which happens to work for me. > > > > Okay. Any hints on how to simplify sending out such patches with the > > same list of recipients? I find it very annoying to have to manually > > copy each recipient into the git send-email command-line, but I don't > > know of a better way to do it. Replying to an email from the MUA will > > at least do that automatically. > > You can have a line starting with 8<------ (the scissors symbol) after > your reply, and then paste the patch below. > > I usually use 'git show --format=email | xclip' to copy the patch into > the X clipboard and paste it into the email window from there. Cool, that's pretty useful. I should be able to do that without going through the X clipboard with mutt/vim even. Thanks, Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 22, 2015 at 07:32:05AM -0700, Greg Kroah-Hartman wrote: > On Fri, May 22, 2015 at 01:49:58PM +0200, Thierry Reding wrote: > > On Fri, May 22, 2015 at 12:33:42PM +0200, Arnd Bergmann wrote: > > > On Friday 22 May 2015 12:00:03 Thierry Reding wrote: > > > > > > > > > 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. > > > > > > > > > > Better make that a general rule. My workflow is different from Greg's > > > but also doesn't cope well with attachments. A lot of people in turn > > > have problems quoting from an attachment when replying to the patch, > > > which happens to work for me. > > > > Okay. Any hints on how to simplify sending out such patches with the > > same list of recipients? I find it very annoying to have to manually > > copy each recipient into the git send-email command-line, but I don't > > know of a better way to do it. Replying to an email from the MUA will > > at least do that automatically. > > Reply from the MUA and then just put the patch in the email body. If > you have a good MUA it should be trivial to do[1] > > thanks, > > greg k-h > > 1) mutt drops you to your editor, and then you can just read in the > patch file directly to that buffer. Indeed, that should work. As I understand it, I wouldn't even have to further edit the email (except strip the reply) because git am prefers headers in the patch to headers in the message (it certainly does that for From:, so I suspect it would do it for Date: and Subject: as well). Or if that doesn't work, Arnd's suggestion to use a scissors line is a good alternative as well. Thanks guys for the suggestions, Thierry
From 4f2f70dbbe9de54c0da9b03a1f384e1464755eab Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Wed, 20 May 2015 13:41:52 +0200
Subject: [PATCH] fbcon: Avoid deleting a timer in IRQ context
Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by
vt") unconditionally removes the cursor blink timer. Unfortunately that
wreaks havoc under some circumstances. An easily reproducible way is to
use both the framebuffer console and a debug serial port as the console
output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
kernel command-line. Upon boot this triggers a warning from within the
del_timer_sync() function because it is called from IRQ context:
[ 5.070096] ------------[ cut here ]------------
[ 5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
[ 5.070115] Modules linked in:
[ 5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
[ 5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[ 5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
[ 5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[ 5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
[ 5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
[ 5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
[ 5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
[ 5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
[ 5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
[ 5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
[ 5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
[ 5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
[ 5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
[ 5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)
After which the system starts spewing all kinds of weird and seemingly
unrelated error messages.
This commit fixes this by restoring the condition under which the call
to fbcon_del_cursor_timer() happens.
Reported-by: Daniel Stone <daniel@fooishbar.org>
Reported-by: Kevin Hilman <khilman@kernel.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
drivers/video/console/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
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;
--
2.4.1