On Saturday 31 March 2007 08:36, Jeremy Fitzhardinge wrote:
> When I run 2.6.21-rc5 + Andi's x86 patches + paravirt_ops patches, I've
> been getting my machine shut down with critical thermal shutdown messages:
Hmm, don't think there's anything either in x86 that would touch this code.
But can you
On Sat, Mar 31 2007, Adrian Bunk wrote:
> On Sat, Mar 31, 2007 at 10:52:59AM +0800, Jeff Chua wrote:
> > On 3/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > >Subject: ThinkPad doesn't resume from suspend to RAM
> > >References : http://lkml.org/lkml/2007/2/27/80
> > > http:/
Hi,
My whole system freeze from time to time when using acpi. I don't get this
problem without acpi. My motherboard is an asus P4S8X
# cat /proc/version
Linux version 2.6.20-rt8 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo
4.1.1-r3))
#1 SMP PREEMPT Fri Mar 30 23:15:59 CEST 2007
lspci -vvv:
0
On 31/03/07 02:18 +0200, Johannes Berg wrote:
> On Fri, 2007-03-30 at 17:57 -0600, Jordan Crouse wrote:
>
> I think the sources file isn't really useful, a
> grep -l 1 /sys/power/wakeup/*
> should do.
I was just trying to be friendly to folks who may be used to the ACPI
method.
> About differ
On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> >
> > Subject: kernels fail to boot with drives on ATIIXP controller
> > (ACPI/IRQ related)
> > References : https://bugzilla.redhat.com/bugzilla/sho
On 31/03/07 02:21 +0200, Johannes Berg wrote:
> > > http://wiki.laptop.org/go/Power_Management_Interface
>
> Hm, another thing. The RTC alarm wakeup event, wouldn't that require
> programming the time too? And if so, should that be done through the
> power interface to it?
Probably not - its pret
On Friday 30 March 2007 5:21 pm, Johannes Berg wrote:
> Hm, another thing. The RTC alarm wakeup event, wouldn't that require
> programming the time too? And if so, should that be done through the
> power interface to it?
There's already a cross-platform interface to RTC wakeup alarms; no
new inte
On Friday 30 March 2007 5:18 pm, Johannes Berg wrote:
> On Fri, 2007-03-30 at 17:57 -0600, Jordan Crouse wrote:
> About different possible states: I think each of those can have
> different possible wakeup sources, ACPI can afaik go to S4 and still be
> able to configure the wakeup sources. So I s
On Friday 30 March 2007 4:57 pm, Jordan Crouse wrote:
> Hey all -
>
> I'm happy to report that the OLPC power management effort is proceeding
> nicely. We have suspend to RAM functional, and the system is resuming
> back to the framebuffer console.
Good to hear that. Now, if the same could be s
On 31/03/07 09:52 -0700, David Brownell wrote:
> USB once worked fine (I spent more than enough time testing it in all
> kinds of configs) but usbcore has changed a lot since then ... I hear
> that some of the root hub stuff got broken.
Marcelo is working hard on the USB. I'm sure he wouldn't say
On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
>
> +static struct sysdev_class hpet_class = {
> + set_kset_name("hpet"),
> + .suspend
On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.
me>Confirmed that suspend/resume disk/ram works on X60s with
me>CONFIG_HPET_TIMER=y an
On Sun, 2007-04-01 at 00:01 +0800, Jeff Chua wrote:
> On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> > caused by time keeping / tick management resume happening before the
> > HPET resume.
>
>
> me>Confirmed th
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.
Well, this is why we probably should try to get away from the "system
device"
On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > sys device suspend / resume ordering is not guaranteed and relies on the
> > registering order.
>
> Well, t
On Sat, Mar 31, 2007 at 06:33:20PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
> >
> > On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > >
> > > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > > sys device suspend / resume ord
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
> On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > >
> > > Subject: kernels fail to boot with drives on ATIIXP controller
> > > (ACPI
On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
> On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> > Subject: Add suspend/resume for HPET
> > This adds support of suspend/resume on i386 for HPET
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
> >
> > +static struct sysdev_
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> Right, but clock - sources/events need to be extremly late suspended and
> early resumed. How can we ensure this ?
Make them be at the top of the device tree by adding them early. That's
the whole point of the device tree after all - we have an o
On Sat, Mar 31, 2007 at 09:53:43AM -0700, Linus Torvalds wrote:
> Make them be at the top of the device tree by adding them early. That's
> the whole point of the device tree after all - we have an ordering that is
> enforced by its topology, and that we sort by when things were added.
>
> Right
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
[...]
> So the only thing that needs to be done is to make sure that we add
> t
On Sat, 31 Mar 2007, Maxim Levitsky wrote:
>
> So maybe I was right afrer all,
> Maybe it is better to add a suspend/resume hook to each clock source and call
> it from timekeeping_resume() ?
Umm.. WHy not make the device tree look like this:
-- "clocksource" -- +-- HPET
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Umm.. WHy not make the device tree look like this:
>
> -- "clocksource" -- +-- HPET
> |
> +-- TSC
> |
> +-- i8259
>
On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
>
> Make them be at the top of the device tree by adding them earl
On Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote:
> yeah. There's some practical problems that need to be sorted out: much
> of the current GTOD code is irq-driven (and all GTOD locks are
> irq-safe), while the sysfs code needs to run in process-context level.
>
> Clocksources 'arrive' and
( please remove obsolute [EMAIL PROTECTED] from further messages!! )
On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
>
> i dont think there's any particular problem here because suspend/resume
> wont be done during bootup - but we might need a way to move a device to
> earlier spots in
I assume this is an acpi table bug.
Is there any way in which we can get a workaround in place to fix this for real?
Begin forwarded message:
Date: Sat, 31 Mar 2007 18:00:34 +0300 (EEST)
From: Mikko Tiihonen <[EMAIL PROTECTED]>
To: Nicolas Mailhot <[EMAIL PROTECTED]>
Cc: Krzysztof Halasa <[EMA
On Saturday 31 March 2007 11:16 am, Jordan Crouse wrote:
> On 31/03/07 09:52 -0700, David Brownell wrote:
> > You seem to be completely ignoring the /sys/devices//power/wakeup
> > event attributes. Why?
>
> Complete and total ignorance that they even existed. I guess I should
> pay more at
On Sat, 2007-03-31 at 12:16 -0600, Jordan Crouse wrote:
> On 31/03/07 09:52 -0700, David Brownell wrote:
> > USB once worked fine (I spent more than enough time testing it in all
> > kinds of configs) but usbcore has changed a lot since then ... I hear
> > that some of the root hub stuff got broken
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute [EMAIL PROTECTED] from further messages!! )
>
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> >
> > i dont think there's any particular problem here because suspend/resume
> > wont be done during boo
On 31/03/07 11:57 -0700, David Brownell wrote:
> The other part is the platform code. On embedded hardware that's usually
> just calling device_init_wakeup() before registering the platform devices,
> and supporting enable_irq_wake(). On x86 that gets messy; ACPI is there,
> and PCI initializatio
On Saturday 31 March 2007 6:01 pm, Jordan Crouse wrote:
> On 31/03/07 11:57 -0700, David Brownell wrote:
> > The other part is the platform code. On embedded hardware that's usually
> > just calling device_init_wakeup() before registering the platform devices,
> > and supporting enable_irq_wake().
On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered. Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.
I tes
On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
> On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > for those will all get grouped together ... suspended "very late" and
> > resumed "very early", regardless of when they get registered. Pretty
> > much the driver model parts of what Linu
Alexey Starikovskiy wrote:
> Could you try to unload or disable hardware sensors and check if it
> helps?
> CONFIG_I2C=m
> CONFIG_I2C_ALGOBIT=m
> CONFIG_I2C_ALGOPCA=m
> CONFIG_I2C_I810=m
> CONFIG_I2C_PIIX4=m
> CONFIG_SENSORS_DS1337=m
> CONFIG_SENSORS_DS1374=m
> CONFIG_SENSORS_EEPROM=m
> CONFIG_SENS
35 matches
Mail list logo
