* 2.6.0-ben3: Badness in redraw_screen
@ 2003-12-31 11:36 Andreas Schwab
2003-12-31 12:55 ` Michael Schmitz
2004-01-01 4:43 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 6+ messages in thread
From: Andreas Schwab @ 2003-12-31 11:36 UTC (permalink / raw)
To: linuxppc-dev
I'm getting this badness in redraw_screen when my iBook wakes up with
2.6.0-ben3:
Badness in redraw_screen at drivers/char/vt.c:596
Call trace:
[c000bd50] dump_stack+0x18/0x28
[c0008c44] check_bug_trap+0x84/0xac
[c0008d34] ProgramCheckException+0xc8/0x180
[c00082cc] ret_from_except_full+0x0/0x4c
[c015a94c] redraw_screen+0x2c/0x1e0
[c00376b4] pm_restore_console+0x38/0x48
[c039ef14] 0xc039ef14
[c039f468] 0xc039f468
[c039fdc8] 0xc039fdc8
[c00701d0] sys_ioctl+0x278/0x2f4
[c0007d0c] ret_from_syscall+0x0/0x4c
(The three unnamed frames are inside pmac_wakeup_devices,
powerbook_sleep_Core99 and pmu_ioctl). Does pm_restore_console need
to acquire the console lock, or is that the duty of the callers?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.0-ben3: Badness in redraw_screen
2003-12-31 11:36 2.6.0-ben3: Badness in redraw_screen Andreas Schwab
@ 2003-12-31 12:55 ` Michael Schmitz
2003-12-31 14:15 ` Michael Schmitz
2004-01-01 4:43 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 6+ messages in thread
From: Michael Schmitz @ 2003-12-31 12:55 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
> I'm getting this badness in redraw_screen when my iBook wakes up with
> 2.6.0-ben3:
>
> Badness in redraw_screen at drivers/char/vt.c:596
> Call trace:
> [c000bd50] dump_stack+0x18/0x28
> [c0008c44] check_bug_trap+0x84/0xac
> [c0008d34] ProgramCheckException+0xc8/0x180
> [c00082cc] ret_from_except_full+0x0/0x4c
> [c015a94c] redraw_screen+0x2c/0x1e0
> [c00376b4] pm_restore_console+0x38/0x48
> [c039ef14] 0xc039ef14
> [c039f468] 0xc039f468
> [c039fdc8] 0xc039fdc8
> [c00701d0] sys_ioctl+0x278/0x2f4
> [c0007d0c] ret_from_syscall+0x0/0x4c
>
Similar badness can be had in set_origin (vt.c:568) and set_palette
(vt.c:2851), on my Lombard. That's called from pm_prepare_console, for a
change.
> (The three unnamed frames are inside pmac_wakeup_devices,
> powerbook_sleep_Core99 and pmu_ioctl). Does pm_restore_console need
> to acquire the console lock, or is that the duty of the callers?
None of the other callers does this so I'd guess it needs to be done in
pm_restore_console (and pm_prepare_console).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.0-ben3: Badness in redraw_screen
2003-12-31 12:55 ` Michael Schmitz
@ 2003-12-31 14:15 ` Michael Schmitz
2003-12-31 15:37 ` Kevin B. Hendricks
0 siblings, 1 reply; 6+ messages in thread
From: Michael Schmitz @ 2003-12-31 14:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: debian-powerpc, linuxppc-dev
[CC to debian-powerpc as this was reported there as well ...]
> > I'm getting this badness in redraw_screen when my iBook wakes up with
> > 2.6.0-ben3:
> >
> > Badness in redraw_screen at drivers/char/vt.c:596
> > Call trace:
> > [c000bd50] dump_stack+0x18/0x28
> > [c0008c44] check_bug_trap+0x84/0xac
> > [c0008d34] ProgramCheckException+0xc8/0x180
> > [c00082cc] ret_from_except_full+0x0/0x4c
> > [c015a94c] redraw_screen+0x2c/0x1e0
> > [c00376b4] pm_restore_console+0x38/0x48
> > [c039ef14] 0xc039ef14
> > [c039f468] 0xc039f468
> > [c039fdc8] 0xc039fdc8
> > [c00701d0] sys_ioctl+0x278/0x2f4
> > [c0007d0c] ret_from_syscall+0x0/0x4c
> >
>
> Similar badness can be had in set_origin (vt.c:568) and set_palette
> (vt.c:2851), on my Lombard. That's called from pm_prepare_console, for a
> change.
>
> > (The three unnamed frames are inside pmac_wakeup_devices,
> > powerbook_sleep_Core99 and pmu_ioctl). Does pm_restore_console need
> > to acquire the console lock, or is that the duty of the callers?
>
> None of the other callers does this so I'd guess it needs to be done in
> pm_restore_console (and pm_prepare_console).
The following patch works for me... should we submit that to lkml?
Michael
--- kernel/power/console.c.org 2003-12-31 14:08:04.000000000 +0100
+++ kernel/power/console.c 2003-12-31 14:09:26.000000000 +0100
@@ -20,12 +20,12 @@
#ifdef SUSPEND_CONSOLE
orig_fgconsole = fg_console;
+ acquire_console_sem();
if (vc_allocate(SUSPEND_CONSOLE))
/* we can't have a free VC for now. Too bad,
* we don't want to mess the screen for now. */
return 1;
- acquire_console_sem();
set_console(SUSPEND_CONSOLE);
release_console_sem();
if (vt_waitactive(SUSPEND_CONSOLE)) {
@@ -42,12 +42,14 @@
{
console_loglevel = orig_loglevel;
#ifdef SUSPEND_CONSOLE
+ acquire_console_sem();
set_console(orig_fgconsole);
/* FIXME:
* This following part is left over from swsusp. Is it really needed?
*/
update_screen(fg_console);
+ release_console_sem();
#endif
return;
}
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.0-ben3: Badness in redraw_screen
2003-12-31 14:15 ` Michael Schmitz
@ 2003-12-31 15:37 ` Kevin B. Hendricks
2004-01-02 10:40 ` Michael Schmitz
0 siblings, 1 reply; 6+ messages in thread
From: Kevin B. Hendricks @ 2003-12-31 15:37 UTC (permalink / raw)
To: Michael Schmitz; +Cc: debian-powerpc, linuxppc-dev, Andreas Schwab
Hi,
In the first hunk of your patch you can possibly grab the semaphore and
then do a return 1 with the semaphore held.
If you really need to hold the semaphore to do a vc_allocate then you
should remember to release that semaphore before doing the return 1
So something along the lines of ...
acquire_console_sem();
if (vc_allocate(SUSPEND_CONSOLE)) {
release_console_sme();
return 1;
}
would be better I think if you really do need to hold the console_sem()
before calling vc_allocate.
Kevin
On Dec 31, 2003, at 9:15 AM, Michael Schmitz wrote:
> [CC to debian-powerpc as this was reported there as well ...]
>
>>> I'm getting this badness in redraw_screen when my iBook wakes up with
>>> 2.6.0-ben3:
>>>
>>> Badness in redraw_screen at drivers/char/vt.c:596
>>> Call trace:
>>> [c000bd50] dump_stack+0x18/0x28
>>> [c0008c44] check_bug_trap+0x84/0xac
>>> [c0008d34] ProgramCheckException+0xc8/0x180
>>> [c00082cc] ret_from_except_full+0x0/0x4c
>>> [c015a94c] redraw_screen+0x2c/0x1e0
>>> [c00376b4] pm_restore_console+0x38/0x48
>>> [c039ef14] 0xc039ef14
>>> [c039f468] 0xc039f468
>>> [c039fdc8] 0xc039fdc8
>>> [c00701d0] sys_ioctl+0x278/0x2f4
>>> [c0007d0c] ret_from_syscall+0x0/0x4c
>>>
>>
>> Similar badness can be had in set_origin (vt.c:568) and set_palette
>> (vt.c:2851), on my Lombard. That's called from pm_prepare_console,
>> for a
>> change.
>>
>>> (The three unnamed frames are inside pmac_wakeup_devices,
>>> powerbook_sleep_Core99 and pmu_ioctl). Does pm_restore_console need
>>> to acquire the console lock, or is that the duty of the callers?
>>
>> None of the other callers does this so I'd guess it needs to be done
>> in
>> pm_restore_console (and pm_prepare_console).
>
> The following patch works for me... should we submit that to lkml?
>
> Michael
>
> --- kernel/power/console.c.org 2003-12-31 14:08:04.000000000 +0100
> +++ kernel/power/console.c 2003-12-31 14:09:26.000000000 +0100
> @@ -20,12 +20,12 @@
> #ifdef SUSPEND_CONSOLE
> orig_fgconsole = fg_console;
>
> + acquire_console_sem();
> if (vc_allocate(SUSPEND_CONSOLE))
> /* we can't have a free VC for now. Too bad,
> * we don't want to mess the screen for now. */
> return 1;
>
> - acquire_console_sem();
> set_console(SUSPEND_CONSOLE);
> release_console_sem();
> if (vt_waitactive(SUSPEND_CONSOLE)) {
> @@ -42,12 +42,14 @@
> {
> console_loglevel = orig_loglevel;
> #ifdef SUSPEND_CONSOLE
> + acquire_console_sem();
> set_console(orig_fgconsole);
>
> /* FIXME:
> * This following part is left over from swsusp. Is it really needed?
> */
> update_screen(fg_console);
> + release_console_sem();
> #endif
> return;
> }
>
>
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.0-ben3: Badness in redraw_screen
2003-12-31 11:36 2.6.0-ben3: Badness in redraw_screen Andreas Schwab
2003-12-31 12:55 ` Michael Schmitz
@ 2004-01-01 4:43 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2004-01-01 4:43 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
On Wed, 2003-12-31 at 22:36, Andreas Schwab wrote:
> I'm getting this badness in redraw_screen when my iBook wakes up with
> 2.6.0-ben3:
Just a warning that I added to a bunch of VT functions to spot various
races in the VT code. I've started adding more grabs of the console
semaphore here or there though I 'forgot' some way the sleep code
before pushing 2.6.0-ben3. There's a 2.6.1-rc1-ben1 now online with
that problem gone
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.0-ben3: Badness in redraw_screen
2003-12-31 15:37 ` Kevin B. Hendricks
@ 2004-01-02 10:40 ` Michael Schmitz
0 siblings, 0 replies; 6+ messages in thread
From: Michael Schmitz @ 2004-01-02 10:40 UTC (permalink / raw)
To: Kevin B.Hendricks
Cc: Michael Schmitz, debian-powerpc, linuxppc-dev, Andreas Schwab
> In the first hunk of your patch you can possibly grab the semaphore and
> then do a return 1 with the semaphore held.
>
> If you really need to hold the semaphore to do a vc_allocate then you
> should remember to release that semaphore before doing the return 1
You're absolutely right. Thanks for spotting this.
> So something along the lines of ...
>
> acquire_console_sem();
> if (vc_allocate(SUSPEND_CONSOLE)) {
> release_console_sme();
> return 1;
> }
>
> would be better I think if you really do need to hold the console_sem()
> before calling vc_allocate.
Unfortunately, to avoid the warning we need to hold the semaphore before
calling vc_allocate, as this in turn will call the routines complaining
about the semaphore.
I don't think we can move the locking into vc_allocate; another function
might call this with the lock already held?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-02 10:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-31 11:36 2.6.0-ben3: Badness in redraw_screen Andreas Schwab
2003-12-31 12:55 ` Michael Schmitz
2003-12-31 14:15 ` Michael Schmitz
2003-12-31 15:37 ` Kevin B. Hendricks
2004-01-02 10:40 ` Michael Schmitz
2004-01-01 4:43 ` Benjamin Herrenschmidt
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).