IBM Desktop patches
Hello, Just thought I'd inquire about people with IBM Desktops, and the inclusion of these machines within all this ACPI hullabaloo. I currently have FC5 running on an IBM ThinkCentre 8147-11U model. I am constantly having issues with this system, and I believe they are probably ACPI related. I've Googled my issue, and it revolves around leaving the PC up overnight, and coming back to slowed-to-a-crawl Linux box. It acts like the system-clock has been slowed, time is off by hours, and you pretty much have to reboot in order to correct the issue. I've seen where a few others have talked about having this problem, so I'm wondering if anyone in the Fedora community has formally brought this problem up. If not, it's definately an issue that should be addressed. Thanks, Jeff Ferrera FiServ Technical Services - Arlington Heights - 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
Re: [PATCH] Check battery after resume
On Fri, 2006-08-04 at 13:09 -0400, Dave Jones wrote:
On Fri, Aug 04, 2006 at 03:46:31PM +0200, Thomas Renninger wrote:
On Thu, 2006-08-03 at 15:02 -0400, Dave Jones wrote:
On Thu, Aug 03, 2006 at 07:17:37PM +0200, Thomas Renninger wrote:
+/*
+ * returns:
+ * 0 on success
+ * 0 on failure
+ * 1 if new battery found
+ * 2 if battery got removed
+ */
Why make this so complicated...
+ result = acpi_battery_check(battery);
+ if (result 0){
+ acpi_bus_generate_event(device,
+ ACPI_NOTIFY_DEVICE_CHECK,
+ battery-flags.present);
+ }
+ return 0;
+}
When we simply treat the result as a boolean ?
The return value is used to:
check for error 0
success, no battery insertion/removal 0
battery insertion/removal 0 (1/2)
The latter one is needed to inform userspace to reread complete battery
information (possibly from other BATx dir) if battery has been
inserted/removed.
The code cares about 2 possible states 'is there a battery added/removed'.
Yet there are 4 possible states for no obvious reason.
acpi_battery_check code could just as easily return
0=nothing changed, 1=battery added/removed, as you don't distinguish
between states '1' and '2' anyway.
But it is already checked for an error at the initial acpi_battery_add
function which is mandatory:
result = acpi_battery_check(battery);
if (result 0)
goto end;
- I need three states here: error, success no hw change, success + hw
change.
Thinking about this again, maybe an error should also be checked in the
resume case. It might be that an additional battery is added and the
ACPI code is executed the first time. The user might want to know that
something went wrong... On the other side ACPI code should throw an
exception if something happens during ACPI func execution... not sure
whether the additional printk(KERN_ERR..) is needed, it shouldn't hurt,
though.
Is this OK:
Check battery after resume
Signed-off-by: Thomas Renninger [EMAIL PROTECTED]
drivers/acpi/battery.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
Index: linux-acpi-2.6.git_i386/drivers/acpi/battery.c
===
--- linux-acpi-2.6.git_i386.orig/drivers/acpi/battery.c
+++ linux-acpi-2.6.git_i386/drivers/acpi/battery.c
@@ -64,6 +64,7 @@ extern void *acpi_unlock_battery_dir(str
static int acpi_battery_add(struct acpi_device *device);
static int acpi_battery_remove(struct acpi_device *device, int type);
+static int acpi_battery_resume(struct acpi_device *device, int state);
static struct acpi_driver acpi_battery_driver = {
.name = ACPI_BATTERY_DRIVER_NAME,
@@ -72,6 +73,7 @@ static struct acpi_driver acpi_battery_d
.ops = {
.add = acpi_battery_add,
.remove = acpi_battery_remove,
+ .resume = acpi_battery_resume,
},
};
@@ -269,6 +271,13 @@ acpi_battery_set_alarm(struct acpi_batte
return 0;
}
+/*
+ * returns:
+ * 0 on failure
+ * 0 on success, no hw change
+ * 1 on success and battery got inserted/removed
+ */
+
static int acpi_battery_check(struct acpi_battery *battery)
{
int result = 0;
@@ -311,12 +320,14 @@ static int acpi_battery_check(struct acp
battery-flags.alarm = 1;
acpi_battery_set_alarm(battery, battery-trips.warning);
}
+ result = 1;
}
/* Removal? */
else if (battery-flags.present !device-status.battery_present) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, Battery removed\n));
+ result = 1;
}
battery-flags.present = device-status.battery_present;
@@ -703,7 +714,7 @@ static int acpi_battery_add(struct acpi_
acpi_driver_data(device) = battery;
result = acpi_battery_check(battery);
- if (result)
+ if (result 0)
goto end;
result = acpi_battery_add_fs(device);
@@ -753,6 +764,33 @@ static int acpi_battery_remove(struct ac
return 0;
}
+static int acpi_battery_resume(struct acpi_device *device, int state){
+
+ int result = 0;
+ struct acpi_battery *battery = NULL;
+
+ if (!device || !acpi_driver_data(device))
+ return -EINVAL;
+
+ battery = (struct acpi_battery *)acpi_driver_data(device);
+
+ result = acpi_battery_check(battery);
+ if (!result){
+ if (result 0){
+ acpi_bus_generate_event(device,
+ ACPI_NOTIFY_DEVICE_CHECK,
+ battery-flags.present);
+
Re: [-mm patch] make arch/i386/kernel/acpi/boot.c:acpi_force static
On Monday 07 August 2006 17:49, Adrian Bunk wrote: acpi_force can become static. Both patches added thanks -Andi - 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
RE: Options depending on STANDALONE
On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote: On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote: ACPI_CUSTOM_DSDT seems to be the most interesting case. It's anyway not usable for distribution kernels, and AFAIR the ACPI people prefer to get the kernel working with all original DSDTs (which usually work with at least one other OS) than letting the people workaround the problem by using a custom DSDT. Not true at all. For SuSE kernels, we have a patch that lets people load a new DSDT from initramfs due to broken machines requiring a replacement in order to work properly. CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system by building a modified DSDT into the kernel to over-ride what came with the system. It would make no sense for a distro to use it, unless the distro were shipping only on 1 model machine. This technique is necessary for debugging, but makes no sense for production. The initramfs method shipped by SuSE is more flexible, allowing the hacker to stick the DSDT image in the initrd and use it without re-compiling the kernel. I have refused to accept the initrd patch into Linux many times, and always will. I've advised SuSE many times that they should not be shipping it, as it means that their supported OS is running on modified firmware -- which, by definition, they can not support. Tainting the kernel if done so should be sufficient. Indeed, one could view this method as couter-productive to the evolution of Linux -- since it is our stated goal to run on the same machines that Windows runs on -- without requiring customers to modify those machines to run Linux. There are three reasons for the initrd patch (last one also applies for the compile in functionality): 1) There might be BIOS bugs that will never get fixed: https://bugzilla.novell.com/show_bug.cgi?id=160671 (Because it's an obvious BIOS bug, compatibility fixing it could make things worse). 2) There might be ACPICA/kernel bugs that take a while until they get fixed: This happens often. There comes out a new machine, using AML in a slightly other way, we need to fix it in kernel/ACPICA. Until the patch appears mainline may take a month or two. Until the distro of your choice that makes use of the fix comes out might take half a year or more... And backporting ACPICA fixes to older kernels is currently not possible as ACPICA patches appear in a big bunch of some thousand lines patches. But this hopefully changes soon. In my mind come: - alias broken in certain cases https://bugziall.novell.com/show_bug.cgi?id=113099 - recon amount of elements in packages https://bugzilla.novell.com/show_bug.cgi?id=189488 - wrong offsets at Field and Operation Region declarations - should be compatible for quite a while now - ... 3) Debugging. This is why at least compile in or via initrd must be provided in mainline kernel IMHO. Intel people themselves ask the bug reporter to override ACPI tables with a patched table to debug the system. Do you really think ripping out all overriding functionality from the kernel is a good idea? Thomas It is true that some users are happy with a fixed DSDT, even you tell them to find the root cause..., but sooner or later they always come back. - 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
Re: Options depending on STANDALONE
On Mon, Aug 07, 2006 at 07:33:31PM +0200, Thomas Renninger wrote: On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote: On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote: ACPI_CUSTOM_DSDT seems to be the most interesting case. It's anyway not usable for distribution kernels, and AFAIR the ACPI people prefer to get the kernel working with all original DSDTs (which usually work with at least one other OS) than letting the people workaround the problem by using a custom DSDT. Not true at all. For SuSE kernels, we have a patch that lets people load a new DSDT from initramfs due to broken machines requiring a replacement in order to work properly. CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system by building a modified DSDT into the kernel to over-ride what came with the system. It would make no sense for a distro to use it, unless the distro were shipping only on 1 model machine. This technique is necessary for debugging, but makes no sense for production. The initramfs method shipped by SuSE is more flexible, allowing the hacker to stick the DSDT image in the initrd and use it without re-compiling the kernel. I have refused to accept the initrd patch into Linux many times, and always will. I've advised SuSE many times that they should not be shipping it, as it means that their supported OS is running on modified firmware -- which, by definition, they can not support. Tainting the kernel if done so should be sufficient. Indeed, one could view this method as couter-productive to the evolution of Linux -- since it is our stated goal to run on the same machines that Windows runs on -- without requiring customers to modify those machines to run Linux. There are three reasons for the initrd patch (last one also applies for the compile in functionality): snip Yeah, you and others within SuSE have convinced me to not drop this patch from our kernel tree. Sorry Len. thanks, greg k-h - 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
