RE: [patch] 2.4.x ACPI updates

RE: [patch] 2.4.x ACPI updates

[Brown, Len]

> > Len,
> >
> > Patch applied, thanks.

Great!

> > Do you have any further information on the ACPI oops 
> reports I sent you?


I see this one in my inbox "Subject: 2.4.22-xx powerdown oddities" and
will follow-up.

If there are more, then forward them to me directly -- the mailing lists
have had some really weird latencies lately.

Thanks,
-Len

RE: [patch] 2.4.x ACPI updates

[Marcelo Tosatti]

On Sat, 23 Aug 2003, Brown, Len wrote:

>
> > > Len,
> > >
> > > Patch applied, thanks.
>
> Great!
>
> > > Do you have any further information on the ACPI oops
> > reports I sent you?
>
>
> I see this one in my inbox "Subject: 2.4.22-xx powerdown oddities" and
> will follow-up.
>
> If there are more, then forward them to me directly -- the mailing lists
> have had some really weird latencies lately.

plus this one

ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2

Re: [ACPI] RE: [patch] 2.4.x ACPI updates

[Karol Kozimor]

Thus wrote Marcelo Tosatti:
> ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2

Hi,
This is probably a BIOS / hardware bug, a rare occurence actually.
The logs show:
#v+
acpi_power-0363 [64] acpi_power_transition : Error transitioning device [CFAN] to D0
acpi_bus-0496 [63] acpi_bus_set_power    : Error transitioning device [CFAN] to D0
acpi_thermal-0549 [62] acpi_thermal_active   : Unable to turn cooling device [c12d2528] 'on'
Unable to handle kernel paging request at virtual address 876c33c4
[...]
#v-
(sometimes there's D3 in place of D0, depending on the trip points /
temperature readings), and then the oops follows. Unfortunately, I
can't provide the ksymoops output, as the kernel which the oops was logged
on has been gone long since.

Anyway, this is by no means reproducible, occurs quasi-randomly (more often
when the machine is cold, possibly due to the fact that actual state
transitions take place then), and causes various effects from keventd /
ACPI subsystem locking to system hangs.
Hope that helps, best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] RE: [patch] 2.4.x ACPI updates

[Eric Valette]

Marcelo Tosatti wrote:
> 
> On Sat, 23 Aug 2003, Brown, Len wrote:
> 
> 
>>>>Len,
>>>>
>>>>Patch applied, thanks.
>>
>>Great!
>>
>>
>>>>Do you have any further information on the ACPI oops
>>>
>>>reports I sent you?
>>
>>
>>I see this one in my inbox "Subject: 2.4.22-xx powerdown oddities" and
>>will follow-up.
>>
>>If there are more, then forward them to me directly -- the mailing lists
>>have had some really weird latencies lately.
> 
> 
> plus this one
> 
> ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2

Note that i have the same computer on run 2.4 ACPI for months without 
problems...

-- eric

Re: [ACPI] RE: [patch] 2.4.x ACPI updates

[Pavel Machek]

Hi!

> > ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2
> 
> Hi,
> This is probably a BIOS / hardware bug, a rare occurence actually.
> The logs show:
> #v+
> acpi_power-0363 [64] acpi_power_transition : Error transitioning device [CFAN] to D0
> acpi_bus-0496 [63] acpi_bus_set_power    : Error transitioning device [CFAN] to D0
> acpi_thermal-0549 [62] acpi_thermal_active   : Unable to turn cooling device [c12d2528] 'on'
> Unable to handle kernel paging request at virtual address 876c33c4
> [...]
> #v-
> (sometimes there's D3 in place of D0, depending on the trip points /
> temperature readings), and then the oops follows. Unfortunately, I
> can't provide the ksymoops output, as the kernel which the oops was logged
> on has been gone long since.
> 
> Anyway, this is by no means reproducible, occurs quasi-randomly (more often

You should be able to do echo ? > /proc/acpi/*/fan/state to stress this manually...
				Pavel

-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: [ACPI] RE: [patch] 2.4.x ACPI updates

[Karol Kozimor]

Thus wrote Pavel Machek:
> > This is probably a BIOS / hardware bug, a rare occurence actually.
> > The logs show:
> > #v+
> > acpi_power-0363 [64] acpi_power_transition : Error transitioning device [CFAN] to D0
> > acpi_bus-0496 [63] acpi_bus_set_power    : Error transitioning device [CFAN] to D0
> > acpi_thermal-0549 [62] acpi_thermal_active   : Unable to turn cooling device [c12d2528] 'on'
> > Unable to handle kernel paging request at virtual address 876c33c4
> > [...]
> > #v-
> > (sometimes there's D3 in place of D0, depending on the trip points /
> > temperature readings), and then the oops follows. Unfortunately, I
> > can't provide the ksymoops output, as the kernel which the oops was logged
> > on has been gone long since.
> > 
> > Anyway, this is by no means reproducible, occurs quasi-randomly (more often
> You should be able to do echo ? > /proc/acpi/*/fan/state to stress this manually...

Of course. It prints the messages, but doesn't oops. I'm waiting to
reproduce it on 2.4.23-pre here right now.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] RE: [patch] 2.4.x ACPI updates

