linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Suspend to RAM fault in VT when resuming
@ 2007-03-13 20:30 Tim Gardner
  2007-03-13 21:24 ` Pavel Machek
  0 siblings, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2007-03-13 20:30 UTC (permalink / raw)
  To: Pavel Machek; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Pavel,

I've chased one of the 'Suspend to RAM' resume problems to a specific
line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
= val', which appears to be causing the problem. I've verified that the
pointer is not NULL, but don't know if its really valid. Its pretty
tough to tell what is happening, but on a Dell XPS it just hangs. A Dell
Precision blinks the keyboard lights.

Since I don't know anything about video programming, I though perhaps
you might have an opinion.

rtg
-- 
Tim Gardner tim.gardner@ubuntu.com

[-- Attachment #2: vt.diff --]
[-- Type: text/x-patch, Size: 627 bytes --]

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index c3f8e38..43a0904 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -98,6 +98,7 @@
 #include <linux/pm.h>
 #include <linux/font.h>
 #include <linux/bitops.h>
+#include <linux/resume-trace.h>
 
 #include <asm/io.h>
 #include <asm/system.h>
@@ -2263,7 +2264,9 @@ static void vt_console_print(struct console *co, const char *b, unsigned count)
 			if (c == 10 || c == 13)
 				continue;
 		}
+TRACE_RESUME(0);
 		scr_writew((vc->vc_attr << 8) + c, (unsigned short *)vc->vc_pos);
+TRACE_RESUME(0);
 		cnt++;
 		if (myx == vc->vc_cols - 1) {
 			vc->vc_need_wrap = 1;

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: Suspend to RAM fault in VT when resuming
  2007-03-13 20:30 Suspend to RAM fault in VT when resuming Tim Gardner
@ 2007-03-13 21:24 ` Pavel Machek
  2007-03-14  1:42   ` Tim Gardner
  0 siblings, 1 reply; 6+ messages in thread
From: Pavel Machek @ 2007-03-13 21:24 UTC (permalink / raw)
  To: Tim Gardner; +Cc: linux-kernel

Hi1

> I've chased one of the 'Suspend to RAM' resume problems to a specific
> line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with

Has suspend/resume ever worked on that hardware?

> TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
> = val', which appears to be causing the problem. I've verified that the
> pointer is not NULL, but don't know if its really valid. Its pretty
> tough to tell what is happening, but on a Dell XPS it just hangs. A Dell
> Precision blinks the keyboard lights.

It is possible that video is not initialized at that point, and that
hardware goes seriously unhappy when you access non-existing vga. Does
it resume ok when you completely disable video support? 


								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Suspend to RAM fault in VT when resuming
  2007-03-13 21:24 ` Pavel Machek
@ 2007-03-14  1:42   ` Tim Gardner
  2007-03-19 15:07     ` Pavel Machek
  0 siblings, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2007-03-14  1:42 UTC (permalink / raw)
  To: Pavel Machek; +Cc: linux-kernel

Pavel Machek wrote:
> Hi1
> 
>> I've chased one of the 'Suspend to RAM' resume problems to a specific
>> line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
> 
> Has suspend/resume ever worked on that hardware?
> 
>> TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
>> = val', which appears to be causing the problem. I've verified that the
>> pointer is not NULL, but don't know if its really valid. Its pretty
>> tough to tell what is happening, but on a Dell XPS it just hangs. A Dell
>> Precision blinks the keyboard lights.
> 
> It is possible that video is not initialized at that point, and that
> hardware goes seriously unhappy when you access non-existing vga. Does
> it resume ok when you completely disable video support? 
> 
> 
> 								Pavel
> 
> 

Resume works on the Dell XPS with the Ubuntu Edgy release
Ubuntu-2.6.17-10.25 (2.6.17 plus a zillion fixes). Ubuntu's git tree is
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git.
Ubuntu-2.6.17-8.21 is the first version where resume works, but there
are a boatload of changes in ACPI and SW suspend between that and the
previous tag Ubuntu-2.6.17-7.20. I don't know what made SW suspend work,
but even knowing that won't tell me what broke it again.

I've been avoiding the bisect process because it is quite time consuming
on my slow machine, there is much branch weirdness, and I'm not that
good with git. I thought if I narrowed the failure down to a small chunk
of code in 2.6.21-rc3, then the answer might be obvious. No such luck, huh?

This crash behaves like the video memory space has become unmapped. Is
that possible?

