lkml.org 
[lkml]   [2003]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.4.22-pre10 ACPI kennel oops
    Brown, Len wrote:

    >Was ACPI included in your 2.4.21 kernel? If no, then 2.4.22-pre10 may
    >be the 1st time that Linux ACPI has examined the tables on this system.
    >
    >I'm not familiar with "woodruf" -- do it have a part number?
    >First thing to do is to locate the latest BIOS for the board, and see if
    >this is something that has already been fixed there.
    >
    >If the latest BIOS doesn't do it, then filing a bug under componenet
    >ACPI will be the best way to get it fixed w/o having it fall through the
    >

    Still fails. A bug with quad, or the ACPI project?

    >cracks.
    >
    >Thanks,
    >-Len
    >
    >
    >
    >
    >
    >>-----Original Message-----
    >>From: Samuel Flory [mailto:sflory@rackable.com]
    >>Sent: Tuesday, August 05, 2003 5:29 PM
    >>To: linux-kernel@vger.kernel.org
    >>Subject: 2.4.22-pre10 ACPI kennel oops
    >>
    >>
    >> I'm getting a kernel oops on the intel woodruf P4 motherboard under
    >>2.4.22pre10. This config worked fine under 2.4.21. The output of
    >>ksymoops is attached, and the raw oops is attached.
    >>
    >>ksymoops 2.4.4 on i686 2.4.20-8smp. Options used
    >> -V (default)
    >> -K (specified)
    >> -L (specified)
    >> -O (specified)
    >> -m /boot/System.map-2.4.22-pre10 (specified)
    >>
    >>ACPI: LAPIC_NMI (acpi_id[0x01] polarity[0x0] trigger[0x0] lint[0x1])
    >>ACPI: LAPIC_NMI (acpi_id[0x02] polarity[0x0] trigger[0x0] lint[0x1])
    >>cpu: 0, clocks: 1328876, slice: 664438
    >>Unable to handle kernel paging request at virtual address f8803000
    >>c022d588
    >>*pde = 00000000
    >>Oops: 0000
    >>CPU: 0
    >>EIP: 0010:[<c022d588>] Not tainted
    >>Using defaults from ksymoops -t elf32-i386 -a i386
    >>EFLAGS: 00010206
    >>eax: 00000000 ebx: 00000000 ecx: 00000001 edx: c1c13ec0
    >>esi: f8802ffd edi: c1c13ee0 ebp: c1c13ec0 esp: c1c13e64
    >>ds: 0018 es: 0018 ss: 0018
    >>Process swapper (pid: 1, stackpage=c1c13000)
    >>Stack: c1c13f1c c1c13f1c c1c13e84 c022d015 c1c13ec0 f8802fdd 00000024
    >>f8802fdd
    >> 00000008 c0492d37 c0492d24 00200000 c1c13eb0 c1c13ec0 c1c13f2c
    >>c1c13eb0
    >> c022c984 c1c13f1c c1c13ec0 00000008 c0492cab c0492ca2 c1c13f0c
    >>54445353
    >>Call Trace: [<c022d015>] [<c022c984>] [<c022cb68>] [<c022cd89>]
    >>[<c022e124>]
    >> [<c022e1fa>] [<c0105000>] [<c010508b>] [<c0105000>] [<c01075ae>]
    >>[<c0105060>]
    >>Code: f3 a5 e9 5c ff ff ff c1 e9 02 89 d7 f3 a5 a4 e9 4f ff ff ff
    >>
    >> >>EIP; c022d588 <__constant_memcpy+bd/f5> <=====
    >>Trace; c022d015 <acpi_tb_get_table_header+11a/12d>
    >>Trace; c022c984 <acpi_tb_get_primary_table+64/d2>
    >>Trace; c022cb68 <acpi_tb_get_required_tables+45/2b4>
    >>Trace; c022cd89 <acpi_tb_get_required_tables+266/2b4>
    >>Trace; c022e124 <acpi_load_tables+34/188>
    >>Trace; c022e1fa <acpi_load_tables+10a/188>
    >>Trace; c0105000 <_stext+0/0>
    >>Trace; c010508b <init+2b/190>
    >>Trace; c0105000 <_stext+0/0>
    >>Trace; c01075ae <arch_kernel_thread+2e/40>
    >>Trace; c0105060 <init+0/190>
    >>Code; c022d588 <__constant_memcpy+bd/f5>
    >>00000000 <_EIP>:
    >>Code; c022d588 <__constant_memcpy+bd/f5> <=====
    >> 0: f3 a5 repz movsl
    >>%ds:(%esi),%es:(%edi) <=====
    >>Code; c022d58a <__constant_memcpy+bf/f5>
    >> 2: e9 5c ff ff ff jmp ffffff63 <_EIP+0xffffff63>
    >>Code; c022d58f <__constant_memcpy+c4/f5>
    >> 7: c1 e9 02 shr $0x2,%ecx
    >>Code; c022d592 <__constant_memcpy+c7/f5>
    >> a: 89 d7 mov %edx,%edi
    >>Code; c022d594 <__constant_memcpy+c9/f5>
    >> c: f3 a5 repz movsl %ds:(%esi),%es:(%edi)
    >>Code; c022d596 <__constant_memcpy+cb/f5>
    >> e: a4 movsb %ds:(%esi),%es:(%edi)
    >>Code; c022d597 <__constant_memcpy+cc/f5>
    >> f: e9 4f ff ff ff jmp ffffff63 <_EIP+0xffffff63>
    >>
    >>
    >>--
    >>Once you have their hardware. Never give it back.
    >>(The First Rule of Hardware Acquisition)
    >>Sam Flory <sflory@rackable.com>
    >>
    >>
    >>
    >
    >
    >


    --
    Once you have their hardware. Never give it back.
    (The First Rule of Hardware Acquisition)
    Sam Flory <sflory@rackable.com>


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:47    [W:5.261 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site