2.4.23pre8 - ACPI Kernel Panic on boot

2.4.23pre8 - ACPI Kernel Panic on boot

[Joachim Bremer]

Hi,

on my laptop HP NX9005 2.4.23pre8 will panic on boot. Tracing
down the differences between 2.4.23pre7 and pre8 a found that
the problems is in patchset 1.1063.43.26. Backing out this patch
lets the laptop boot again. Decode oops follows.

Joachim

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
kernel BUG at slab.c:1130!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c012df25>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 000001f0   ebx: c1797270   ecx: 000001f0   edx: c02db798
esi: c1797278   edi: c1797270   ebp: 000001f0   esp: c031da84
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=c031d000)
Stack: c031dac0 00000388 c01ca227 00200000 00000388 c1797270 c1797278 00000246
       000001f0 c012e2a3 c1797270 000001f0 00000009 c031dad8 00000001 00000001
       c01a5cde 00000060 000001f0 c01c8ebc 00000060 00000001 c02a78c1 c02a7884
Call trace:    [<c01ca227>] [<c012e2a3>] [<c01a5cde>] [<c01c8ebc>] [<c01c8fad>]
  [<c01c8c82>] [<c01ca153>] [<c01cc793>] [<c01c168f>] [<c01c0dec>] [<c01c0f3c>]
  [<c01c8c36>] [<c01ca1d4>] [<c01ac6bf>] [<c01c1408>] [<c01c141d>] [<c01a8073>]
  [<c01c1454>] [<c01c207a>] [<c01bcabc>] [<c01bc995>] [<c01bc71d>] [<c01ba804>]
  [<c01bf28d>] [<c01d1b49>] [<c01d1bc5>] [<c01ad11d>] [<c01acf2e>] [<c01af467>]
  [<c01a5e0f>] [<c01087c5>] [<c01a5e03>] [<c0108944>] [<c010ac98>] [<c01d591f>]
  [<c01d5843>] [<c0105372>] [<c0105000>]
Code: 0f 0b 6a 04 0e 4d 29 c0 89 c8 c7 44 24 0c 01 00 00 00 25 f0


>>EIP; c012df25 <kmem_cache_grow+45/1f0>   <=====

>>edx; c02db798 <cache_sizes+18/c0>
>>esp; c031da84 <init_task_union+1a84/2000>

Trace; c01ca227 <acpi_ut_status_exit+49/55>
Trace; c012e2a3 <kmalloc+e3/110>
Trace; c01a5cde <acpi_os_allocate+e/11>
Trace; c01c8ebc <acpi_ut_callocate+75/e5>
Trace; c01c8fad <acpi_ut_callocate_and_track+20/81>
Trace; c01c8c82 <acpi_ut_acquire_from_cache+cf/e3>
Trace; c01ca153 <acpi_ut_trace_ptr+2c/30>
Trace; c01cc793 <acpi_ut_create_generic_state+c/15>
Trace; c01c168f <acpi_ps_push_scope+3c/b0>
Trace; c01c0dec <acpi_ps_parse_loop+4ce/a40>
Trace; c01c0f3c <acpi_ps_parse_loop+61e/a40>
Trace; c01c8c36 <acpi_ut_acquire_from_cache+83/e3>
Trace; c01ca1d4 <acpi_ut_exit+1d/27>
Trace; c01ac6bf <acpi_ds_push_walk_state+4a/51>
Trace; c01c1408 <acpi_ps_parse_aml+aa/242>
Trace; c01c141d <acpi_ps_parse_aml+bf/242>
Trace; c01a8073 <acpi_ds_call_control_method+171/261>
Trace; c01c1454 <acpi_ps_parse_aml+f6/242>
Trace; c01c207a <acpi_psx_execute+226/2b0>
Trace; c01bcabc <acpi_ns_execute_control_method+e5/104>
Trace; c01bc995 <acpi_ns_evaluate_by_handle+df/121>
Trace; c01bc71d <acpi_ns_evaluate_relative+141/192>
Trace; c01ba804 <acpi_hw_low_level_read+10f/11c>
Trace; c01bf28d <acpi_evaluate_object+179/282>
Trace; c01d1b49 <acpi_ec_gpe_query+104/11b>
Trace; c01d1bc5 <acpi_ec_gpe_handler+65/93>
Trace; c01ad11d <acpi_ev_gpe_dispatch+7e/1bb>
Trace; c01acf2e <acpi_ev_gpe_detect+119/16a>
Trace; c01af467 <acpi_ev_sci_xrupt_handler+37/4d>
Trace; c01a5e0f <acpi_irq+c/e>
Trace; c01087c5 <handle_IRQ_event+45/70>
Trace; c01a5e03 <acpi_irq+0/e>
Trace; c0108944 <do_IRQ+64/a0>
Trace; c010ac98 <call_do_IRQ+5/d>
Trace; c01d591f <acpi_processor_idle+dc/1cf>
Trace; c01d5843 <acpi_processor_idle+0/1cf>
Trace; c0105372 <cpu_idle+42/60>
Trace; c0105000 <_stext+0/0>

