Len Brown wrote:
..same problem with 2.6.20-rc3. Last worked with
2.6.19-rc6-git12, so it was 2.6.19 where it failed.
Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet
doesn't get configured, route -n says it's an Unsupported operation,
ifconfig only shows for
Around about 04/01/07 19:15, Mattia Dongili typed ...
I have the hw and I'd be happy to do some basic working on the code
OK, I'm going to jump in here with something I've been meaning to post
for a while; now seems as good a time as any :)
I *think* I'm using the code you're all
Le jeudi 04 janvier 2007 à 20:16 -0800, Andrew Morton a écrit :
On Fri, 05 Jan 2007 00:54:32 +0100
Stelian Pop [EMAIL PROTECTED] wrote:
Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit :
On Fri, 05 Jan 2007 00:36:23 +0100
Stelian Pop [EMAIL PROTECTED] wrote:
Added
Le vendredi 05 janvier 2007 à 01:11 +0100, Jan Engelhardt a écrit :
On Jan 5 2007 00:36, Stelian Pop wrote:
@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
+static struct acpi_device
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit :
What needs to happen is
1. a maintainer for sony_acpi.c needs to step forward
I can't do this, I'm not allowed to be in the reverse engineering
business.
Well, I can't do this either, because I just don't have
On Mon, 2006-12-04 at 14:49 -0800, [EMAIL PROTECTED] wrote:
From: Akinobu Mita [EMAIL PROTECTED]
Make loading processor.ko fail when an error happens.
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
On Thu, 2006-12-21 at 22:40 +, Peter Clifton wrote:
On Thu, 2006-12-21 at 16:44 -0500, Lincoln Baxter, III wrote:
[snip]
Can someone point me to the code that determines the voltage / amperage
pairings for CPUs in power saving mode? Is this handled by the ACPI bios
(bios function
On Fri, Jan 05, 2007 at 11:02:03AM +0100, Stelian Pop wrote:
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit :
What needs to happen is
1. a maintainer for sony_acpi.c needs to step forward
I can't do this, I'm not allowed to be in the reverse engineering
On Fri, Jan 05, 2007 at 12:33:20PM -0500, Len Brown wrote:
[...]
With /proc/acpi/ going away, this raises the question of where sony_acpi
should put stuff
that is under development -- as unlike brightness -- it will not have a
generic home in sysfs.
I was thinking the same and had 2 options
Well, HAL has used it for changing the brightness for the last year or
so: /proc/acpi/sony/brightness
Although if you use a new enough HAL (CVS), the laptop will be supported
via the shiny new backlight class.
great, -mm already has the /sys/class/backlight in place for sony_acpi
On Thursday 04 January 2007 21:20, MoRpHeUz wrote:
Hi,
I own a Sony Vaio VGN-SZ340 and I had problems regarding acpi + it's
dual core processor. The guys from Intel gave me a workaround and now
it recognises both cores.
What workaround are you using?
The problem is that it does not do
What workaround are you using?
This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
The frequency scaling issue sounds like a BIOS/Linux incompatibility.
Please open a bugzilla, if you haven't already, and include the
output from acpidump.
I agree that it sound like a BIOS/Linux
On Fri, Jan 05, 2007 at 12:02:30PM -0500, Len Brown wrote:
Well, HAL has used it for changing the brightness for the last year or
so: /proc/acpi/sony/brightness
Although if you use a new enough HAL (CVS), the laptop will be supported
via the shiny new backlight class.
great,
On Friday 05 January 2007 12:24, MoRpHeUz wrote:
What workaround are you using?
This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
Ah yes, the duplicate MADT issue is clearly a BIOS bug.
It is possible that we can tweak our Linux workaround for it to be more
Microsoft Windows Bug
On Friday 05 January 2007 11:10, Len Brown wrote:
On Friday 05 January 2007 12:24, MoRpHeUz wrote:
What workaround are you using?
This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
Ah yes, the duplicate MADT issue is clearly a BIOS bug.
It is possible that we can tweak our
I`m having a lot of ACPI BATTERY related problems ...
A lot of
Jan 6 00:43:49 localhost kernel: ACPI Error (psargs-0355): [PBST]
Namespace lookup failure, AE_NOT_FOUND
Jan 6 00:43:49 localhost kernel: ACPI Error (psparse-0537): Method
parse/execution failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node
applied to sysfs branch.
thanks,
-Len
On Thursday 04 January 2007 02:03, Zhang Rui wrote:
From: Zhang Rui [EMAIL PROTECTED]
Some of the ACPI devices use the internal fake hids which are exposed to
userspace as devces' bus_id after sysfs conversion.
To make it more friendly, we convert
I`m having a lot of ACPI BATTERY related problems ...
Please look into the bug #7386 and try 'acpi_serialize' flag.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Salatiel Filho
Sent: Saturday, January 06, 2007 7:13 AM
To: linux-acpi@vger.kernel.org
18 matches
Mail list logo
