Bug 123091 - Kernel oops in kswapd0
Kernel oops in kswapd0
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-12 05:47 EDT by Jeremy Sanders
Modified: 2015-01-04 17:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-02 23:49:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Sanders 2004-05-12 05:47:23 EDT
Description of problem:

Our athlon test machine running kernel-2.6.5-1.327 oopsd. It possible
it's a hardware bug I suppose.

The oops is as follows:

May 12 04:02:03 xpc15 kernel: kjournald starting.  Commit interval 5
seconds
May 12 04:02:03 xpc15 kernel: EXT3 FS on hdb1, internal journal
May 12 04:02:03 xpc15 kernel: EXT3-fs: mounted filesystem with ordered
data mode.
May 12 04:03:20 xpc15 kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000004
May 12 04:03:20 xpc15 kernel:  printing eip:
May 12 04:03:20 xpc15 kernel: 021c701c
May 12 04:03:20 xpc15 kernel: *pde = 00000000
May 12 04:03:20 xpc15 kernel: Oops: 0000 [#1]
May 12 04:03:20 xpc15 kernel: CPU:    0
May 12 04:03:20 xpc15 kernel: EIP:    0060:[<021c701c>]    Not tainted
May 12 04:03:20 xpc15 kernel: EFLAGS: 00010093   (2.6.5-1.327)
May 12 04:03:20 xpc15 kernel: EIP is at __lookup+0x44/0xd6
May 12 04:03:20 xpc15 kernel: eax: 00000000   ebx: 00000000   ecx:
00000000   edx: 00000000
May 12 04:03:20 xpc15 kernel: esi: 00000001   edi: 00000000   ebp:
00000000   esp: 035fbd14
May 12 04:03:20 xpc15 kernel: ds: 007b   es: 007b   ss: 0068
May 12 04:03:20 xpc15 kernel: Process kswapd0 (pid: 8,
threadinfo=035fb000 task=035d0cd0)
May 12 04:03:20 xpc15 kernel: Stack: 00000000 00000002 00000000
00000000 035fbd9c 00000000 00000010 08fd8228
May 12 04:03:20 xpc15 kernel:        0000003f 021c70e7 00000010
035fbd48 035fbd9c 08fd8224 08fd8224 00000010
May 12 04:03:20 xpc15 kernel:        00000000 035fbd9c 0213c0e3
00000010 00000000 035fbd94 02331a60 00000000
May 12 04:03:20 xpc15 kernel: Call Trace:
May 12 04:03:20 xpc15 kernel:  [<021c70e7>]
radix_tree_gang_lookup+0x39/0x52
May 12 04:03:20 xpc15 kernel:  [<0213c0e3>] find_get_pages+0x8e/0x115
May 12 04:03:20 xpc15 kernel:  [<02145a92>] pagevec_lookup+0x17/0x1d
May 12 04:03:20 xpc15 kernel:  [<02145f27>]
invalidate_mapping_pages+0xb2/0xc5
May 12 04:03:20 xpc15 kernel:  [<02146b15>] shrink_cache+0x280/0x557
May 12 04:03:20 xpc15 kernel:  [<02179f2a>] prune_icache+0x1d4/0x39c
May 12 04:03:20 xpc15 kernel:  [<0217a0ff>] shrink_icache_memory+0xd/0x13
May 12 04:03:20 xpc15 kernel:  [<021461d3>] shrink_slab+0x103/0x150
May 12 04:03:20 xpc15 kernel:  [<021479c6>] balance_pgdat+0x153/0x216
May 12 04:03:20 xpc15 kernel:  [<02147b77>] kswapd+0xee/0xf0
May 12 04:03:20 xpc15 kernel:  [<0211bc33>]
autoremove_wake_function+0x0/0x28
May 12 04:03:20 xpc15 kernel:  [<0211bc33>]
autoremove_wake_function+0x0/0x28
May 12 04:03:20 xpc15 kernel:  [<02147a89>] kswapd+0x0/0xf0
May 12 04:03:20 xpc15 kernel:  [<021041d9>] kernel_thread_helper+0x5/0xb
May 12 04:03:20 xpc15 kernel:
May 12 04:03:20 xpc15 kernel: Code: 83 7c 82 04 00 75 1e b8 01 00 00
00 89 e9 d3 e0 89 c2 f7 da
May 12 04:03:49 xpc15 kernel:  mm/vmscan.c:412:
spin_lock(fs/inode.c:08fd8234) already locked by mm/filemap.c/543


It happened after mounting a backup partition during a cron job
(/dev/hdb1). However df reports hdb1 as having more space available
than fdisk shows space for:


[root@xpc15 root]# /sbin/fdisk /dev/hdb

The number of cylinders for this disk is set to 9729.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/hdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1   *           1         319     2562336   83  Linux
/dev/hdb2             320         574     2048287+  82  Linux swap
/dev/hdb3             575        9345    70453057+  83  Linux

Command (m for help): q

[root@xpc15 root]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1              6253848   3147808   2788360  54% /
none                    258352         0    258352   0% /dev/shm
/dev/hda3             65606920     32828  65574092   1% /xpc15_data1
xalph3:/soft3
                     118733148  49314268  69418880  42% /data/soft3
/dev/hdb1              6253848   3147808   2788360  54% /root_backup
xpc5:/xpc5_data1/home/jss
                     108317728  77197316  31120412  72% /home/jss
xalph3:/soft3/caldb
                     118733148  49314268  69418880  42% /data/caldb

ksymoops says:

>>EIP; 021c701c <radix_tree_tag_clear+106/198>   <=====

Trace; 021c70e7 <radix_tree_gang_lookup+39/160>
Trace; 0213c0e3 <find_or_create_page+fe/2ae>
Trace; 02145a92 <__pagevec_lru_add+3e5/5cd>
Trace; 02145f27 <truncate_inode_pages+2ad/2c0>
Trace; 02146b15 <remove_shrinker+a9e/1bed>
Trace; 02179f2a <__invalidate_device+247/4c0>
Trace; 0217a0ff <__invalidate_device+41c/4c0>
Trace; 021461d3 <remove_shrinker+15c/1bed>
Trace; 021479c6 <remove_shrinker+194f/1bed>
Trace; 02147b77 <remove_shrinker+1b00/1bed>
Trace; 0211bc33 <autoremove_wake_function+0/a6e>
Trace; 0211bc33 <autoremove_wake_function+0/a6e>
Trace; 02147a89 <remove_shrinker+1a12/1bed>
Trace; 021041d9 <enable_hlt+1c8/1ce>

Code;  021c701c <radix_tree_tag_clear+106/198>
00000000 <_EIP>:
Code;  021c701c <radix_tree_tag_clear+106/198>   <=====
   0:   83 7c 82 04 00            cmpl   $0x0,0x4(%edx,%eax,4)   <=====
Code;  021c7021 <radix_tree_tag_clear+10b/198>
   5:   75 1e                     jne    25 <_EIP+0x25>
Code;  021c7023 <radix_tree_tag_clear+10d/198>
   7:   b8 01 00 00 00            mov    $0x1,%eax
Code;  021c7028 <radix_tree_tag_clear+112/198>
   c:   89 e9                     mov    %ebp,%ecx
Code;  021c702a <radix_tree_tag_clear+114/198>
   e:   d3 e0                     shl    %cl,%eax
Code;  021c702c <radix_tree_tag_clear+116/198>
  10:   89 c2                     mov    %eax,%edx
Code;  021c702e <radix_tree_tag_clear+118/198>
  12:   f7 da                     neg    %edx




Version-Release number of selected component (if applicable):

kernel-2.6.5-1.327

How reproducible:

Unsure

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jeremy Sanders 2004-05-12 05:53:24 EDT
I should add, after rebooting /dev/hdb1 went back to its normal size:

[root@xpc15 root]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1              6253848   3138700   2797468  53% /
none                    258352         0    258352   0% /dev/shm
/dev/hda3             65606920     32828  65574092   1% /xpc15_data1
xalph3:/soft3
                     118733148  49314212  69418936  42% /data/soft3
/dev/hdb1              2522048   2505932         0 100% /root_backup

For some reason the size in the kernel got corrupted and became the
same size as /dev/hda1
Comment 2 Dave Jones 2004-05-12 10:32:42 EDT
various VM bits have changed dramatically since -327
Can you try and repeat with -358 ?
Comment 3 Jeremy Sanders 2004-05-12 13:01:51 EDT
Okay, we've updated to -358. Unfortunately the problem may not be
easily reproducable as it didn't happen for the first couple of backups.
Comment 4 Dave Jones 2004-11-02 23:49:41 EST
assuming this got fixed. please reopen if it reoccurs.

Note You need to log in before you can comment on or make changes to this bug.