Code;  c012df25 <kmem_cache_grow+45/1f0>
00000000 <_EIP>:
Code;  c012df25 <kmem_cache_grow+45/1f0>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c012df27 <kmem_cache_grow+47/1f0>
   2:   6a 04                     push   $0x4
Code;  c012df29 <kmem_cache_grow+49/1f0>
   4:   0e                        push   %cs
Code;  c012df2a <kmem_cache_grow+4a/1f0>
   5:   4d                        dec    %ebp
Code;  c012df2b <kmem_cache_grow+4b/1f0>
   6:   29 c0                     sub    %eax,%eax
Code;  c012df2d <kmem_cache_grow+4d/1f0>
   8:   89 c8                     mov    %ecx,%eax
Code;  c012df2f <kmem_cache_grow+4f/1f0>
   a:   c7 44 24 0c 01 00 00      movl   $0x1,0xc(%esp,1)
Code;  c012df36 <kmem_cache_grow+56/1f0>
  11:   00 
Code;  c012df37 <kmem_cache_grow+57/1f0>
  12:   25 f0 00 00 00            and    $0xf0,%eax

 <0>Kernel panic: Aiee, killing interrupt handler!

Re: 2.4.23pre8 - ACPI Kernel Panic on boot

[Marcelo Tosatti]

On Tue, 28 Oct 2003, Joachim Bremer wrote:

> Hi,
> 
> on my laptop HP NX9005 2.4.23pre8 will panic on boot. Tracing
> down the differences between 2.4.23pre7 and pre8 a found that
> the problems is in patchset 1.1063.43.26. Backing out this patch
> lets the laptop boot again. Decode oops follows.

Joachim, 

The patch in question has caused other problems and will be removed.

RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Kristofer T. Karas]

Marcelo Tosatti wrote:

>Joachim, 
>The patch in question has caused other problems and will be removed.
>  
>

Speaking of patches causing problems and needing reversion, can the 
screen-corrupting RadeonFB patch introduced in 2.4.23-pre3 be reverted 
until such time as it is fixed?  I know there was a maintainer war going 
on over who should officially submit RadeonFB patches; somewhere in 
there, updates and fixes stopped coming.

As it now stands in current -pre kernels, returning from XFree86 to a 
RadeonFB console results in total gibberish all over the screen (with my 
hardware anyway, a standard Built-by-ATI Radeon 8500 LE chipset QL 
rev0).  There is no workaround, other than to return to X.  Another bug 
also causes screen corruption when switching VCs (it forgets where in 
the YPan it is), but this can be easily worked around by setting VYRES = 
YRES (fbset -match -a).

The previous version of RadeonFB in 2.4.23-pre2 and earlier works just 
fine on my Radeon 8500 hardware, albeit without accelerated scrolling.  
Of course, if people with other Radeon flavors can't use the older 
driver but the newer one works for them, then short of a 
CONFIG_OLD_RADEONFB, I guess we should keep the current one...

Kris

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Javier Villavicencio]

On Tue, 28 Oct 2003 17:42:17 -0500
"Kristofer T. Karas" <ktk@enterprise.bidmc.harvard.edu> wrote:

