* 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 unsubs
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 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 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 t
* 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
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 ab
* 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_vers
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 D
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 pr
* 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
>
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 c
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 s
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 t
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 se
* 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)
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
* 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.4566
* 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 0
* 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 su
* 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
> > 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 bisecti
> 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
> &
> 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
> diff
* 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 ac
* 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 bugg
[ 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 <[EM
> 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 B
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 l
34 matches
Mail list logo
