lkml.org 
[lkml]   [1998]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject2.1.112: page fault from irq handler
From
Date
Hello,

yesterday our server machine crashed because of a 'page fault from irq
handler'. The kernel wrote a rather strange oops message to the console
and "panic-ed", because the page fault happened in the context of the
idle process. I have copied the oops message to a piece of paper and
here it is:

page fault from irq handler: 0
CPU: 3
EIP: 0010:[<c012aeb0>]
EFLAGS: ???
eax: dc050845 ebx: c957ef20 ecx: c957ef20 edx: 0008761b
esi: c001be94 edi: 00000002 ebp: c001be00 esp: c0107e9c
ds: ??? es: ??? fs: ??? gs: ??? ss: ???
Process swapper (pid: 0, process nr: 0, stackpage=c0107000)
Stack: c0129d70 c957ef20 00000001 c957ef20 c01d32d5 c957ef20 00000001 00000000
c001be00 c001be00 00000000 c01d39e9 c001be00 00000001 00000002 00000000
c001be00 00000000 00000000 c01cb8b5 00000001 c0018c00 00000001 00000002
Call Trace: [<c0129d70>] [<c01d32d5>] [<c01d39e9>] [<c01cb8b5>] [<c01cd88c>] [<c0107f9c>] [<c01e3055>] [<c010b70d>] [<c0107f9c>] [<c0110237>] [<c0107f9c>] [<c0107f9c>] [<c0106000>] [<c0106000>] [<c0107f94>] [<c010bb53>] [<c0107f9c>] [<c0109ec8>] [<c0106000>] [<c0106000>] [<c0106000>] [<c0100018>] [<c0108266>] [<c0107fe4>] [<c0106000>] [<c01001b5>]
Code:

>>EIP: c012aeb0 <generic_readpage+30/8c>
Trace: c0129d70 <end_buffer_io_sync+10/2c>
Trace: c01d32d5 <end_scsi_request+79/138>
Trace: c01d39e9 <rw_intr+39d/6b4>
Trace: c01cb8b5 <scsi_delete_timer+19/54>
Trace: c01cd88c <scsi_old_done+548/554>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c01e3055 <ncr53c8xx_intr+89/a0>
Trace: c010b70d <handle_IRQ_event+35/58>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0110237 <do_edge_ioapic_IRQ+93/100>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0107f94 <this_must_match_init_task+1f94/2000>
Trace: c010bb53 <do_IRQ+37/54>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0109ec8 <ret_from_intr>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0107f9c <this_must_match_init_task+1f9c/2000>
Trace: c0100018 <startup_32+18/a4>
Trace: c0108266 <cpu_idle+3a/bc>
Trace: c0107fe4 <this_must_match_init_task+1fe4/2000>
Trace: c0107fe4 <this_must_match_init_task+1fe4/2000>
Trace: c01001b5 <L6>

The code associated with eip is:

0xc012aead <generic_readpage+45>: movl 0x5c(%ebp),%eax
0xc012aeb0 <generic_readpage+48>: movzbl 0x8(%eax),%ecx
0xc012aeb4 <generic_readpage+52>: movl $0x1000,%edi
0xc012aeb9 <generic_readpage+57>: shrl %cl,%edi

/home/jw5/tmp/linux/linux/fs/buffer.c:1570
1e75: 8b 45 5c movl 0x5c(%ebp),%eax
1e78: 0f b6 48 08 movzbl 0x8(%eax),%ecx
1e7c: bf 00 10 00 00 movl $0x1000,%edi
1e81: d3 ef shrl %cl,%edi

buffer.c:
i = PAGE_SIZE >> inode->i_sb->s_blocksize_bits;

Somehow i_sb seems to point to a bogus address leading to a page fault
(ebp contains the value of inode).

The strange thing is that the stack trace looks like a normal
interrupt handling sequence but there is no call from
end_buffer_io_sync to generic_read_page.

So it seems like somehow the interrupt handling trashed the stack of
the idle process. On the other hand: Why is the idle process calling
generic_readpage?

There was another oops before the machine crashed but unfortunately
the message 'scrolled away' and the log file contains only two lines
of it:

Aug 6 03:31:22 os kernel: Oops: 0000
Aug 6 03:31:22 os kernel: CPU: 2

The kernel is a stock 2.1.112 (with the lock_kernel patch applied).
The machine is a AMI Goliath equipped with 4 PPro and 256MB memory.
/proc/interrupts reports:
3: IO-APIC-edge NE2000
7: IO-APIC-edge Digital DS21140 Tulip
9: IO-APIC-edge ncr53c8xx
10: IO-APIC-edge ncr53c8xx


If I can provide any additional information feel free to ask me.

Jean

PS: the config file:
grep '^C' .config
CONFIG_M686=y
CONFIG_MODULES=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_BIOS=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_STRIPED=y
CONFIG_MD_BOOT=y
CONFIG_BLK_DEV_RAM=y
CONFIG_PARIDE_PARPORT=y
CONFIG_PACKET=y
CONFIG_NET_ALIAS=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ALIAS=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_RARP=y
CONFIG_IP_NOSR=y
CONFIG_SKB_LARGE=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_BUSLOGIC=y
CONFIG_SCSI_OMIT_FLASHPOINT=y
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=4
CONFIG_SCSI_NCR53C8XX_SYNC=5
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_ISA=y
CONFIG_NE2000=y
CONFIG_NET_EISA=y
CONFIG_DE4X5=y
CONFIG_DEC_ELCP=y
CONFIG_MINIX_FS=y
CONFIG_EXT2_FS=y
CONFIG_ISO9660_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_PROC_FS=y
CONFIG_NFS_FS=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_SMB_FS=y
CONFIG_AUTOFS_FS=y
CONFIG_NLS=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_VGA_CONSOLE=y
CONFIG_MAGIC_SYSRQ=y

--
I get up each morning, gather my wits.
Pick up the paper, read the obits.
if I'm not there I know I'm not dead.
So I eat a good breakfast and go back to bed. Peete Seeger

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

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