Re: [ACPI] No handler for Region [ERAM] on Gateway M350?

[Dan <da...@in...>]

> problems...I shall continue poking away at the 2.6 tree in an attempt to
> patch it with the ecdt_fake patch =)

Well, I've managed to get the patch (from
http://sourceforge.net/mailarchive/message.php?msg_id=6561311) to apply
to the 2.6.1 kernel source, and it does indeed fix my issue with not
seeing the /proc/acpi/battery/BAT0 directory, only it seems to have
broken the event model -- acpid no longer reports any events, nor can I
pick them up by hand by watching /proc/acpi/event ... I suspect that
this is due to the tinkering that I had to do with regards to the fact
that schedule_task() no longer exists in linux/sched.h in 2.6 (I'm
assuming due to the massive scheduler overhaul done between versions),
and so I was somewhat at a loss as for what to do with the following
section of the patch to drivers/acpi/osl.c (note my comment near the end
for the particular line that is the source of most of my troubles):

@@ -639,45 +651,63 @@
  	void			*context)
  {
  	acpi_status 		status = AE_OK;
 -	struct acpi_os_dpc	*dpc = NULL;
 -	struct tq_struct	*task;
 +	struct acpi_os_dpc	*dpc;
  
 -	ACPI_FUNCTION_TRACE ("os_queue_for_execution");
 +	ACPI_FUNCTION_TRACE ("acpi_os_queue_for_execution");
  
  	ACPI_DEBUG_PRINT ((ACPI_DB_EXEC, "Scheduling function [%p(%p)] for deferred
execution.\n", function, context));
  
  	if (!function)
  		return_ACPI_STATUS (AE_BAD_PARAMETER);
 -
 -	/*
 -	 * Allocate/initialize DPC structure.  Note that this memory will be
 -	 * freed by the callee.  The kernel handles the tq_struct list  in a
 -	 * way that allows us to also free its memory inside the callee.
 -	 * Because we may want to schedule several tasks with different
 -	 * parameters we can't use the approach some kernel code uses of
 -	 * having a static tq_struct.
 -	 * We can save time and code by allocating the DPC and tq_structs
 -	 * from the same memory.
 -	 */
 -	dpc = kmalloc(sizeof(struct acpi_os_dpc)+sizeof(struct tq_struct), GFP_ATOMIC);
 +	dpc = kmalloc(sizeof(struct acpi_os_dpc), GFP_ATOMIC);
  	if (!dpc)
  		return_ACPI_STATUS (AE_NO_MEMORY);
  
  	dpc->function = function;
  	dpc->context = context;
 -
 -	task = (void *)(dpc+1);
 -	INIT_TQUEUE(task, acpi_os_execute_deferred, (void*)dpc);
 -
 -	if (!schedule_task(task)) {
 -		ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Call to schedule_task() failed.\n"));
 -		kfree(dpc);
 -		status = AE_ERROR;
 +	INIT_LIST_HEAD(&dpc->next);
 +	
 +	spin_lock(&acpi_events_list_spinlock);
 +	list_add_tail(&dpc->next, &acpi_events_list);
 +	if (first_acpi_event || (!task.sync)) {
 +		INIT_TQUEUE(&task, do_acpi_task_queue, NULL);
/* ****** This line below in particular; all else stems from this =\ ***** */
 +		if (!schedule_task(&task)) {   
 +			ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Call to schedule_work() failed.\n"));
 +			kfree(dpc);
 +			status = AE_ERROR;
 +		}
 +		first_acpi_event = 0;
  	}
 +	spin_unlock(&acpi_events_list_spinlock);
  
~~~~~~~~~End patch excerpt~~~~~~~~

Unfortunately, I don't know much about task scheduling in the 2.6 kernel, 
so I'm stuck on this one for a bit, at least...any ideas from someone more 
knowledgeable than I about this sort of thing? =)

Thanks,
~D. Stone