> Marcelo Tosatti wrote:
> 
> >Joachim, 
> >The patch in question has caused other problems and will be removed.
> >  
> >
> 
> Speaking of patches causing problems and needing reversion, can the 
> screen-corrupting RadeonFB patch introduced in 2.4.23-pre3 be reverted 
> until such time as it is fixed?  I know there was a maintainer war going 
> on over who should officially submit RadeonFB patches; somewhere in 
> there, updates and fixes stopped coming.
> 
> As it now stands in current -pre kernels, returning from XFree86 to a 
> RadeonFB console results in total gibberish all over the screen (with my 
> hardware anyway, a standard Built-by-ATI Radeon 8500 LE chipset QL 
> rev0).  There is no workaround, other than to return to X.  Another bug 
> also causes screen corruption when switching VCs (it forgets where in 
> the YPan it is), but this can be easily worked around by setting VYRES = 
> YRES (fbset -match -a).
> 
> The previous version of RadeonFB in 2.4.23-pre2 and earlier works just 
> fine on my Radeon 8500 hardware, albeit without accelerated scrolling.  
> Of course, if people with other Radeon flavors can't use the older 
> driver but the newer one works for them, then short of a 
> CONFIG_OLD_RADEONFB, I guess we should keep the current one...
> 

Just to add some words about this, the older patch doesn't have support
for my Radeon 9600 Pro (RV350 chipset AP), so I tried the new one,
which has support, but only that, the new one is what Kristofer told
here among other things. So I added (just guessing, no idea if that was
right, for fun maybe) the PCI_IDs and RV350 checks in some places
of the old driver (I'm pretty sure they're all wrong), compiled and tried.
The old driver works *just fine* with my Radeon 9600, I only have a little
character distortion when trying to show the default linux logo, it shows 
without problems my customized logo, strange this. I can switch from X
without any trouble and the console looks fine.
I did this for kernel version prior to linux-2.6.0-test9 there are a new fbdev
patch but I added the radeonfb_setup function to it, it wasn't compiling
, not taking arguments from the kernel command line video=...., and 
has the same behaviour as the new driver.


Salu2.

Javier Villavicencio
-----------------------
qué desastre.-

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Marcelo Tosatti]

On Tue, 28 Oct 2003, Javier Villavicencio wrote:

> On Tue, 28 Oct 2003 17:42:17 -0500
> "Kristofer T. Karas" <ktk@enterprise.bidmc.harvard.edu> wrote:
> 
> > Marcelo Tosatti wrote:
> > 
> > >Joachim, 
> > >The patch in question has caused other problems and will be removed.
> > >  
> > >
> > 
> > Speaking of patches causing problems and needing reversion, can the 
> > screen-corrupting RadeonFB patch introduced in 2.4.23-pre3 be reverted 
> > until such time as it is fixed?  I know there was a maintainer war going 
> > on over who should officially submit RadeonFB patches; somewhere in 
> > there, updates and fixes stopped coming.
> > 
> > As it now stands in current -pre kernels, returning from XFree86 to a 
> > RadeonFB console results in total gibberish all over the screen (with my 
> > hardware anyway, a standard Built-by-ATI Radeon 8500 LE chipset QL 
> > rev0).  There is no workaround, other than to return to X.  Another bug 
> > also causes screen corruption when switching VCs (it forgets where in 
> > the YPan it is), but this can be easily worked around by setting VYRES = 
> > YRES (fbset -match -a).
> > 
> > The previous version of RadeonFB in 2.4.23-pre2 and earlier works just 
> > fine on my Radeon 8500 hardware, albeit without accelerated scrolling.  
> > Of course, if people with other Radeon flavors can't use the older 
> > driver but the newer one works for them, then short of a 
> > CONFIG_OLD_RADEONFB, I guess we should keep the current one...

There have been no radeonfb changes in 2.4.23-pre, what has been updated 
is DRM.

Are you using DRM? 

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Kristofer T. Karas]

Marcelo Tosatti wrote:

>There have been no radeonfb changes in 2.4.23-pre, what has been updated 
>is DRM.
>
>Are you using DRM? 
>  
>
Sorry Marcelo, dain bramage on my part.  I meant 2.4.22-pre.  I think it 
was -pre3 that upgraded drivers/video/radeonfb.c from version 0.1.4 to 
version 0.1.8-ben

I guess the newer 0.1.8 is needed to support Radeon 9600's.  I'm curious 
as to whether other people have the same massive screen corruption 
problems returning from X as I do.  If not, probably best to keep the 
new driver.  (Maybe I should go out and buy myself a new Radeon. :-)  I 
have been using ATI's private DRI/DRM kernel module driver (fglrx) in 
concert with XFree 4.2.0 for quite some time.

Kris

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Kronos]

