* 2.4.23pre8 - ACPI Kernel Panic on boot @ 2003-10-28 13:32 Joachim Bremer 2003-10-28 15:49 ` Marcelo Tosatti 2003-10-28 17:40 ` 2.4.23pre8 - ACPI Kernel Panic on boot Marcos D. Marado Torres 0 siblings, 2 replies; 13+ messages in thread From: Joachim Bremer @ 2003-10-28 13:32 UTC (permalink / raw) To: linux-kernel 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! ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.4.23pre8 - ACPI Kernel Panic on boot 2003-10-28 13:32 2.4.23pre8 - ACPI Kernel Panic on boot Joachim Bremer @ 2003-10-28 15:49 ` Marcelo Tosatti 2003-10-28 22:42 ` RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] Kristofer T. Karas 2003-10-28 17:40 ` 2.4.23pre8 - ACPI Kernel Panic on boot Marcos D. Marado Torres 1 sibling, 1 reply; 13+ messages in thread From: Marcelo Tosatti @ 2003-10-28 15:49 UTC (permalink / raw) To: Joachim Bremer; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-28 15:49 ` Marcelo Tosatti @ 2003-10-28 22:42 ` Kristofer T. Karas 2003-10-28 23:05 ` Javier Villavicencio 0 siblings, 1 reply; 13+ messages in thread From: Kristofer T. Karas @ 2003-10-28 22:42 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-28 22:42 ` RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] Kristofer T. Karas @ 2003-10-28 23:05 ` Javier Villavicencio 2003-10-29 16:51 ` Marcelo Tosatti 0 siblings, 1 reply; 13+ messages in thread From: Javier Villavicencio @ 2003-10-28 23:05 UTC (permalink / raw) To: linux-kernel; +Cc: Marcelo Tosatti, Kristofer T. Karas 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.- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-28 23:05 ` Javier Villavicencio @ 2003-10-29 16:51 ` Marcelo Tosatti 2003-10-29 20:06 ` Kristofer T. Karas 0 siblings, 1 reply; 13+ messages in thread From: Marcelo Tosatti @ 2003-10-29 16:51 UTC (permalink / raw) To: Javier Villavicencio; +Cc: linux-kernel, Marcelo Tosatti, Kristofer T. Karas 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? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-29 16:51 ` Marcelo Tosatti @ 2003-10-29 20:06 ` Kristofer T. Karas 2003-10-29 21:03 ` Kronos 0 siblings, 1 reply; 13+ messages in thread From: Kristofer T. Karas @ 2003-10-29 20:06 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: Javier Villavicencio, linux-kernel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-29 20:06 ` Kristofer T. Karas @ 2003-10-29 21:03 ` Kronos 2003-10-30 5:20 ` Kristofer T. Karas 0 siblings, 1 reply; 13+ messages in thread From: Kronos @ 2003-10-29 21:03 UTC (permalink / raw) To: linux-kernel; +Cc: Kristofer T. Karas, Javier Villavicencio > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-29 21:03 ` Kronos @ 2003-10-30 5:20 ` Kristofer T. Karas 2003-10-31 7:59 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 13+ messages in thread From: Kristofer T. Karas @ 2003-10-30 5:20 UTC (permalink / raw) To: kronos; +Cc: Linux Kernel Mailing List, Javier Villavicencio 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-30 5:20 ` Kristofer T. Karas @ 2003-10-31 7:59 ` Benjamin Herrenschmidt 2003-10-31 19:16 ` Kristofer T. Karas 2003-11-01 6:22 ` Kristofer T. Karas 0 siblings, 2 replies; 13+ messages in thread From: Benjamin Herrenschmidt @ 2003-10-31 7:59 UTC (permalink / raw) To: Kristofer T. Karas Cc: Kronos, Linux Kernel Mailing List, Javier Villavicencio > 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-31 7:59 ` Benjamin Herrenschmidt @ 2003-10-31 19:16 ` Kristofer T. Karas 2003-10-31 22:55 ` Benjamin Herrenschmidt 2003-11-01 6:22 ` Kristofer T. Karas 1 sibling, 1 reply; 13+ messages in thread From: Kristofer T. Karas @ 2003-10-31 19:16 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Kronos, Linux Kernel Mailing List, Javier Villavicencio 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-31 19:16 ` Kristofer T. Karas @ 2003-10-31 22:55 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 13+ messages in thread From: Benjamin Herrenschmidt @ 2003-10-31 22:55 UTC (permalink / raw) To: Kristofer T. Karas Cc: Kronos, Linux Kernel Mailing List, Javier Villavicencio 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] 2003-10-31 7:59 ` Benjamin Herrenschmidt 2003-10-31 19:16 ` Kristofer T. Karas @ 2003-11-01 6:22 ` Kristofer T. Karas 1 sibling, 0 replies; 13+ messages in thread From: Kristofer T. Karas @ 2003-11-01 6:22 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Kronos, Linux Kernel Mailing List, Javier Villavicencio 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.4.23pre8 - ACPI Kernel Panic on boot 2003-10-28 13:32 2.4.23pre8 - ACPI Kernel Panic on boot Joachim Bremer 2003-10-28 15:49 ` Marcelo Tosatti @ 2003-10-28 17:40 ` Marcos D. Marado Torres 1 sibling, 0 replies; 13+ messages in thread From: Marcos D. Marado Torres @ 2003-10-28 17:40 UTC (permalink / raw) To: Joachim Bremer; +Cc: linux-kernel 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/ > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-11-01 6:23 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-28 13:32 2.4.23pre8 - ACPI Kernel Panic on boot Joachim Bremer 2003-10-28 15:49 ` Marcelo Tosatti 2003-10-28 22:42 ` RadeonFB [Re: 2.4.23pre8 - ACPI Kernel Panic on boot] Kristofer T. Karas 2003-10-28 23:05 ` Javier Villavicencio 2003-10-29 16:51 ` Marcelo Tosatti 2003-10-29 20:06 ` Kristofer T. Karas 2003-10-29 21:03 ` Kronos 2003-10-30 5:20 ` Kristofer T. Karas 2003-10-31 7:59 ` Benjamin Herrenschmidt 2003-10-31 19:16 ` Kristofer T. Karas 2003-10-31 22:55 ` Benjamin Herrenschmidt 2003-11-01 6:22 ` Kristofer T. Karas 2003-10-28 17:40 ` 2.4.23pre8 - ACPI Kernel Panic on boot Marcos D. Marado Torres
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).