[Karol Kozimor]

Thus wrote Karol Kozimor:
> > You should be able to do echo ? > /proc/acpi/*/fan/state to stress this manually...
> Of course. It prints the messages, but doesn't oops. I'm waiting to
> reproduce it on 2.4.23-pre here right now.

Gotcha! (see bug http://65.172.181.4/show_bug.cgi?id=1185 for reference)
2.4.23-pre3 (with some patches): first, the messages are printed: 

acpi_power-0363 [28] acpi_power_transition : Error transitioning device [CFAN] to D0
acpi_bus-0496 [27] acpi_bus_set_power    : Error transitioning device [CFAN] to D0
acpi_thermal-0549 [26] acpi_thermal_active   : Unable to turn cooling device [c12d24a8] 'on'

And then, 4 seconds after:

ksymoops 2.4.9 on i686 2.4.23-pre3-xcs.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.23-pre3-xcs/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Unable to handle kernel paging request at virtual address 876c33c4
*pde = 00000000
c01fd497
Oops: 0000
CPU:    0
EIP:    0010:[<c01fd497>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000   ebx: 876c33c4   ecx: cff0fd94   edx: 00000006
esi: 876c33c4   edi: cff0fdf0   ebp: c020c608   esp: cff0fd9c
ds: 0018   es: 0018   ss: 0018
Process keventd (pid: 2, stackpage=cff0f000)
Stack: 00001001 c01fe17f 876c33c4 cff0fdc8 cff0fdf0 876c33c4 cff0fe2c c020c686
       876c33c4 c020c608 cff0fdf0 00010000 c02cd715 c02cd6ca 00000050 cff0fdf4
       cff0fdf4 876c33c4 c0213efe 876c33c4 cff0fdf0 00000000 00800000 c02ce900
Call Trace: [<c01fe17f>]  [<c020c686>]  [<c020c608>]  [<c0213efe>]  [<c02142f5>]  [<c0214651>]  [<c020ca83>]  [<c0208e00>]  [<c0218342>]  [<c02186bf>]  [<c0219402>]  [<c01ecaa4>]  [<c01e484d>]  [<c011d02a>]  [<c01256b3>]  [<c0125580>]  [<c0105000>]  [<c01058ee>]  [<c0125580>]
Code: 80 3b aa 0f 44 c3 5b c3 a1 d4 6b 3d c0 eb f7 8b 44 24 04 c3


>>EIP; c01fd497 <acpi_ns_map_handle_to_node+17/26>   <=====

>>ecx; cff0fd94 <_end+fb19fbc/1241e288>
>>edi; cff0fdf0 <_end+fb1a018/1241e288>
>>ebp; c020c608 <acpi_bus_data_handler+0/39>
>>esp; cff0fd9c <_end+fb19fc4/1241e288>

Trace; c01fe17f <acpi_get_data+38/5d>
Trace; c020c686 <acpi_bus_get_device+45/ae>
Trace; c020c608 <acpi_bus_data_handler+0/39>
Trace; c0213efe <acpi_power_get_context+4a/ae>
Trace; c02142f5 <acpi_power_off_device+4a/1a7>
Trace; c0214651 <acpi_power_transition+113/13c>
Trace; c020ca83 <acpi_bus_set_power+170/298>
Trace; c0208e00 <acpi_ut_track_stack_ptr+1f/26>
Trace; c0218342 <acpi_thermal_active+c4/190>
Trace; c02186bf <acpi_thermal_check+29d/2ec>
Trace; c0219402 <acpi_thermal_notify+a9/10a>
Trace; c01ecaa4 <acpi_ev_notify_dispatch+52/75>
Trace; c01e484d <acpi_os_execute_deferred+39/75>
Trace; c011d02a <__run_task_queue+5a/70>
Trace; c01256b3 <context_thread+133/1d0>
Trace; c0125580 <context_thread+0/1d0>
Trace; c0105000 <_stext+0/0>
Trace; c01058ee <arch_kernel_thread+2e/40>
Trace; c0125580 <context_thread+0/1d0>

Code;  c01fd497 <acpi_ns_map_handle_to_node+17/26>
00000000 <_EIP>:
Code;  c01fd497 <acpi_ns_map_handle_to_node+17/26>   <=====
   0:   80 3b aa                  cmpb   $0xaa,(%ebx)   <=====
Code;  c01fd49a <acpi_ns_map_handle_to_node+1a/26>
   3:   0f 44 c3                  cmove  %ebx,%eax
Code;  c01fd49d <acpi_ns_map_handle_to_node+1d/26>
   6:   5b                        pop    %ebx
Code;  c01fd49e <acpi_ns_map_handle_to_node+1e/26>
   7:   c3                        ret
Code;  c01fd49f <acpi_ns_map_handle_to_node+1f/26>
   8:   a1 d4 6b 3d c0            mov    0xc03d6bd4,%eax
Code;  c01fd4a4 <acpi_ns_map_handle_to_node+24/26>
   d:   eb f7                     jmp    6 <_EIP+0x6>
Code;  c01fd4a6 <acpi_ns_convert_entry_to_handle+0/5>
   f:   8b 44 24 04               mov    0x4(%esp,1),%eax
Code;  c01fd4aa <acpi_ns_convert_entry_to_handle+4/5>
  13:   c3                        ret

Hope that helps.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

RE: [ACPI] RE: [patch] 2.4.x ACPI updates

[Brown, Len]

Yeah, broke this in 2.6 also -- apparently neglected to test that change w/o CONFIG_SMP...

Patrick suggested a cleaner way to do this code using fewer #ifdefs, so I'll try that out this evening.  Until that arrives, you can just nuke that line and the "noapic" flag will revert to being broken in ACPI mode like it was before this week.

Thanks,
-Len

===== arch/i386/kernel/setup.c 1.91 vs edited =====
--- 1.91/arch/i386/kernel/setup.c	Sat Aug 16 00:28:34 2003
+++ edited/arch/i386/kernel/setup.c	Wed Aug 20 19:48:21 2003
@@ -545,7 +545,7 @@
 
 		/* disable IO-APIC */
 		else if (!memcmp(from, "noapic", 6)) {
-			skip_ioapic_setup = 1;
+//			skip_ioapic_setup = 1;
 		}
 #endif