> I guess the newer 0.1.8 is needed to support Radeon 9600's.  I'm curious 
> as to whether other people have the same massive screen corruption 
> problems returning from X as I do.  If not, probably best to keep the 
> new driver.  (Maybe I should go out and buy myself a new Radeon. :-)  I 
> have been using ATI's private DRI/DRM kernel module driver (fglrx) in 
> concert with XFree 4.2.0 for quite some time.

Ah! ATI's driver touches registers behind our back. Can you reproduce
without this binary module?

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Al termine di un pranzo di nozze mi hanno dato un
amaro alle erbe cosi' schifoso che perfino sull'etichetta
c'era un frate che vomitava.

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Kristofer T. Karas]

On Wed, 2003-10-29 at 16:03, Kronos wrote:
> > have been using ATI's private DRI/DRM kernel module driver (fglrx) in 
> > concert with XFree 4.2.0 for quite some time.
> 
> Ah! ATI's driver touches registers behind our back. Can you reproduce
> without this binary module?

Hi Luca, et al,

Yes, I can reproduce without the tainting kernel module (fglrx.o). 
Debugging a bit, the corruption shows up when using ATI's "fglr" device
driver in XF86Config.  If I switch to using the unaccelerated "Radeon"
driver provided by XFree, then the screen remains readable upon return
from X.  Thus, the kernel module is OK, the ATI proprietary glx and dri
modules are OK, it's just the driver.

However, I still think this belongs as a kernel issue, because it
appears to be a failing of the radeonfb.o module to properly set the
radeon registers.  Remember that version 0.1.4 of the driver does not
have this issue; it works just fine with the ATI fglr X driver.

Kris

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Benjamin Herrenschmidt]

> Yes, I can reproduce without the tainting kernel module (fglrx.o). 
> Debugging a bit, the corruption shows up when using ATI's "fglr" device
> driver in XF86Config.  If I switch to using the unaccelerated "Radeon"
> driver provided by XFree, then the screen remains readable upon return
> from X.  Thus, the kernel module is OK, the ATI proprietary glx and dri
> modules are OK, it's just the driver.
> 
> However, I still think this belongs as a kernel issue, because it
> appears to be a failing of the radeonfb.o module to properly set the
> radeon registers.  Remember that version 0.1.4 of the driver does not
> have this issue; it works just fine with the ATI fglr X driver.

Ok, first thing: XFree "radeon" _is_ accelerated, though it doesn't
do 3D on recent cards

Then, the problem you are having is well known and I don't have a
simple workaround at hand other than re-initing the engine on each
console switch, which I would have very much liked to avoid... maybe
I can add an fbdev hook to the switch from KD_GRAPHICS to KD_TEXT
which is what we really want to cleanup the engine.

Can you verify that running fbset -accel 0 then back 1 cures the
problem for you ?

Ben.
 

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Kristofer T. Karas]

Benjamin Herrenschmidt wrote:

>Ok, first thing: XFree "radeon" _is_ accelerated, though it doesn't
>do 3D on recent cards
>
Hi Ben - Right, sorry, I mean to apply "accelerated" to the 3D effects; 
the private ATI driver is much faster on glxgears than the version that 
bundles with XFree.

>Then, the problem you are having is well known
>
I'm having two, actually.  The first is that YPAN is getting quite 
confused.  If I switch VCs, then switch back, the text has been 
re-arranged, the cursor is often invisible, and sometimes a page or two 
of new text must be written before anything starts to show up on the 
screen again.  Experimenting shows that setting VYRES = YRES works 
around this problem.

The second problem is of course the register contents issue when 
returning from certain graphics programs (e.g. X+fglr) to text mode..  I 
rather like your idea of doing a re-init when switching from KD_GRAPHICS 
to KD_TEXT, as the monitor blank during resolution switch will likely 
overshadow the re-init process.

>Can you verify that running fbset -accel 0 then back 1 cures the
>problem for you ?
>  
>

At work now, will try when I return home later...

Kris

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Benjamin Herrenschmidt]

