Once reading the ACPI spec I noticed that ACPI supports this feature
so it is qute nice to implement it, since this will prevent resume from disk
what hardware was changed.
But.. how many bioses are broken regarding this feature
If they are broken though, how likely is it they'll have
This is did not happen before; I am not sure right now what caused this (i.e.
battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming battery is loading and at 94%. Sysfs displays
battery state as Full:
UEVENT[1199264702.345795]
Andrey Borzenkov wrote:
This is did not happen before; I am not sure right now what caused this (i.e.
battery aging or some software change) nor whether this is kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming battery is loading and at 94%. Sysfs displays
battery state as Full:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Hi,
Some device drivers register CPU hotplug notifiers and use them to
destroy device objects when removing the corresponding CPUs and to
create these objects when adding the CPUs back.
Unfortunately, this is not the right thing to do
On Wednesday, 2 of January 2008, Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Hi,
Some device drivers register CPU hotplug notifiers and use them to
destroy device objects when removing the corresponding CPUs and to
create these objects when adding the CPUs
On Wednesday 02 January 2008, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
This is did not happen before; I am not sure right now what caused this
(i.e.
battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming
(David Brownell Cc:-ed too)
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Well, we have the following test script in the userland suspend
package that is supposed to work right now:
#!/bin/bash
date
cd /sys/class/rtc/rtc0
echo $(( $(cat since_epoch) + 20 )) wakealarm
s2ram
date
On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
It sometimes is necessary to destroy a device object during a suspend or
hibernation, but the PM core is supposed to control all device objects in that
cases. For this reason, it is necessary
On Wednesday, 2 of January 2008, Shaohua Li wrote:
ACPI defines a hardware signature. BIOS calculates the signature
according to hardware configure, if hardware changes, the signature will
change, in this case, S4 resume should fail.
The idea is fine, but I'd prefer to do that in a more
Le Sat, 29 Dec 2007 10:40:20 -0800,
Lee Howard [EMAIL PROTECTED] a écrit :
# cat /proc/interrupts
CPU0
0: 1051464247 IO-APIC-edge timer
1: 8 IO-APIC-edge i8042
8: 0 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12:
On Wednesday, 2 of January 2008, Erik Andrén wrote:
Hi,
2008/1/2, Shaohua Li [EMAIL PROTECTED]:
ACPI defines a hardware signature. BIOS calculates the signature
according to hardware configure, if hardware changes, the signature will
change, in this case, S4 resume should fail.
On Jan 2, 2008 2:15 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
A stupid question. The old RTC driver is in
drivers/char/rtc.c, and maps to:
crw-r--r-- 1 root root 10, 135 Oct 25 18:02 /dev/rtc
the new driver is in drivers/rtc/*, and maps to:
crw-r--r-- 1 root root 254, 0 Dec 12 02:30
* Kay Sievers [EMAIL PROTECTED] wrote:
shouldnt we provide a Kconfig way of replacing dev 10:135 with the
new driver's 254:0 device? (while keeping all the current modes of
operation as well, of course.) It's all supposed to be 100% ioctl
ABI compatible with the old driver, right?
On Wed 2008-01-02 10:03:59, Yi Yang wrote:
On Wed, 2008-01-02 at 00:20 +0100, Pavel Machek wrote:
Hi!
/proc/acpi/wakeup is also case-sensitive, case-insensitive is better.
Why?
A user uses device bus id like 'C093' to enable or disable wakeup of the
device, for example
echo C093
Andrey Borzenkov wrote:
On Wednesday 02 January 2008, Alexey Starikovskiy wrote:
Andrey Borzenkov wrote:
This is did not happen before; I am not sure right now what caused this
(i.e.
battery aging or some software change) nor whether this is
kernel/HAL/kpowersave
On Wed, 2 Jan 2008, Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
It sometimes is necessary to destroy a device object during a suspend or
hibernation, but the PM core is supposed to control all device
On Wednesday, 2 of January 2008, Alan Stern wrote:
On Wed, 2 Jan 2008, Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
It sometimes is necessary to destroy a device object during a suspend or
(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Well, we have the following test script in the userland suspend
package that is supposed to work right now:
#!/bin/bash
date
cd /sys/class/rtc/rtc0
echo $(( $(cat since_epoch)
shouldnt we provide a Kconfig way of replacing dev 10:135 with the
new driver's 254:0 device? (while keeping all the current modes of
operation as well, of course.) It's all supposed to be 100% ioctl
ABI compatible with the old driver, right?
It's not compatible enough to fake
On Wed, 02 Jan 2008 09:54:00 -0800
David Bro
It'd need to have some NTP sync solution for RTC_LIB devices, but
ISTR the gentime stuff still assumes an update_persistent_clock()
that doesn't sleep ... and hence can't be used with I2C based RTCs.
I still believe NTP sync stuff should be done
It'd need to have some NTP sync solution for RTC_LIB devices, but
ISTR the gentime stuff still assumes an update_persistent_clock()
that doesn't sleep ... and hence can't be used with I2C based RTCs.
I still believe NTP sync stuff should be done outside of the kernel.
given the mean
On Tuesday 25 December 2007 02:31:26 pm Jean Delvare wrote:
Le 23/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit:
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
The problem is that the it87 driver is used on a variety of motherboards,
some where the hardware monitoring device
On Wed, 02 Jan 2008 10:12:54 -0800
David Brownell [EMAIL PROTECTED] wrote:
It'd need to have some NTP sync solution for RTC_LIB devices, but
ISTR the gentime stuff still assumes an update_persistent_clock()
that doesn't sleep ... and hence can't be used with I2C based RTCs.
I still
* David Brownell [EMAIL PROTECTED] wrote:
I've been trying to make sure the x86 world could realistically switch
to the RTC framework used by other Linux platforms, hence e.g. the
util-unix-ng updates, but never assumed there would be no userspace
changes. After all, userspace was using
* David Brownell [EMAIL PROTECTED] wrote:
shouldnt we provide a Kconfig way of replacing dev 10:135 with the
new driver's 254:0 device? (while keeping all the current modes of
operation as well, of course.)
The major number 254 is not statically allocated, ISTR; that should be
On Wednesday 02 January 2008, Ingo Molnar wrote:
then please provide a kernel config option for the new driver to take
over 10:135 too. There's nothing worse to the adoption of new kernel
features necessiating user-space attention. I've got several images of
old distros that i dont want
Hi.
Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Erik Andrén wrote:
Hi,
2008/1/2, Shaohua Li [EMAIL PROTECTED]:
ACPI defines a hardware signature. BIOS calculates the signature
according to hardware configure, if hardware changes, the signature will
change, in this case, S4
On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
Hi.
Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Shaohua Li wrote:
ACPI defines a hardware signature. BIOS calculates the signature
according to hardware configure, if hardware changes, the signature will
change, in
On Wednesday, 2 of January 2008, Nigel Cunningham wrote:
Hi.
Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Erik Andrén wrote:
Hi,
2008/1/2, Shaohua Li [EMAIL PROTECTED]:
ACPI defines a hardware signature. BIOS calculates the signature
according to hardware configure, if
Arjan van de Ven wrote:
On Fri, 30 Nov 2007 22:31:17 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Arjan van de Ven wrote:
On Fri, 30 Nov 2007 22:14:08 -0500
Mark Lord [EMAIL PROTECTED] wrote:
in -mm there is.. the QoS stuff allows you to set maximum
tolerable
..
That's encouraging, I think,
(I'm still looking into this matter...)
Shaohua Li wrote:
In IOAPIC mode, interrupt priority isn't related with the pin (in your
case, irq 16 or 19), but the vector of the pin.
Just to help my understanding a bit... does the Linux ACPI driver
determine which IRQ numbers are given to certain
Shaohua Li wrote:
Currently vector is allocated when pci_enable_device is called. So which
vector is allocated depends on how many drivers already called the
routine. The first vector is 0x31, later higher priority (higher) vector
will be allocated. In latest kernel, a vector of a irq could be
-Original Message-
From: Mark Lord [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 02, 2008 3:42 PM
To: Arjan van de Ven
Cc: Pallipadi, Venkatesh; Andrew Morton; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Ingo Molnar; [EMAIL PROTECTED];
linux-acpi@vger.kernel.org
Subject: Re: +
On Wed, 2 Jan 2008 16:06:20 -0800 Pallipadi, Venkatesh [EMAIL PROTECTED]
wrote:
-Original Message-
From: Mark Lord [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 02, 2008 3:42 PM
To: Arjan van de Ven
Cc: Pallipadi, Venkatesh; Andrew Morton; [EMAIL PROTECTED];
[EMAIL
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 02, 2008 4:52 PM
To: Pallipadi, Venkatesh
Cc: Mark Lord; Arjan van de Ven; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Ingo Molnar; [EMAIL PROTECTED];
linux-acpi@vger.kernel.org
Subject: Re: +
On Wed, 2008-01-02 at 17:29 +0800, Johannes Berg wrote:
Once reading the ACPI spec I noticed that ACPI supports this feature
so it is qute nice to implement it, since this will prevent resume from
disk what hardware was changed.
But.. how many bioses are broken regarding this
On Wed, 2008-01-02 at 17:09 +0100, Pavel Machek wrote:
On Wed 2008-01-02 10:03:59, Yi Yang wrote:
On Wed, 2008-01-02 at 00:20 +0100, Pavel Machek wrote:
Hi!
/proc/acpi/wakeup is also case-sensitive, case-insensitive is better.
Why?
A user uses device bus id like 'C093' to
Pallipadi, Venkatesh wrote:
-Original Message-
From: Mark Lord [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 02, 2008 3:42 PM
To: Arjan van de Ven
Cc: Pallipadi, Venkatesh; Andrew Morton; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Ingo Molnar; [EMAIL PROTECTED];
Pallipadi, Venkatesh wrote:
-Original Message-
From: Andrew Morton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 02, 2008 4:52 PM
To: Pallipadi, Venkatesh
Cc: Mark Lord; Arjan van de Ven; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Ingo Molnar; [EMAIL PROTECTED];
On Wed, 2008-01-02 at 22:05 +0800, Rafael J. Wysocki wrote:
On Wednesday, 2 of January 2008, Shaohua Li wrote:
ACPI defines a hardware signature. BIOS calculates the signature
according to hardware configure, if hardware changes, the signature
will
change, in this case, S4 resume should
40 matches
Mail list logo
