On Thursday 31 May 2007 00:17, Andrew Morton wrote:
initcall 0x8066281b: rtc_init+0x0/0x1aa() returned 0.
initcall 0x8066281b ran for 0 msecs: rtc_init+0x0/0x1aa()
Calling initcall 0x806629c5: hpet_init+0x0/0x69()
hpet_resources: 0xfed0 is busy
ACPI Error
Please open bug at bugzilla.kernel.org and attach acpidump output.
Thanks,
Alex.
John Floyd пишет:
Hi,
Have a specialised weatherproof laptop with a smartbattery running FC6
latest kernel. I cannot get battey monitoring going. Have loaded
modules i2c_ec and sbs with out any errors.
Hi,
Have a specialised weatherproof laptop with a smartbattery running FC6
latest kernel. I cannot get battey monitoring going. Have loaded
modules i2c_ec and sbs with out any errors.
log/messages indicate that the EC driver loads with
ACPI: EC HC smbus [SMB1]
There is nothing from the sbs
On Wed, May 30, 2007 at 03:25:05PM -0400, Len Brown wrote:
Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
where this code comes from...
When we change syntax in ACPICA files in Linux to make it more
On Wed, 2007-05-30 at 21:53 -0300, Henrique de Moraes Holschuh wrote:
Maybe we can add that requirement and driver changes (if any, for all
I know most drivers might already be generating such events) for
2.6.23? I bet Richard would like that one a lot. Richard?
To be honest, I've got lost
On Thu, 31 May 2007, Richard Hughes wrote:
On Wed, 2007-05-30 at 21:53 -0300, Henrique de Moraes Holschuh wrote:
Maybe we can add that requirement and driver changes (if any, for all
I know most drivers might already be generating such events) for
2.6.23? I bet Richard would like that one
On Thu, 2007-05-31 at 13:53 +0100, Bastien Nocera wrote:
On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
Attached patch adds a kernel thread to do polling on Toshiba hardware.
Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically
On Thu, 2007-05-31 at 13:36 +0100, Richard Hughes wrote:
Attached patch adds a kernel thread to do polling on Toshiba hardware.
Toshiba hardware is a little oddball, and does not provide ACPI events
on some key presses, typically Fn hotkey buttons. The key interface is
now polled, and events
On 5/31/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Thu, 31 May 2007, Richard Hughes wrote:
I am on it on the thinkpad-acpi side, so at least for that, you don't have
to worry. I am still waiting an answer about which event is the correct one
to output scancodes, but the
Hi,
we only make use of a small subset of current ACPI tables.
ACPI spreads more and more over different parts of the kernel and it's
likely that this will hold on.
ACPI_DEBUG=y is a powerful debug facility, that can ease up bug
communication with less (ACPI) experienced bug submitters and can
On Thu, 2007-05-31 at 14:44 +0100, Richard Hughes wrote:
Nope, impossible AFAICS. The hardware is just broken. Windows XP has an
toshiba supplied daemon that polls, so I think we have to just bite the
bullet.
... adding in reply in different thread...
On Thu, 2007-05-31 at 10:37 -0400, Dmitry
Hi,
On Thu, May 31, 2007 at 04:46:56PM +0100, Richard Hughes wrote:
+ if (!hotkeys_over_input) {
+ if (!key_event_valid) {
+ hci_read1(HCI_SYSTEM_EVENT, value, hci_result);
+ if (hci_result == HCI_SUCCESS) {
+
The name of this patch is really split ACPI function tracing
out of CONFIG_ACPI_DEBUG to a new Kconfig build option
I agree that tracing should be its own build option.
I don't agree that enabling CONFIG_ACPI_DEBUG by default
is what you want to do in a production kernel, but that
isn't what
Applied.
thanks,
-Len
On Wednesday 30 May 2007 19:50, Henrique de Moraes Holschuh wrote:
The initial version of the thinkpad-acpi sysfs interface (not yet released
in any stable mainline kernel) made liberal use of named sysfs groups, in
order to get the attributes more organized.
This
Applied.
thanks,
-Len
On Thursday 24 May 2007 16:57, Luck, Tony wrote:
Last of the Section mismatch errors from ia64 builds! acpi_map_pxm_to_node()
is defined with attribute __cpuinit, but is called by normal kernel
functions
acpi_getnode() and acpi_map_cpu2node().
Commit
On Wednesday 30 May 2007 20:53, Henrique de Moraes Holschuh wrote:
On Wed, 30 May 2007, Dmitry Torokhov wrote:
On 5/30/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
It is trivial to guarantee that KEY_PROG is unique for a single input
device (keyboard), but it certainly won't
On 5/31/07, Thomas Renninger [EMAIL PROTECTED] wrote:
(This should efficiently be the same as the proposed big patch a year
ago from Pekka Enberg, just a bit smaller and should make ACPICA and
kernel/linux people happy:
http://marc.info/?l=linux-kernelm=113699535303722w=2)
No, you're keeping
On Thursday 31 May 2007 14:57, Pekka Enberg wrote:
On 5/31/07, Thomas Renninger [EMAIL PROTECTED] wrote:
(This should efficiently be the same as the proposed big patch a year
ago from Pekka Enberg, just a bit smaller and should make ACPICA and
kernel/linux people happy:
We have all the pieces needed to have sane, generic userland keyboard handling
in place for a while now, but it was not sufficiently documented (or used!).
If EV_KEY input drivers always generate scan codes that can be used to
reprogram their keycode maps, and always generate EV_MSC MSC_SCAN
-Original Message-
From: Len Brown [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 11:02 PM
To: Andrew Morton; Pallipadi, Venkatesh
Cc: linux-acpi@vger.kernel.org
Subject: Re: acpi exception with current -mm lineup (HPET)
I put a copy of /proc/acpi/dsdt at
On Thu, 2007-05-31 at 18:46 +0200, Andreas Mohr wrote:
HCI_EMPTY is *by far* the most frequent state to occur I think
(users won't press keys all the time), thus it's probably better(?)
for branch prediction to have this placed first, right?
Not that it matters too much instruction-wise, but
I got this messages warnings, I just found it, after had other problems
not related with ACPI, I am been running with this kernels one or two
months ago, and I don't had problems, just reporting the situation,
could be useful anyway.
Thanks,
ACPI Warning (tbfadt-0360): Ignoring BIOS FADT r2
On Thu, May 31, 2007 at 09:13:04PM -0300, Henrique de Moraes Holschuh wrote:
Well, we already produce KEY_UNKNOWN anyway, and the stuff you quoted above
just makes KEY_UNKNOWN useful for something instead of keeping it as an
useless notice to the user that some key (which one? who knows!) was
Applied this series to acpi-test
in anticipation that Venki is about to send some incremental
patches to address the feedback on it.
thanks,
-Len
On Saturday 24 March 2007 03:46, Adam Belay wrote:
Hi All,
Here is my first take at implementing an idle PM governor that takes
full advantage of
Please open a sighting at bugzilla.kernel.org against ACPI/tables
and attach the output from acpidump
thanks,
-Len
On Thursday 31 May 2007 20:11, Sergio Monteiro Basto wrote:
I got this messages warnings, I just found it, after had other problems
not related with ACPI, I am been running with
On Fri, 01 Jun 2007, Matthew Garrett wrote:
On Thu, May 31, 2007 at 09:13:04PM -0300, Henrique de Moraes Holschuh wrote:
Well, we already produce KEY_UNKNOWN anyway, and the stuff you quoted above
just makes KEY_UNKNOWN useful for something instead of keeping it as an
useless notice to the
On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 01 Jun 2007, Matthew Garrett wrote:
Given existing userspace, it's never useful to generate KEY_UNKNOWN.
Adding extra information to the event doesn't alter that.
It will not break anything, and it is
On Fri, 01 Jun 2007, Matthew Garrett wrote:
On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 01 Jun 2007, Matthew Garrett wrote:
Given existing userspace, it's never useful to generate KEY_UNKNOWN.
Adding extra information to the event doesn't alter
Hook acpi D-state method to pnp suspend/resume, so we have a chance to poweroff
the device.
Signed-off-by: Shaohua Li [EMAIL PROTECTED]
Index: 2.6.22-rc2/include/linux/pnp.h
===
--- 2.6.22-rc2.orig/include/linux/pnp.h 2007-05-23
On Monday 21 May 2007 08:11, Pavel Machek wrote:
On Thu 2007-05-17 18:42:43, Len Brown wrote:
Something similar happened to me on XE3, yes.
(Actual values were different; BIOS specified critical temperature at
cca 95C, but hw killed the power at cca 83C. Setting critical trip
Len Brown wrote:
Then the button driver should take the lid event and
cause the code in the video driver to be invoked.
I'm not sure what the best method for inter-driver
event like this, since both of them can be modules.
I have taken a stab at this approach and it is working nicely. I'm
Many Dell laptops have the DSDT coded to power down the display when the lid
is closed, and leave it off when it is opened.
http://bugzilla.kernel.org/show_bug.cgi?id=5155
Based on ideas from Len Brown, this patch creates an internal event so
that the button driver can notify the video driver
This patch creates a new event system for communication between in-kernel
ACPI drivers (ievent). It is simple - it should only be used to infrequently
pass simple messages to a small audience.
This is used in an upcoming patch which makes the ACPI video driver listen for
lid open events from the
Dell laptops seem to address video devices without the device_id_scheme bit,
which means that Linux doesn't know the device types of the video devices.
This patch makes the ACPI video driver guess the device type based on the
device name for devices which do not have the device_id_scheme set.
On Thursday 31 May 2007 21:44, Matthew Garrett wrote:
On Thu, May 31, 2007 at 10:29:28PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 01 Jun 2007, Matthew Garrett wrote:
Given existing userspace, it's never useful to generate KEY_UNKNOWN.
Adding extra information to the event
On Friday 01 June 2007 00:08, Matthew Garrett wrote:
On Thu, May 31, 2007 at 11:33:10PM -0400, Dmitry Torokhov wrote:
On Thursday 31 May 2007 21:44, Matthew Garrett wrote:
It's not trivial at all. You need to introduce a mechanism for noting a
KEY_UNKNOWN keypress. It then needs to
36 matches
Mail list logo