Re: [ACPI] RE: [patch] 2.4.x ACPI updates

[Sérgio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Hi

So had this compile error :
setup.c: In function `parse_cmdline_early':
setup.c:830: `skip_ioapic_setup' undeclared (first use in this function)
setup.c:830: (Each undeclared identifier is reported only once
setup.c:830: for each function it appears in.)

Since just in arch/i386/kernel/io_apic.c, skip_ioapic_setup is declared
and in arch/i386/kernel/Makefile we have
obj-$(CONFIG_X86_IO_APIC)       += io_apic.o
I think this is the correct patch.

thanks

On Wed, 2003-08-20 at 19:15, Marcelo Tosatti wrote:
> 
> 
> On Tue, 19 Aug 2003, Brown, Len wrote:
> 
> > Andy/Jeff/Marcelo,
> >
> > At Jeff's request, I've back ported ACPICA 20030813 from
> > http://linux-acpi.bkbits.net/linux-acpi-2.4 into a new tree for 2.4.22:
> > http://linux-acpi.bkbits.net/linux-acpi-2.4.22
> >
> > I've restored acpitable.[ch], which was deleted too late for this
> > release cycle; and will live on until 2.4.23 -- as well as restored
> > CONFIG_ACPI_HT_ONLY under CONFIG_ACPI; restored the 8-bit characters
> > that got expanded to 16-bits in a previous merge; and deleted some dmesg
> > verbiage that Jeff didn't think was appropriate for the baseline kernel.
> >
> > I exported this a patch and then imported onto a clone of Marcelo's
> > tree, so it appears as a single cset where the changes that got un-done
> > never happened.  I've done some sanity tests on it, and will test it
> > some more tomorrow.  Take a look at it and let me know if I missed
> > anything.  When Andy is happy with it I'll leave it to him to re-issue a
> > pull request from Marcelo.
> 
> Cool!!
> 
> Ill try to take a look at the patch now (having serious conectivity issues
> :()
> 
-- 
SérgioMB
email: sergiomb@netcabo.pt

Who gives me one shell, give me everything.

[-- Attachment #2: fixcompile.diff --]
[-- Type: text/plain, Size: 628 bytes --]

--- linux-2.4.22-rc2.orig/arch/i386/kernel/setup.c	Wed Aug 20 23:52:45 2003
+++ linux-2.4.22-rc2/arch/i386/kernel/setup.c	Wed Aug 20 23:54:36 2003
@@ -824,11 +824,12 @@
 			acpi_ht = 1; 
 			if (!acpi_force) acpi_disabled = 1; 
 		} 
-
-                /* disable IO-APIC */
-                else if (!memcmp(from, "noapic", 6)) {
-                        skip_ioapic_setup = 1;
-                }
+#ifdef CONFIG_X86_IO_APIC
+		/* disable IO-APIC */
+		else if (!memcmp(from, "noapic", 6)) {
+			skip_ioapic_setup = 1;
+		}
+#endif
 #endif
 		/*
 		 * highmem=size forces highmem to be exactly 'size' bytes.