rtg
-- 
Tim Gardner tim.gardner@ubuntu.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Suspend to RAM fault in VT when resuming
  2007-03-14  1:42   ` Tim Gardner
@ 2007-03-19 15:07     ` Pavel Machek
  2007-03-19 16:15       ` Tim Gardner
  0 siblings, 1 reply; 6+ messages in thread
From: Pavel Machek @ 2007-03-19 15:07 UTC (permalink / raw)
  To: Tim Gardner; +Cc: linux-kernel

On Tue 2007-03-13 19:42:07, Tim Gardner wrote:
> Pavel Machek wrote:
> > Hi1
> > 
> >> I've chased one of the 'Suspend to RAM' resume problems to a specific
> >> line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
> > 
> > Has suspend/resume ever worked on that hardware?
> > 
> >> TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
> >> = val', which appears to be causing the problem. I've verified that the
> >> pointer is not NULL, but don't know if its really valid. Its pretty
> >> tough to tell what is happening, but on a Dell XPS it just hangs. A Dell
> >> Precision blinks the keyboard lights.
> > 
> > It is possible that video is not initialized at that point, and that
> > hardware goes seriously unhappy when you access non-existing vga. Does
> > it resume ok when you completely disable video support? 
> 
> Resume works on the Dell XPS with the Ubuntu Edgy release
> Ubuntu-2.6.17-10.25 (2.6.17 plus a zillion fixes). Ubuntu's git tree is
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git.
> Ubuntu-2.6.17-8.21 is the first version where resume works, but there
> are a boatload of changes in ACPI and SW suspend between that and the
> previous tag Ubuntu-2.6.17-7.20. I don't know what made SW suspend work,
> but even knowing that won't tell me what broke it again.
> 
> I've been avoiding the bisect process because it is quite time consuming
> on my slow machine, there is much branch weirdness, and I'm not that
> good with git. I thought if I narrowed the failure down to a small chunk
> of code in 2.6.21-rc3, then the answer might be obvious. No such luck, huh?
> 
> This crash behaves like the video memory space has become unmapped. Is
> that possible?

That seems improbable. It is physical ram, we do not unmap that..

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Suspend to RAM fault in VT when resuming
  2007-03-19 15:07     ` Pavel Machek
@ 2007-03-19 16:15       ` Tim Gardner
  2007-03-19 20:45         ` Pavel Machek
  0 siblings, 1 reply; 6+ messages in thread
From: Tim Gardner @ 2007-03-19 16:15 UTC (permalink / raw)
  To: Pavel Machek; +Cc: linux-kernel

Pavel Machek wrote:
> On Tue 2007-03-13 19:42:07, Tim Gardner wrote:
>> Pavel Machek wrote:
>>> Hi1
>>>
>>>> I've chased one of the 'Suspend to RAM' resume problems to a specific
>>>> line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
>>> Has suspend/resume ever worked on that hardware?
>>>
>>>> TRACE_RESUME() instrumentation. The macro scr_writew resolves to '*addr
>>>> = val', which appears to be causing the problem. I've verified that the
>>>> pointer is not NULL, but don't know if its really valid. Its pretty
>>>> tough to tell what is happening, but on a Dell XPS it just hangs. A Dell
>>>> Precision blinks the keyboard lights.
>>> It is possible that video is not initialized at that point, and that
>>> hardware goes seriously unhappy when you access non-existing vga. Does
>>> it resume ok when you completely disable video support? 
>> Resume works on the Dell XPS with the Ubuntu Edgy release
>> Ubuntu-2.6.17-10.25 (2.6.17 plus a zillion fixes). Ubuntu's git tree is
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git.
>> Ubuntu-2.6.17-8.21 is the first version where resume works, but there
>> are a boatload of changes in ACPI and SW suspend between that and the
>> previous tag Ubuntu-2.6.17-7.20. I don't know what made SW suspend work,
>> but even knowing that won't tell me what broke it again.
>>
>> I've been avoiding the bisect process because it is quite time consuming
>> on my slow machine, there is much branch weirdness, and I'm not that
>> good with git. I thought if I narrowed the failure down to a small chunk
>> of code in 2.6.21-rc3, then the answer might be obvious. No such luck, huh?
>>
>> This crash behaves like the video memory space has become unmapped. Is
>> that possible?
> 
> That seems improbable. It is physical ram, we do not unmap that..
> 

The machine _has_ just come out of BIOS ACPI space. Perhaps PCI
resources for video are hosed. All I can tell for sure is that this one
line appears to cause some kind of crash. I'm working on finding some
1394 resources to see if I can nail this one.

-- 
Tim Gardner tim.gardner@ubuntu.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Suspend to RAM fault in VT when resuming
  2007-03-19 16:15       ` Tim Gardner
@ 2007-03-19 20:45         ` Pavel Machek
  0 siblings, 0 replies; 6+ messages in thread
From: Pavel Machek @ 2007-03-19 20:45 UTC (permalink / raw)
  To: Tim Gardner; +Cc: linux-kernel

Hi!

> >> This crash behaves like the video memory space has become unmapped. Is
> >> that possible?
> > 
> > That seems improbable. It is physical ram, we do not unmap that..
> 
> The machine _has_ just come out of BIOS ACPI space. Perhaps PCI
> resources for video are hosed. All I can tell for sure is that this
> one

Yes, this is possible, AFAICT. I'm just saying that it is unlikely to
be unmapped at pagetable level.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-03-19 20:45 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-13 20:30 Suspend to RAM fault in VT when resuming Tim Gardner
2007-03-13 21:24 ` Pavel Machek
2007-03-14  1:42   ` Tim Gardner
2007-03-19 15:07     ` Pavel Machek
2007-03-19 16:15       ` Tim Gardner
2007-03-19 20:45         ` Pavel Machek

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).