On Sat, 2003-11-01 at 06:16, Kristofer T. Karas wrote:
> Benjamin Herrenschmidt wrote:
> 
> >Ok, first thing: XFree "radeon" _is_ accelerated, though it doesn't
> >do 3D on recent cards
> >
> Hi Ben - Right, sorry, I mean to apply "accelerated" to the 3D effects; 
> the private ATI driver is much faster on glxgears than the version that 
> bundles with XFree.
> 
> >Then, the problem you are having is well known
> >
> I'm having two, actually.  The first is that YPAN is getting quite 
> confused.  If I switch VCs, then switch back, the text has been 
> re-arranged, the cursor is often invisible, and sometimes a page or two 
> of new text must be written before anything starts to show up on the 
> screen again.  Experimenting shows that setting VYRES = YRES works 
> around this problem.

I'll have to look at this in more details. I don't see why ypan would
cause such screen re-arrangement though...

> The second problem is of course the register contents issue when 
> returning from certain graphics programs (e.g. X+fglr) to text mode..  I 
> rather like your idea of doing a re-init when switching from KD_GRAPHICS 
> to KD_TEXT, as the monitor blank during resolution switch will likely 
> overshadow the re-init process.
> 
> >Can you verify that running fbset -accel 0 then back 1 cures the
> >problem for you ?
> >  
> >
> 
> At work now, will try when I return home later...
> 
> Kris

Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot]

[Kristofer T. Karas]

On Fri, 2003-10-31 at 02:59, Benjamin Herrenschmidt wrote:
> Can you verify that running fbset -accel 0 then back 1 cures the
> problem for you ?

Hi Ben -

Tried it, no effect.  It did not seem to do a reset of the card; sync
never hiccupped.  I also set the mode to a different one and back; that
had no effect, either.  I'm using fbset 2.1 from the linux-fbdev site.

As for the YPAN problem, I have the screen set to 1280x1024 using the
sun 22x12 font.

Kris

Re: 2.4.23pre8 - ACPI Kernel Panic on boot

[Marcos D. Marado Torres]

The same happens wit me in my Asus M3N Laptop...

Mind

--
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\               http://student.dei.uc.pt/~marado
\ /                       marado@student.dei.uc.pt
 X   ASCII Ribbon Campaign
/ \  against HTML e-mail and Micro$oft attachments
==================================================

On Tue, 28 Oct 2003, Joachim Bremer wrote:

