>On 2/20/06, Yu, Luming <[EMAIL PROTECTED]> wrote:
>> I found _BCM, _BCL ... which are reserved methods for
>> ACPI video extension device. If the vendor follows
>> ACPI video extension spec, this proposed driver is
>> NOT needed. Because, we do have acpi video driver
>> in kernel today. Could yo
Begin forwarded message:
Date: Mon, 20 Feb 2006 20:13:59 -0400
From: Kevin Winchester <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Subject: x86_64 ACPI Error in 2.6.16-rc4-mm1
I have the following little message in my log with rc4-mm1 that I don't
have with vanilla rc4, running on a
Edgar Hucek <[EMAIL PROTECTED]> wrote:
>
> When EFI is enabled acpi_os_unmap_memory trys to unmap memory
> which was not mapped by acpi_os_map_memory.
Your email client replaces tabs with spaces and wordwraps things.
The patch could be cleaned up a bit..
Matt, ACPi people: please ack or nack as
Mark Lord <[EMAIL PROTECTED]> wrote:
>
> For the past week, I've been trying to keep with the latest -rc*-git*
> releases of 2.6.16 on my notebook, and something new in those is
> impacting resume-from-RAM.
>
> It works most of the time, but *rarely* when suspended for more
> than a few hours (lik
Hi,
>
>When EFI is enabled acpi_os_unmap_memory trys to unmap memory
>which was not mapped by acpi_os_map_memory.
Yes, this could solve you problem at hand, but I wonder why we should
always use ioremap in acpi_os_map_memory. It's ACPI tables or pci memory
bar, ioremap should be safe to me.
Thanks
I'm not sure this is EC caused trouble, because
the user report "Acpi says no matter what is
enabled/disabled from ec_intr and noapic: "
It looks like a regression since 2.6.12.
thanks,
luming
>The ec-burst thing seems to be causing quite a lot of problems
>out there.
>Is there somethi
When EFI is enabled acpi_os_unmap_memory trys to unmap memory
which was not mapped by acpi_os_map_memory.
Signed-off-by: Edgar Hucek <[EMAIL PROTECTED]>
diff -uNr linux-2.6.16-rc4.orig/drivers/acpi/osl.c
linux-2.6.16-rc4/drivers/acpi/osl.c
--- linux-2.6.16-rc4.orig/drivers/acpi/osl.c2006-02-
On Mon, Feb 20, 2006 at 12:17:49PM +0100, Henrik Brix Andersen wrote:
> Except that this daemon isn't written yet?
Given that it's about 20 lines of code plus the rest of acpid...
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
t
Hey folks,
I got an annoying problem with my fan, when I boot the system,
it is allways on, with full speed. If I start compiling some stuff,
or use BurnP6 to get the CPU over 65 degrees, the fan starts
to behave right and goes into passive mode on cooldown.
The notebook is an Asus M68Ne and has t
When EFI is enabled acpi_os_unmap_memory trys to unmap memory
which was not mapped by acpi_os_map_memory.
This patch for it.
Signed-off-by: Edgar Hucek <[EMAIL PROTECTED]>
diff -uNr linux-2.6.16-rc4.orig/drivers/acpi/osl.c
linux-2.6.16-rc4/drivers/acpi/osl.c
--- linux-2.6.16-rc4.orig/drivers/acp
This patch removes the following four unused global functions from
drivers/acpi/utilities/utmisc.c:
- acpi_ut_strupr()
- acpi_ut_report_warning()
- acpi_ut_report_info()
Is this patch OK or is future usage planned or are they still used on
other operating systems?
Signed-off-by: Adrian Bunk <[
The ec-burst thing seems to be causing quite a lot of problems out there.
Is there something we can do for 2.6.16?
Begin forwarded message:
Date: Mon, 20 Feb 2006 12:58:09 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6111] New: Acpi defunct -- buttons, battery
On Mon, Feb 20, 2006 at 07:25:26PM +0800, Jaya Kumar wrote:
> I have some questions then.
> 1. Are Patrick's acpi driver model changes considered to be a more
> final approach that standardize everyone to some sysfs based interface
> to userspace?
I don't believe so. Backlight drivers will still
On 2/20/06, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 20, 2006 at 06:49:54PM +0800, Jaya Kumar wrote:
>
> > I'm not sure how standard that is. For example, I looked at the asus
> > and toshiba drivers. These ACPI board drivers use
> > /proc/acpi/somedevice/lcd. For example,
>
> And,
On Mon, Feb 20, 2006 at 11:01:45AM +, Matthew Garrett wrote:
> Doing it via the input layer adds flexibility - it makes it easier for
> non-root uesrspace to handle things, but you can still have a root-level
> daemon that monitors /dev/input/event* and runs commands in response to
> keycode
On Mon, Feb 20, 2006 at 06:49:54PM +0800, Jaya Kumar wrote:
> I'm not sure how standard that is. For example, I looked at the asus
> and toshiba drivers. These ACPI board drivers use
> /proc/acpi/somedevice/lcd. For example,
And, from a userspace perspective, it sucks. I'm in the process of
writ
On Sun, Feb 19, 2006 at 02:45:06AM +0100, Vince wrote:
> Hello,
>
> I'm using an opteron 165 (dual-core) which frequency/voltage should
> be able to be scaled, but unfortunately the latest BIOS for my motherboard
> lacks the frequency transition tables needed by powernow-k8.c
>
> as shown by the
On 2/20/06, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 20, 2006 at 10:13:53AM +0800, [EMAIL PROTECTED] wrote:
>
> > + /* setup proc entry to set and get lcd brightness */
> > + proc = create_proc_read_entry("lcd", S_IFREG | S_IRUGO | S_IWUSR,
> > + atlas_pr
On Mon, Feb 20, 2006 at 10:13:53AM +0800, [EMAIL PROTECTED] wrote:
> + /* setup proc entry to set and get lcd brightness */
> + proc = create_proc_read_entry("lcd", S_IFREG | S_IRUGO | S_IWUSR,
> + atlas_proc_dir, atlas_read_proc_lcd, atlas_dev);
For basic sanity, coul
>mem38: type=7, attr=0xf, range=[0x1feef000-0x1fef)
(0MB)
>mem39: type=9, attr=0xf, range=[0x1fef-0x1feff000)
(0MB)
>mem40: type=6, attr=0x800f,
range=[0x1feff000-0x1ff0) (0MB)
>mem41: type=11, attr=0x8000,
range=[0
On 2/20/06, Yu, Luming <[EMAIL PROTECTED]> wrote:
> I found _BCM, _BCL ... which are reserved methods for
> ACPI video extension device. If the vendor follows
> ACPI video extension spec, this proposed driver is
> NOT needed. Because, we do have acpi video driver
> in kernel today. Could you pleas
I found _BCM, _BCL ... which are reserved methods for
ACPI video extension device. If the vendor follows
ACPI video extension spec, this proposed driver is
NOT needed. Because, we do have acpi video driver
in kernel today. Could you please show me acpidump
output?
Thanks,
Luming
>Hi Len, ACPI,
I don't think anybody claimed this isn't a regression for the 600X.
>
>>> I narrowed it further. The short story is that this commit (diff
>>> below sig) makes the second S3 sleep go into the endless loop, if
>>> the loaded modules are exactly thermal, processor, intel_agp, and
>>> agpgart:
>
23 matches
Mail list logo
