Michael S. Tsirkin wrote:
On Mon, Feb 25, 2008 at 10:50 PM, Alexey Starikovskiy
<[EMAIL PROTECTED]> wrote:
Michael S. Tsirkin wrote:
> Did you guys stop accepting reports by mail?
> I hope not.
It is easier to track bug information in bugzilla.
If you for some reason do not wish
Michael S. Tsirkin wrote:
Did you guys stop accepting reports by mail?
I hope not.
It is easier to track bug information in bugzilla.
If you for some reason do not wish to create a bug report,
I can do it for you. You only need to provide acpidump.
and attach acpidump?
I'll see if I can get
Michael S. Tsirkin wrote:
On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
such as Fn-F4 and lid open/close, prints them in /var/log/acpid
and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
This no longer happens in 2.6.25-rc3: I see nothing in /var/log/acpid
Please open bug report at bugzilla.kernel.org against ACPI/battery.
Please attach dmesg and acpidump to that bug.
Please also attach actual /proc/acpi/battery/*/* files.
Thanks,
Alex.
Daniel Barkalow wrote:
I'm having problems with the battery reporting on my laptop. In
particular, the LEDs sug
S4BIOS is not supported, so there is no reason to expect
it as input and try to do something wrong.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/sleep/main.c |2 --
drivers/acpi/sleep/proc.c |5 -
2 files changed, 0 insertions(+), 7 deletions(-)
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote:
How about WMI?
Do you think that there will be some point in the future,
when we could claim that our WMI implementation is the
same as Windows + HW manufacturer private driver?
When vendors
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote:
It would be much better if we define feature-specific OSI() strings
that have well defined meanings for each place where Lenovo has to do
something different than What Happens With Windows --- especially for
Rafael J. Wysocki wrote:
On Wednesday, 20 of February 2008, Linus Torvalds wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
I think we should export the target sleep state somehow.
Yeah. By *not* using "->suspend()" for freezing or hibernate.
Please, Rafael - just make the
Hi Ron,
Throttling is meant as a last line of defense before powering-off
machine, and not a thermal regulation feature.
Please check if you have cpufreq compiled in and able to change frequency.
Please open a bug report at bugzilla.kernel.org against ACPI/Thermal.
Please attach dmesg output an
Len Brown wrote:
On Tuesday 12 February 2008 05:57, Jan-Simon Möller wrote:
Sorry for the late reply !
Am Samstag 19 Januar 2008 05:29:49 schrieb Len Brown:
On Saturday 13 October 2007 04:13, Jan-Simon Möller wrote:
System Information
Manufacturer: FUJITSU SIEMENS
same function. I could adjust any of two patches to not conflict with the other.
Regards,
Alex.
thanks,
-Len
On Tuesday 13 November 2007 05:05, Alexey Starikovskiy wrote:
Level GPE should not be enabled until all work caused by it is done,
e.g. all Notify() methods are completed.
This cou
Thomas Renninger wrote:
On Thu, 2008-01-31 at 14:17 -0500, Len Brown wrote:
[skipped]
Those tables have the same OEM id then the original ones, right?
Tables with the same OEM id (the original ones) should get ignored later
automatically. IIRC I had some problems with dynamically loaded table
xuqiang wrote:
Alexey Starikovskiy,??!
ok, I will get all needed information. But can you tell me what [\_SB_.RPME] [\_SB_.RDPE] and [\_GPE._L18] mean?
_L18 is ACPI level-triggered event #18. _GPE._L18 is a BIOS provided (in
DSDT table) handler for this event.
It calls some other
Hi Likes,
What kernel are you using?
Please open bug in bugzilla.kernel.org for ACPI and provide all needed
information, including dmesg (from the beginning) and acpidump.
xuqiang wrote:
hi,all:
an error happened. in an hour, more than 30 million lines were repeated and
writed to /var/log
Sjoerd Simons wrote:
On Wed, Jan 23, 2008 at 02:01:34PM +0300, Alexey Starikovskiy wrote:
maximilian attems wrote:
got the following question:
~/src/hal$ egrep 'voltage_(max|min)_design' -r .
./hald/linux/device.c: if (hal_util_get_int_from_file (path, "voltage_max_design&quo
maximilian attems wrote:
got the following question:
~/src/hal$ egrep 'voltage_(max|min)_design' -r .
./hald/linux/device.c: if (hal_util_get_int_from_file (path, "voltage_max_design",
&voltage_design, 10)) {
any particular reason the kernel is calling it
cat /sys/class/power_supply/BAT0/volta
maximilian attems wrote:
On Tue, Jan 22, 2008 at 09:00:09PM +0300, Alexey Starikovskiy wrote:
ACK
thanks for your quick response!
while checking the missing bits of ACPI_SYSFS_POWER versus
ACPI_PROCFS_POWER i also noticed capacity granularity.
is that used by anyone?
IMHO, nobody cares
ACK
maximilian attems wrote:
egrep serial /proc/acpi/battery/BAT0/info
serial number: 32090
serial number can tell you from the imminent danger
of beeing set on fire.
Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c |5 +
drivers/pow
Does revert of 93ad7c07ad487b036add8760dabcc35666a550ef helps?
Rafael J. Wysocki wrote:
On Tuesday, 22 of January 2008, Rafael J. Wysocki wrote:
Hi,
It turns out that the following script (from openSUSE 10.3):
#
# triggers the ACPI
Zhao Yakui wrote:
On Mon, 2008-01-21 at 13:00 +0300, Alexey Starikovskiy wrote:
Thanks for the response.
Hi Zhao,
All patches have relevant bugzilla entries, so you could read them for full
understanding.
Summary:
acpi_ec_probe/boot_ec_enable are workarounds for same situation then
EC driver
Hi Zhao,
All patches have relevant bugzilla entries, so you could read them for full
understanding.
Summary:
acpi_ec_probe/boot_ec_enable are workarounds for same situation then
EC driver should be inited early, but ECDT was not provided. Half of this
workaround was enabled earlier with fake ECDT
Burst mode temporary (50 ms) locks EC to do only transactions with
driver, without it some hardware returns abstract garbage.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c |4
1 files chan
Specification allows only byte access for EC region, so
make it separate from bug-compatible multy-byte access.
Also do not allow return of garbage in supplied *value.
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
d
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
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 wrote:
On Wednesday, 26 of December 2007, Linus Torvalds wrote:
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
2.0 and later wants us to put devices into low power states before calling
_PTS, ACPI
Carlos Corbacho wrote:
On Monday 17 December 2007 09:40:19 Alexey Starikovskiy wrote:
+/*
+ * WMI can have EmbeddedControl access regions. In which case, we just
want to + * hand these off to the EC driver.
+ */
+static acpi_status
+acpi_wmi_ec_space_handler(u32 function
hout a WCxx method.
* Minor cleanups
v11 (2007-12-17)
* More fixing for broken GUIDs declared expensive without a WCxx method.
* Add basic EmbeddedControl region handling.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
CC: Len Brown <[EMAIL PROTECTED]>
CC: Matthew Garr
Jan Willies wrote:
Rafael J. Wysocki wrote:
On Sunday, 16 of December 2007, Jan Willies wrote:
Rafael J. Wysocki wrote:
On Saturday, 15 of December 2007, Jan Willies wrote:
Len Brown wrote:
On Friday 14 December 2007 12:42, Jan Willies wrote:
Carlos Corbacho wrote:
Alexey,
Is the code in EC0 interfering then with the EC access code in AMW0? (See
lines 962 onwards for the AMW0 EmbeddedControl region bits)?
Because AFAICT, the EC0 code is fine (my 5020 has the same AML for EC0 and
doesn't have any problem, and the user didn't repor
_STA for EC is not needed -- might be worth trying to remove it
AnyAcc is not right -- should be ByteAcc.
OperationRegion EC01, EC02 also seem to be good recipe for trouble...
Carlos Corbacho wrote:
On Wednesday 28 November 2007 18:08:44 Moore, Robert wrote:
This will probably require a t
Borislav Petkov wrote:
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
From what i can roughly tell so far it seems like an resource conflict between
acpi and
the pnp requested regions in your patch which res
Thomas Renninger wrote:
On Tue, 2007-11-13 at 19:03 +, Carlos Corbacho wrote:
Alexey,
How about character /dev/ec0?
Yes, that would be fine.
On Tuesday 13 November 2007 18:54:51 Alexey Starikovskiy wrote:
What is the benefit of having acer_acpi in userspace, rather
l.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Romano Giannetti <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c | 46 +
drivers/acpi/processor_core.c |5
2 files changed, 37 insertions
Sometimes it is usefull to see raw protocol dump.
Uncomment '#define DEBUG' at the beginning of file to make EC
really verbose.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
dr
l.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Romano Giannetti <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c | 46 +-
1 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/ec
Sometimes it is usefull to see raw protocol dump.
Uncomment '#define DEBUG' at the beginning of file to make EC
really verbose.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
dr
l.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Romano Giannetti <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c | 46 +-
1 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/ec
Sometimes it is usefull to see raw protocol dump.
Uncomment '#define DEBUG' at the beginning of file to make EC
really verbose.
Signed-off-by: Márton Németh <[EMAIL PROTECTED]>
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
dr
Zhang Rui wrote:
On Mon, 2007-11-19 at 15:32 +0800, Zhang Rui wrote:
From: Zhang Rui <[EMAIL PROTECTED]>
The current code only disable the GPE by judging the
GPE type, which is one of WAKE, RUNTIME and WAKE_RUN.
In bug 6217, GPE 17 is enabled by the AML code ...
And it will be triggerred whe
Henrique de Moraes Holschuh wrote:
On Mon, 19 Nov 2007, Alexey Starikovskiy wrote:
Henrique de Moraes Holschuh wrote:
On Thu, 08 Nov 2007, Alexey Starikovskiy wrote:
handle explicitly. There doesn't seem to be any status enum value
defined that makes more sense than 'unknown'
Introduce new ACPI_PROCFS_POWER (default Yes) config option and move
procfs code in battery, ac, and sbs drivers under it.
This is done to allow ACPI_PROCFS to be default No.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/Kconfig | 16 +++-
d
Henrique de Moraes Holschuh wrote:
On Thu, 08 Nov 2007, Alexey Starikovskiy wrote:
handle explicitly. There doesn't seem to be any status enum value
defined that makes more sense than 'unknown' for a battery at a
critical charge level.
Maybe one should be added
Rolf Eike Beer wrote:
Alexey Starikovskiy wrote:
Rolf Eike Beer wrote:
cat
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_
supply/BAT1/status
This leads to a stacktrace as acpi_battery_get_property() returns 0 for a
case where it does not set val->int
Rolf Eike Beer wrote:
cat
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:19/PNP0C0A:00/power_supply/BAT1/status
This leads to a stacktrace as acpi_battery_get_property() returns 0 for a
case where it does not set val->intval. These value is used as an array
index in drivers/power/power
l.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Romano Giannetti <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c | 35 ++-
1 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/e
() already does.
* put braces around unregister call, as it depends on dev being not NULL.
* remove unneeded braces
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/sbs.c | 25 +
1 files
l.org/show_bug.cgi?id=9327
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c | 35 ++-
1 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 56afe13..d6ddb54 100644
--- a/drivers/acpi
http://bugzilla.kernel.org/show_bug.cgi?id=9262
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=8598
Reference: https://bugzilla.novell.com/show_bug.cgi?id=334806
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c |8
1 files changed, 8 inser
Do you ACPI_PROC_EVENTS set in your config?
Frank Munsche wrote:
Hello,
I've got a Sony Vaio SZ61 running gentoo, 2.6.22-gentoo-r9 . Although there is
acpi - information available in /proc/acpi (e.g. battery, ac_adapter,
processor) I never get apci - events reported.
If I pull the ac - cable
Rafael J. Wysocki wrote:
On Wednesday, 14 of November 2007, Alexey Starikovskiy wrote:
get_property() should not call battery_update(),
it also should call get_status() only if battery is present to
avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by
get_property() should not call battery_update(),
it also should call get_status() only if battery is present to
avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Acked-by: Johannes Weiner <[EMAIL PROTECTED]
Carlos Corbacho wrote:
Alexey,
2) I'm toying with the idea of re-implementing acer_acpi as a userspace
application (which also requires EC access for certain functions - I don't
mind poking /dev/ports for the odd bit of reverse engineering, but for any
other kind of normal usage access to the
Alexey Starikovskiy wrote:
Carlos Corbacho wrote:
Alexey,
I'm considering writing a sysfs interface for the EC registers, and
was wondering if you would be ok with such a patch (before I start
work on it)?
What do you need that for?
I'd like to expose the registers to userspace
Carlos Corbacho wrote:
Alexey,
I'm considering writing a sysfs interface for the EC registers, and was
wondering if you would be ok with such a patch (before I start work on it)?
What do you need that for?
I'd like to expose the registers to userspace, as it is already possible to
access th
Level GPE should not be enabled until all work caused by it is done,
e.g. all Notify() methods are completed.
This could be accomplished by appending enable_gpe function to the end
of notify queue.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/events/evgpe.c
get_property() should not call battery_update(),
it also should call get_status() only if battery is present to
avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Rolf Eike Beer <[EMAIL PROTECTED]>
Acked-by: Johannes Weiner <[EMAIL PROTECTED]
i, 09 Nov 2007 12:36:43 +0300 Alexey Starikovskiy <[EMAIL PROTECTED]>
wrote:
Andrew Morton wrote:
A> On Thu, 08 Nov 2007 19:35:23 +0300 Alexey Starikovskiy <[EMAIL PROTECTED]>
wrote:
[remove_cycle_at_battery_removal.patch text/x-patch (1.7KB)]
ACPI: Battery: remov
$
Use strncasecmp to compare model string to skip trailing part
Signed-off-by: Andrey Borzenkov <[EMAIL PROTECTED]>
Acked-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/driver
Andrey,
Fix already exists. It already went up to Len's tree.
Regards,
Alex.
Andrey Borzenkov wrote:
Alexey, this fixes my patch that went into -rc2. Sorry for Oops.
Subject: [PATCH] 2.6.24-rc2: do not unregister power_supply in sysfs ->show
method
From: Andrey Borzenkov <[EMAIL PROTECTED]>
Shaohua,
There is cond_resched() before the exit from deferred execution routine,
specifically to let notify thread a chance to execute.
Thus by the time deferred execution is exited, notify should be already
done,
and we could safely enable _Lxx again.
Do you think it is not sufficient?
Regard
Andrew Morton wrote:
A> On Thu, 08 Nov 2007 19:35:23 +0300 Alexey Starikovskiy <[EMAIL PROTECTED]>
wrote:
[remove_cycle_at_battery_removal.patch text/x-patch (1.7KB)]
ACPI: Battery: remove cycle from battery removal.
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
get_proper
der to not get stale data.
Regards,
Alex.
ACPI: Battery: remove cycle from battery removal.
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
get_property() should not call battery_update() on absent battery to
avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Rafael J. Wysocki wrote:
On Thursday, 8 of November 2007, Johannes Weiner wrote:
Hi,
is there any reason, why acpi_battery_get_property() should call
acpi_battery_update() at all?
Alex?
If someone wants to read stale values, he could comment out acpi_battery_update.
Regards,
Alex.
-
To unsu
Hi Romano,
EC was changed to automatically choose it's working mode (poll vs. interrupt
driven).
You see it oscillating between modes because it receives interrupts just after it
stops waiting for them.
Please open new bug entry at bugzilla.kernel.org.
Your .config might be usefull.
Thanks,
A
er <[EMAIL PROTECTED]>
Acked-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index c2ce0ad..cbb27b4 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -152,6 +152,8 @@ static int acpi_battery_get_pr
http://bugzilla.kernel.org/show_bug.cgi?id=9262
Reference: http://bugzilla.kernel.org/show_bug.cgi?id=8598
Reference: https://bugzilla.novell.com/show_bug.cgi?id=334806
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/ec.c |3 +++
1 files changed, 3 insertions(+),
do AC adapter register/unregister at on/off.
Acked-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
get_property() should not call battery_update() on absent battery to
avoid cycle and oops.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
Tested-by: Rolf Eike Beer <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c |8 +---
1 files changed, 5 insertions(+), 3 deleti
Rolf Eike Beer wrote:
Alexey Starikovskiy wrote:
Rolf Eike Beer wrote:
Alexey Starikovskiy wrote:
Rolf Eike Beer wrote:
Rolf Eike Beer wrote:
Hi,
this happened while I removed my battery on bootup. Complete dmesg is
attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was
Rolf Eike Beer wrote:
Alexey Starikovskiy wrote:
Rolf Eike Beer wrote:
Rolf Eike Beer wrote:
Hi,
this happened while I removed my battery on bootup. Complete dmesg is
attached. Kernel is 2.6.24-rc1-git of yesterday (last commit was
d919fd433b5823d1cf9d0688eb2eec183de9b74c).
Ok, I found out
d oops.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index c2ce0ad..50cdf6f 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/ac
Andrey Borzenkov wrote:
> On Wednesday 31 October 2007, Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> I suspect new ACPI AC adapter code but have to add some printk's to be
>>> sure.
>>>
>>> To reproduce - plug in AC cord, suspend, un
this patch helps.
Regards,
Alex.
ACPI: AC: Update AC state on sysfs read
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/ac.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drive
Andrey Borzenkov wrote:
> I suspect new ACPI AC adapter code but have to add some printk's to be sure.
>
> To reproduce - plug in AC cord, suspend, unplug, resume - kpowersave and
> sysfs
> still show AC adapter online. Or other way round.
>
> -andrey
The only change to drivers/acpi/ac.c after
Danny Baumann wrote:
> Hi,
>
>>> after upgrading to Fedora 8 which brought kernel 2.6.23 with it I can no
>>> longer
>>> use the brightness buttons (Fn+F6/F7) on my above mentioned laptop. Pressing
>>> them generates F6 and F7 key events instead of ACPI events. This used to
>>> work
>>> fine in
Some machines return integer instead of expected string.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c | 25 +++--
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
Ash Milsted wrote:
> I wonder how common this problem is. This laptop is quite old (Toshiba
> Satellite 1110), but if this is a common issue I guess it makes sense
I've seen only one bug report with similar issue -- DSDT required 10 false
_BST executions before returning actual value.
So, I'd say
John Rogers wrote:
> I'm running a dell latitude c400, and a fixed dsdt isn't available. My
> C skills are like my B-ball skills - non-existent.
You are lucky -- DSDT is not written in C :)
Why do you need it? E.g. what is broken and what do you hope to 'fix' by DSDT?
> -
> To unsubscribe from this
Ash Milsted wrote:
> On 27/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>> Ash Milsted wrote:
>>> Hi again,
>>> I just thought I'd say that this is still occuring with the current
>>> linux-acpi-2.6 git tree on top of Linus' latest..
Ash Milsted wrote:
>> No problem. One other thing - I just saw this is my dmesg...
>> Oct 28 13:41:49 tuktuk omnibook: Driver version 2.20070211-trunk.
>> Oct 28 13:41:49 tuktuk omnibook: Toshiba Satellite 1110 detected.
>> Oct 28 13:41:49 tuktuk omnibook: LCD backlight turn off at console
>> blank
Support Li-Ion as possible name for technology.
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]>
---
drivers/acpi/battery.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 6c06879..06b68de 100644
--- a/d
From: Andrey Borzenkov <[EMAIL PROTECTED]>
Make sure no power_supply object is present unless we actualy detect
presence of battery. This fixes ghost batteries detected by HAL
Signed-off-by: Andrey Borzenkov <[EMAIL PROTECTED]>
Signed-off-by: Alexey Starikovskiy <[EMAIL PROTECTED]
Bart wrote:
> Hi,
>
> Currently I'm having two acpi problems on linux.
>
> 1. My temperature is reported as -47°C (THRM/temperature).
> 2. And sometimes the pc is automatically shutdown due to a critical
> temperature event (not often).
First, check if you use lm_sensors.
They work with the same
Andrey Borzenkov wrote:
> On Saturday 27 October 2007, Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> I am not exactly sure about this one ... what other power_supply class
>>> drivers do? Should I fix HAL instead (but then, I do not know whether HAL
>>
Ash Milsted wrote:
> Hi again,
> I just thought I'd say that this is still occuring with the current
> linux-acpi-2.6 git tree on top of Linus' latest.. I don't get
> (dis)charge uevents and, oddly, the sysfs charge_now value is
As I remember, you did not found uevents in 2.6.23 as well?
> initiall
Andrey Borzenkov wrote:
> I am not exactly sure about this one ... what other power_supply class
> drivers
> do? Should I fix HAL instead (but then, I do not know whether HAL is the only
> application that is using this interface).
>
>
Hm, do you need separate set of properties for that? You c
Andrey Borzenkov wrote:
> On Saturday 27 October 2007, Alexey Starikovskiy wrote:
>> As you wish... :) Please check the attached patch.
>>
>
> Not sure why you need to reimplement acpi_extract_package, but ...
Take a look on memory allocations around it... :)
>
>
Andrey Borzenkov wrote:
> On Saturday 27 October 2007, Alexey Starikovskiy wrote:
>> Andrey,
>> Please try the attached patch. I choose to do snprintf() instead of direct
>> copy, as your previous message showed empty OEM type.
>>
>
> Not quite. Now I get
>
&g
Andrey,
Please try the attached patch. I choose to do snprintf() instead of direct copy,
as your previous message showed empty OEM type.
Thanks,
Alex.
Andrey Borzenkov wrote:
> On Friday 26 October 2007, Alexey Starikovskiy wrote:
>> Your cat's "Bad address" means -EFAULT,
Frans Pop wrote:
> Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> is it in -rc1 or can you point me to the patch (I'd rather avoid having
>>> to pull from different git trees). Thank you.
>> No, it should be rc1.
>>> And what about ACPI_
Andrey Borzenkov wrote:
> On Friday 26 October 2007, Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> On Friday 26 October 2007, Alexey Starikovskiy wrote:
>>>> Andrey Borzenkov wrote:
>>>>> I have lost battery in 2.6.24-rc1. Without CONFIG_A
Andrey Borzenkov wrote:
> On Friday 26 October 2007, Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> I have lost battery in 2.6.24-rc1. Without CONFIG_ACPI_PROCFS I have
>>> no /proc/acpi/battery and cannot test netlink interface because right now
>>>
cpi/debug_layer (/sys/module/acpi/parameters/debug_layer)
> /proc/acpi/debug_level (/sys/module/acpi/parameters/debug_level)
>
> neither does it mention /proc/acpi/battery not do I actually have any battery
> information in /sys.
>
> Personally I do not like it (if it is in
Len Brown wrote:
> and going away), and the DSDT databse -- which I believe
> is also somewhat of a historical artifact.
DSDT database or better acpidump.out database might be very useful,
if could be searched for particular feature -- absence of EC, use of SBS, etc.
Alex.
-
To unsubscribe from th
Ash Milsted wrote:
> On 25/10/2007, Ash Milsted <[EMAIL PROTECTED]> wrote:
>> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>>> Ash Milsted wrote:
>>>> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>>>>>
Ash Milsted wrote:
> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>> Ash Milsted wrote:
>>> On 24/10/2007, Ash Milsted <[EMAIL PROTECTED]> wrote:
>>>> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>>>>&g
Ash Milsted wrote:
> On 24/10/2007, Ash Milsted <[EMAIL PROTECTED]> wrote:
>> On 24/10/2007, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>>> Could you please test this patch?
>> Appears to work again - sysfs values now seem to update correctly
>>
t; the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
ACPI: battery: run acpi_battery_update from sysfs read
From: Alexey Starikovskiy <[EMAIL PROTECTED]>
Update battery information at sysfs read.
Signed-off-by: Alexey Starikovskiy &l
Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 09:15:18PM +0400, Alexey Starikovskiy wrote:
>> Adrian,
>>
>> commit 30c08574da0ead1a47797ce028218ce5b2de61c7 can not introduce
>> use-after-free.
>>
>> Please check...
>
>
> Commit 30c08574da0e
1 - 100 of 399 matches
Mail list logo
