Jim Gettys wrote:
On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote:
What you say sounds good, assuming that the cost of a sleep is less than
the cost of the busy wait. But this may be hardware, the waits may be
very small and frequent, and if it's hitting a small hardware window
like
On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote:
>
> What you say sounds good, assuming that the cost of a sleep is less than
> the cost of the busy wait. But this may be hardware, the waits may be
> very small and frequent, and if it's hitting a small hardware window
> like retrace, de
Jim Gettys wrote:
On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote:
* 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 e
On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote:
> * 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 app
* 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
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
* 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 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
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
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
> S
> 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
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?
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
30 matches
Mail list logo