> Hi,
>
> on my laptop HP NX9005 2.4.23pre8 will panic on boot. Tracing
> down the differences between 2.4.23pre7 and pre8 a found that
> the problems is in patchset 1.1063.43.26. Backing out this patch
> lets the laptop boot again. Decode oops follows.
>
> Joachim
>
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> kernel BUG at slab.c:1130!
> invalid operand: 0000
> CPU:    0
> EIP:    0010:[<c012df25>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 000001f0   ebx: c1797270   ecx: 000001f0   edx: c02db798
> esi: c1797278   edi: c1797270   ebp: 000001f0   esp: c031da84
> ds: 0018   es: 0018   ss: 0018
> Process swapper (pid: 0, stackpage=c031d000)
> Stack: c031dac0 00000388 c01ca227 00200000 00000388 c1797270 c1797278 00000246
>        000001f0 c012e2a3 c1797270 000001f0 00000009 c031dad8 00000001 00000001
>        c01a5cde 00000060 000001f0 c01c8ebc 00000060 00000001 c02a78c1 c02a7884
> Call trace:    [<c01ca227>] [<c012e2a3>] [<c01a5cde>] [<c01c8ebc>] [<c01c8fad>]
>   [<c01c8c82>] [<c01ca153>] [<c01cc793>] [<c01c168f>] [<c01c0dec>] [<c01c0f3c>]
>   [<c01c8c36>] [<c01ca1d4>] [<c01ac6bf>] [<c01c1408>] [<c01c141d>] [<c01a8073>]
>   [<c01c1454>] [<c01c207a>] [<c01bcabc>] [<c01bc995>] [<c01bc71d>] [<c01ba804>]
>   [<c01bf28d>] [<c01d1b49>] [<c01d1bc5>] [<c01ad11d>] [<c01acf2e>] [<c01af467>]
>   [<c01a5e0f>] [<c01087c5>] [<c01a5e03>] [<c0108944>] [<c010ac98>] [<c01d591f>]
>   [<c01d5843>] [<c0105372>] [<c0105000>]
> Code: 0f 0b 6a 04 0e 4d 29 c0 89 c8 c7 44 24 0c 01 00 00 00 25 f0
>
>
> >>EIP; c012df25 <kmem_cache_grow+45/1f0>   <=====
>
> >>edx; c02db798 <cache_sizes+18/c0>
> >>esp; c031da84 <init_task_union+1a84/2000>
>
> Trace; c01ca227 <acpi_ut_status_exit+49/55>
> Trace; c012e2a3 <kmalloc+e3/110>
> Trace; c01a5cde <acpi_os_allocate+e/11>
> Trace; c01c8ebc <acpi_ut_callocate+75/e5>
> Trace; c01c8fad <acpi_ut_callocate_and_track+20/81>
> Trace; c01c8c82 <acpi_ut_acquire_from_cache+cf/e3>
> Trace; c01ca153 <acpi_ut_trace_ptr+2c/30>
> Trace; c01cc793 <acpi_ut_create_generic_state+c/15>
> Trace; c01c168f <acpi_ps_push_scope+3c/b0>
> Trace; c01c0dec <acpi_ps_parse_loop+4ce/a40>
> Trace; c01c0f3c <acpi_ps_parse_loop+61e/a40>
> Trace; c01c8c36 <acpi_ut_acquire_from_cache+83/e3>
> Trace; c01ca1d4 <acpi_ut_exit+1d/27>
> Trace; c01ac6bf <acpi_ds_push_walk_state+4a/51>
> Trace; c01c1408 <acpi_ps_parse_aml+aa/242>
> Trace; c01c141d <acpi_ps_parse_aml+bf/242>
> Trace; c01a8073 <acpi_ds_call_control_method+171/261>
> Trace; c01c1454 <acpi_ps_parse_aml+f6/242>
> Trace; c01c207a <acpi_psx_execute+226/2b0>
> Trace; c01bcabc <acpi_ns_execute_control_method+e5/104>
> Trace; c01bc995 <acpi_ns_evaluate_by_handle+df/121>
> Trace; c01bc71d <acpi_ns_evaluate_relative+141/192>
> Trace; c01ba804 <acpi_hw_low_level_read+10f/11c>
> Trace; c01bf28d <acpi_evaluate_object+179/282>
> Trace; c01d1b49 <acpi_ec_gpe_query+104/11b>
> Trace; c01d1bc5 <acpi_ec_gpe_handler+65/93>
> Trace; c01ad11d <acpi_ev_gpe_dispatch+7e/1bb>
> Trace; c01acf2e <acpi_ev_gpe_detect+119/16a>
> Trace; c01af467 <acpi_ev_sci_xrupt_handler+37/4d>
> Trace; c01a5e0f <acpi_irq+c/e>
> Trace; c01087c5 <handle_IRQ_event+45/70>
> Trace; c01a5e03 <acpi_irq+0/e>
> Trace; c0108944 <do_IRQ+64/a0>
> Trace; c010ac98 <call_do_IRQ+5/d>
> Trace; c01d591f <acpi_processor_idle+dc/1cf>
> Trace; c01d5843 <acpi_processor_idle+0/1cf>
> Trace; c0105372 <cpu_idle+42/60>
> Trace; c0105000 <_stext+0/0>
>
> Code;  c012df25 <kmem_cache_grow+45/1f0>
> 00000000 <_EIP>:
> Code;  c012df25 <kmem_cache_grow+45/1f0>   <=====
>    0:   0f 0b                     ud2a      <=====
> Code;  c012df27 <kmem_cache_grow+47/1f0>
>    2:   6a 04                     push   $0x4
> Code;  c012df29 <kmem_cache_grow+49/1f0>
>    4:   0e                        push   %cs
> Code;  c012df2a <kmem_cache_grow+4a/1f0>
>    5:   4d                        dec    %ebp
> Code;  c012df2b <kmem_cache_grow+4b/1f0>
>    6:   29 c0                     sub    %eax,%eax
> Code;  c012df2d <kmem_cache_grow+4d/1f0>
>    8:   89 c8                     mov    %ecx,%eax
> Code;  c012df2f <kmem_cache_grow+4f/1f0>
>    a:   c7 44 24 0c 01 00 00      movl   $0x1,0xc(%esp,1)
> Code;  c012df36 <kmem_cache_grow+56/1f0>
>   11:   00
> Code;  c012df37 <kmem_cache_grow+57/1f0>
>   12:   25 f0 00 00 00            and    $0xf0,%eax
>
>  <0>Kernel panic: Aiee, killing interrupt handler!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>