* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Some day we may have modesetting support in the kernel for some
> > graphics hw, right now it's pretty damn spotty.
>
> Yep, that's the way to go.
hey, i wildly supported this approach ever since 1996, when GGI came up
:-/
Ingo
-
To
* Pavel Machek [EMAIL PROTECTED] wrote:
Some day we may have modesetting support in the kernel for some
graphics hw, right now it's pretty damn spotty.
Yep, that's the way to go.
hey, i wildly supported this approach ever since 1996, when GGI came up
:-/
Ingo
-
To unsubscribe
On Sat, 2007-03-17 at 23:41 +0200, Michael S. Tsirkin wrote:
> > > a quick ping: on your box that doesnt resume - if you can log in over
> > > the network after resume (or somehow run shell commands), does 'date'
> > > advance properly or not? (or do you not get that far to be able to
> > >
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: [2/6] 2.6.21-rc2: known regressions
>
> > Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> > Subject: Re: [2/6] 2.6.21-rc2: known regressions
> >
> >
> > Michael,
> >
> > *
Quoting Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
Michael,
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
2. First disk access after
On Sat, 2007-03-17 at 23:41 +0200, Michael S. Tsirkin wrote:
a quick ping: on your box that doesnt resume - if you can log in over
the network after resume (or somehow run shell commands), does 'date'
advance properly or not? (or do you not get that far to be able to
tell?)
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> Subject: Re: [2/6] 2.6.21-rc2: known regressions
>
>
> Michael,
>
> * Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
>
> > > > 2. First disk access after resume takes a couple of minutes
> > >
On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Unfortunately, these tend to crash the box when you pass wrong
> > options, and I do not see easy way to test "can user see whats on
> > display" automatically.
>
> you could perhaps
On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
Unfortunately, these tend to crash the box when you pass wrong
options, and I do not see easy way to test can user see whats on
display automatically.
you could perhaps try what X's
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
Michael,
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
2. First disk access after resume takes a couple of minutes
(seemed instant with 2.6.20) during this time no new messages show
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Probably tweaking the webpage doesnt help because people dont get
> > there - as the results plainly show it. Maybe some more automation
> > would be useful too, a tool that detects failed resume and tries all
> > those options that makes sense on
* Pavel Machek [EMAIL PROTECTED] wrote:
Probably tweaking the webpage doesnt help because people dont get
there - as the results plainly show it. Maybe some more automation
would be useful too, a tool that detects failed resume and tries all
those options that makes sense on that box
Hi!
> > Ok. To be honest, you are the first reporter that seems to have read
> > the documentation above, but not understood what to do.
>
> thanks for the compliment ;-) _I_ very much know what to do (i mailed
> the right person after all ;), but i dont really count and on the 6
(Can we get
Hi!
> > > Even if one doesn't use the fb console at all, radeonfb apparently
> > > is still required on some ThinkPad models to work around BIOS bugs:
> > >
> > > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
> >
> >
> > s2ram should be
* Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> > btw., the s2ram database seems quite a bit spotty:
> >
> > $ ./s2ram -n
> > Machine is unknown.
> > This machine can be identified by:
> > sys_vendor = "System manufacturer"
> > sys_product = "System Product Name"
> >
On Sat, Mar 10, 2007 at 12:43:01PM +0100, Stefan Seyfried wrote:
> On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
> >
> > i'm wondering, do you have any idea how Windows handles the
> > suspend/resume quirks problem area? Do they "curse BIOS vendors and
> > maintain a large DB of
On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
> > s2ram should be able to work around this, it has parts from
> > radeontool. (suspend.sf.net).
>
> i'm wondering, do you have any idea how Windows handles the
> suspend/resume quirks
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Even if one doesn't use the fb console at all, radeonfb apparently
> > is still required on some ThinkPad models to work around BIOS bugs:
> >
> > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
* Pavel Machek [EMAIL PROTECTED] wrote:
s2ram should be able to work around this, it has parts from
radeontool. (suspend.sf.net).
i'm wondering, do you have any idea how Windows handles the
suspend/resume quirks problem
On Sat, Mar 10, 2007 at 12:43:01PM +0100, Stefan Seyfried wrote:
On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote:
i'm wondering, do you have any idea how Windows handles the
suspend/resume quirks problem area? Do they curse BIOS vendors and
maintain a large DB of DMI-driven
* Stefan Seyfried [EMAIL PROTECTED] wrote:
btw., the s2ram database seems quite a bit spotty:
$ ./s2ram -n
Machine is unknown.
This machine can be identified by:
sys_vendor = System manufacturer
sys_product = System Product Name
sys_version = System Version
Hi!
Ok. To be honest, you are the first reporter that seems to have read
the documentation above, but not understood what to do.
thanks for the compliment ;-) _I_ very much know what to do (i mailed
the right person after all ;), but i dont really count and on the 6
(Can we get the
* Pavel Machek [EMAIL PROTECTED] wrote:
Even if one doesn't use the fb console at all, radeonfb apparently
is still required on some ThinkPad models to work around BIOS bugs:
http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
s2ram
Hi!
Even if one doesn't use the fb console at all, radeonfb apparently
is still required on some ThinkPad models to work around BIOS bugs:
http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
s2ram should be able to work around
Hi!
> > You're better off using the VGA console, and lettign X re-initialize the
> > graphics device. That generally at least has a reasonably good chance of
> > working.
> >
> > Re-initializing graphics modes really is very hard. You can try with the
> > BIOS video hack (I forget the kernel
On Thu, Mar 08, 2007, Linus Torvalds wrote:
> On Fri, 9 Mar 2007, Ingo Molnar wrote:
> >
> > disabling the following radeonfb options in the .config made resume work
> > again:
>
> In general, don't even *try* to use radeonfb for suspend/resume.
>
> I don't think it has ever worked, except on
On Fri, 9 Mar 2007, Ingo Molnar wrote:
> > Some day we may have modesetting support in the kernel for some
> > graphics hw, right now it's pretty damn spotty.
>
> having no video is what i'd have expected - but getting a /hang/ is not
> what i'd have expected.
I debugged a case exactly like
Hi!
> > disabling the following radeonfb options in the .config made resume work
> > again:
>
> In general, don't even *try* to use radeonfb for suspend/resume.
>
> I don't think it has ever worked, except on some very rare laptops
> (largely PPC Macs) where people had enough information to
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > disabling the following radeonfb options in the .config made resume
> > work again:
>
> In general, don't even *try* to use radeonfb for suspend/resume.
>
> I don't think it has ever worked, except on some very rare laptops
> (largely PPC Macs)
* Linus Torvalds [EMAIL PROTECTED] wrote:
disabling the following radeonfb options in the .config made resume
work again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where
Hi!
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people had enough information to set up the
On Fri, 9 Mar 2007, Ingo Molnar wrote:
Some day we may have modesetting support in the kernel for some
graphics hw, right now it's pretty damn spotty.
having no video is what i'd have expected - but getting a /hang/ is not
what i'd have expected.
I debugged a case exactly like this
On Thu, Mar 08, 2007, Linus Torvalds wrote:
On Fri, 9 Mar 2007, Ingo Molnar wrote:
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very
Hi!
You're better off using the VGA console, and lettign X re-initialize the
graphics device. That generally at least has a reasonably good chance of
working.
Re-initializing graphics modes really is very hard. You can try with the
BIOS video hack (I forget the kernel command line
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> disabling the following radeonfb options in the .config made resume work
> again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Here's another suspend/resume artifact: one of my boxes wouldnt
> > resume, it hangs at:
> >
> > [1.456633] pci :00:18.2: resuming
> > [1.456641] pci :00:18.3: resuming
> > [1.456648] 8139too :05:07.0: resuming
> > [
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Here's another suspend/resume artifact: one of my boxes wouldnt
> resume, it hangs at:
>
> [1.456633] pci :00:18.2: resuming
> [1.456641] pci :00:18.3: resuming
> [1.456648] 8139too :05:07.0: resuming
> [1.456667] radeonfb
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Thomas found a new twist to this today: applying the patch below
> (which turns on ATA_DEBUG) made the SATA problem go away on his
> laptop. Michael, could you try this patch, does it change the behavior
> of your laptop in any way?
Here's another
* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> > Michael - does your 'date' output advance after resume? If not then
> > i'd say it's a NO_HZ related problem. If yes then i'd guess it's the
> > SATA problem.
>
> I'll test, but I have NO_HZ off for now.
there can still be effects of it
> > 2. First disk access after resume takes a couple of minutes
> >(seemed instant with 2.6.20) during this time no new messages show on
> > console
>
> Yeah, there is some problem with SATA resume. It would be beautiful if the
> people who actually see this could narrow it down with
> Quoting Ingo Molnar <[EMAIL PROTECTED]>:
> Subject: Re: [2/6] 2.6.21-rc2: known regressions
>
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of
> > > windows
&g
> Quoting Linus Torvalds <[EMAIL PROTECTED]>:
> >
> > Here's the status with -rc3: better, but still does not work as well as
> > 2.6.20.
>
> Ok. I think we mostly solved the irq-related stuff, but you might want to
> check whether you have CONFIG_NOHZ on or off and whether that makes a
>
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > 2. First disk access after resume takes a couple of minutes
> >(seemed instant with 2.6.20) during this time no new messages
> >show on console
>
> Yeah, there is some problem with SATA resume. It would be beautiful if
> the people who
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Michael - does your 'date' output advance after resume? If not then
> i'd say it's a NO_HZ related problem. [...]
in that case please do this on such a 'frozen date' system:
echo q > /proc/sysrq-trigger
and then send us the hw-timers info.
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of
> > windows
> >after waiting for some 10 min, I rebooted. no new messages showed
> >up in /var/log/messages
>
> I think this is likely just more of the disk being
[ Eric, Ingo, can you double-check the timer initialization after resume?
We appear to have several reports of date not advancing, and while this
could be some SATA issue, it could easily be a timer tick issue too ]
On Thu, 8 Mar 2007, Michael S. Tsirkin wrote:
>
> Here's the status with
On 3/8/07, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> Quoting Adrian Bunk <[EMAIL PROTECTED]>:
> Subject: [2/6] 2.6.21-rc2: known regressions
>
> Subject: ThinkPad T60: no screen after suspend to RAM
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter : Michael S. Tsirkin
> Quoting Adrian Bunk <[EMAIL PROTECTED]>:
> Subject: [2/6] 2.6.21-rc2: known regressions
>
> Subject: ThinkPad T60: no screen after suspend to RAM
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter : Michael S. Tsirkin <[EMAIL PROTECTED]>
> Status : unknown
Here's the status
On Wed, 07 Mar 2007 06:09:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Adrian Bunk wrote:
> > Subject: AT keyboard only works with pci=noacpi
> > References : http://lkml.org/lkml/2007/3/3/68
> > Submitter : Ash Milsted <[EMAIL PROTECTED]>
> > Status : unknown
>
>
> sounds like a
On Wed, 07 Mar 2007 06:09:06 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Adrian Bunk wrote:
Subject: AT keyboard only works with pci=noacpi
References : http://lkml.org/lkml/2007/3/3/68
Submitter : Ash Milsted [EMAIL PROTECTED]
Status : unknown
sounds like a BIOS bug, even
Quoting Adrian Bunk [EMAIL PROTECTED]:
Subject: [2/6] 2.6.21-rc2: known regressions
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Status : unknown
Here's the status with -rc3:
On 3/8/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting Adrian Bunk [EMAIL PROTECTED]:
Subject: [2/6] 2.6.21-rc2: known regressions
Subject: ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin [EMAIL
[ Eric, Ingo, can you double-check the timer initialization after resume?
We appear to have several reports of date not advancing, and while this
could be some SATA issue, it could easily be a timer tick issue too ]
On Thu, 8 Mar 2007, Michael S. Tsirkin wrote:
Here's the status with
* Linus Torvalds [EMAIL PROTECTED] wrote:
3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of
windows
after waiting for some 10 min, I rebooted. no new messages showed
up in /var/log/messages
I think this is likely just more of the disk being buggered, but
* Ingo Molnar [EMAIL PROTECTED] wrote:
Michael - does your 'date' output advance after resume? If not then
i'd say it's a NO_HZ related problem. [...]
in that case please do this on such a 'frozen date' system:
echo q /proc/sysrq-trigger
and then send us the hw-timers info.
* Linus Torvalds [EMAIL PROTECTED] wrote:
2. First disk access after resume takes a couple of minutes
(seemed instant with 2.6.20) during this time no new messages
show on console
Yeah, there is some problem with SATA resume. It would be beautiful if
the people who actually see
Quoting Linus Torvalds [EMAIL PROTECTED]:
Here's the status with -rc3: better, but still does not work as well as
2.6.20.
Ok. I think we mostly solved the irq-related stuff, but you might want to
check whether you have CONFIG_NOHZ on or off and whether that makes a
difference.
Quoting Ingo Molnar [EMAIL PROTECTED]:
Subject: Re: [2/6] 2.6.21-rc2: known regressions
* Linus Torvalds [EMAIL PROTECTED] wrote:
3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of
windows
after waiting for some 10 min, I rebooted. no new messages showed
2. First disk access after resume takes a couple of minutes
(seemed instant with 2.6.20) during this time no new messages show on
console
Yeah, there is some problem with SATA resume. It would be beautiful if the
people who actually see this could narrow it down with bisection. It
* Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Michael - does your 'date' output advance after resume? If not then
i'd say it's a NO_HZ related problem. If yes then i'd guess it's the
SATA problem.
I'll test, but I have NO_HZ off for now.
there can still be effects of it (the
* Ingo Molnar [EMAIL PROTECTED] wrote:
Thomas found a new twist to this today: applying the patch below
(which turns on ATA_DEBUG) made the SATA problem go away on his
laptop. Michael, could you try this patch, does it change the behavior
of your laptop in any way?
Here's another
* Ingo Molnar [EMAIL PROTECTED] wrote:
Here's another suspend/resume artifact: one of my boxes wouldnt
resume, it hangs at:
[1.456633] pci :00:18.2: resuming
[1.456641] pci :00:18.3: resuming
[1.456648] 8139too :05:07.0: resuming
[1.456667] radeonfb
* Ingo Molnar [EMAIL PROTECTED] wrote:
Here's another suspend/resume artifact: one of my boxes wouldnt
resume, it hangs at:
[1.456633] pci :00:18.2: resuming
[1.456641] pci :00:18.3: resuming
[1.456648] 8139too :05:07.0: resuming
[1.456667] radeonfb
On Fri, 9 Mar 2007, Ingo Molnar wrote:
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people had
On Wed, 7 Mar 2007, Jeff Garzik wrote:
>
> Adrian Bunk wrote:
> > Subject: AT keyboard only works with pci=noacpi
> > References : http://lkml.org/lkml/2007/3/3/68
> > Submitter : Ash Milsted <[EMAIL PROTECTED]>
> > Status : unknown
>
> sounds like a BIOS bug, even though it appears to
Adrian Bunk wrote:
Subject: AT keyboard only works with pci=noacpi
References : http://lkml.org/lkml/2007/3/3/68
Submitter : Ash Milsted <[EMAIL PROTECTED]>
Status : unknown
sounds like a BIOS bug, even though it appears to be a regression?
-
To unsubscribe from this list: send the
Adrian Bunk wrote:
Subject: AT keyboard only works with pci=noacpi
References : http://lkml.org/lkml/2007/3/3/68
Submitter : Ash Milsted [EMAIL PROTECTED]
Status : unknown
sounds like a BIOS bug, even though it appears to be a regression?
-
To unsubscribe from this list: send the
On Wed, 7 Mar 2007, Jeff Garzik wrote:
Adrian Bunk wrote:
Subject: AT keyboard only works with pci=noacpi
References : http://lkml.org/lkml/2007/3/3/68
Submitter : Ash Milsted [EMAIL PROTECTED]
Status : unknown
sounds like a BIOS bug, even though it appears to be a
68 matches
Mail list logo
