Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
--- Hugh Dickins <[EMAIL PROTECTED]> wrote: > > The app which is kernel panicing is the only > > application which makes use of the fusedriver. I'd > > like to confirm my suspicions on the driver. Do > you > > have any suggestions on how I could trace the > kernel > > panic to that specific driver? > > Indeed, yes, get its source and look to see what > it's doing > with PageReserved - or mail it to me privately and > I'll take > a look. But my Google for fusedriver didn't show > anything, > and clearly it has nothing to do with the FUSE > filesystems. > > Hugh > Sorry for the late reply, I was on vacation with the family for a few days. fusedriver is a driver for a customized fpga pci card used in our systems. I'm not sure how open the manufacturer will be in sending me the source for the drivers. I'll contact them though to get their input, specifically on their use of PageReserved. Thanks, Pat Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
--- Hugh Dickins [EMAIL PROTECTED] wrote: The app which is kernel panicing is the only application which makes use of the fusedriver. I'd like to confirm my suspicions on the driver. Do you have any suggestions on how I could trace the kernel panic to that specific driver? Indeed, yes, get its source and look to see what it's doing with PageReserved - or mail it to me privately and I'll take a look. But my Google for fusedriver didn't show anything, and clearly it has nothing to do with the FUSE filesystems. Hugh Sorry for the late reply, I was on vacation with the family for a few days. fusedriver is a driver for a customized fpga pci card used in our systems. I'm not sure how open the manufacturer will be in sending me the source for the drivers. I'll contact them though to get their input, specifically on their use of PageReserved. Thanks, Pat Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
Pat wrote: I'm running kernel 2.6.9-22.ELsmp on dual Xeon servers. I've received kernel panics occasionally in the past, but they are more frequent now as the load on the system has increased. Below is a capture of the kernel panic. If anything below screams it's coming from a certain source (defective RAM? Bad application or device driver?), please let me know as I'm pulling what little hair I have left out on this one. Suggestions on what to try would be greatly appreciated. Thanks! First try updating to the latest RHEL update kernel, that one's out of date. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
Pat wrote: I'm running kernel 2.6.9-22.ELsmp on dual Xeon servers. I've received kernel panics occasionally in the past, but they are more frequent now as the load on the system has increased. Below is a capture of the kernel panic. If anything below screams it's coming from a certain source (defective RAM? Bad application or device driver?), please let me know as I'm pulling what little hair I have left out on this one. Suggestions on what to try would be greatly appreciated. Thanks! First try updating to the latest RHEL update kernel, that one's out of date. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
On Thu, 5 Apr 2007, Pat wrote: > Yes, there is a specific app which seems to be related > to the kernel panic. > > We use a few third party drivers on the system, so my > initial suspicions were on: 3w_9xxx(U) which is the > RAID card driver and fusedriver(U) which is a hardware > PCI card driver. > > The app which is kernel panicing is the only > application which makes use of the fusedriver. I'd > like to confirm my suspicions on the driver. Do you > have any suggestions on how I could trace the kernel > panic to that specific driver? Indeed, yes, get its source and look to see what it's doing with PageReserved - or mail it to me privately and I'll take a look. But my Google for fusedriver didn't show anything, and clearly it has nothing to do with the FUSE filesystems. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
--- Hugh Dickins <[EMAIL PROTECTED]> wrote: > > I'm running kernel 2.6.9-22.ELsmp on dual Xeon > > You'd do better to ask Red Hat support than here. Thanks for the suggestion. I'll give them a shot too. > Are the initial BUGs usually of that kind - > rmap.c:434? Yes. From the ones I've recorded so far, they all begin with BUGs on rmap.c:434. > Do check your RAM (memtest86 overnight), maybe that I ran memtest86+ (default test) overnight on the system and it's still going strong, so I hope that indicates the RAM is okay. > PG_reserved bit is spurious. But if rmap.c:434 is > what's happening to you again and again, I'd wonder > if a driver has been allocating a high-order page, > marking the constituent pages as reserved, later > clearing reserved from the first constituent page, > then freeing the high-order page while leaving other > reserved bits behind - I believe that could sneak a > PageReserved page back into the 2.6.9 allocator. > > If it were a particular application triggering this, > it'd still be a kernel bug to allow it to happen. Yes, there is a specific app which seems to be related to the kernel panic. We use a few third party drivers on the system, so my initial suspicions were on: 3w_9xxx(U) which is the RAID card driver and fusedriver(U) which is a hardware PCI card driver. The app which is kernel panicing is the only application which makes use of the fusedriver. I'd like to confirm my suspicions on the driver. Do you have any suggestions on how I could trace the kernel panic to that specific driver? Thanks again for your input Hugh. Pat > > [ cut here ] > > kernel BUG at mm/rmap.c:434! > > invalid operand: [#1] > > SMP > > Modules linked in: fusedriver(U) md5 ipv6 > parport_pc > > lp parport autofs4 i2c_dev i2c_core sunrpc > > dm_multipath button battery ac uhci_hcd ehci_hcd > e1000 > > floppy dm_snapshot dm_zero dm_mirror ext3 jbd > dm_mod > > 3w_9xxx(U) sd_mod scsi_mod > > CPU:5 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010202 (2.6.9-22.ELsmp) > > EIP is at page_add_anon_rmap+0xe/0x66 > > eax: 4964 ebx: c1800040 ecx: 090a100c > edx: > > e5b5a544 > > esi: d1837e8c edi: fff25508 ebp: c1800040 > esp: > > cf12ae40 > > ds: 007b es: 007b ss: 0068 > > Process check-enqueued- (pid: 17602, > > threadinfo=cf12a000 task=f57577b0) > > Stack: 40002067 8000 c014d034 fff29000 > 40002025 > > 8000 0163 e5b5a544 > >f35b9080 fff25508 fff25508 > 090a100c > > c014d0e2 cc5a2240 0001 > >090a100c > > > 8000 > > Call Trace: > > [] do_anonymous_page+0x19c/0x1db > > [] do_no_page+0x6f/0x2f9 > > [] handle_mm_fault+0xbd/0x175 > > [] do_page_fault+0x1ae/0x5c6 > > [] vma_adjust+0x286/0x2d6 > > [] vma_merge+0xe1/0x165 > > [] finish_task_switch+0x30/0x66 > > [] schedule+0x844/0x87a > > [] do_page_fault+0x0/0x5c6 > > [] error_code+0x2f/0x38 > > Code: 83 7b 10 00 74 0b 89 ca 89 d8 e8 fb fe ff ff > 01 > > c6 89 d8 e8 ac df fe ff 5b 89 f0 5e c3 56 53 89 c3 > 8b > > 00 8b 72 44 f6 c4 08 74 08 <0f> 0b b2 01 ce 52 2e > c0 > > 85 f6 75 08 0f 0b b3 01 ce 52 2e c0 8b > 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
On Wed, 4 Apr 2007, Pat wrote: > I'm running kernel 2.6.9-22.ELsmp on dual Xeon You'd do better to ask Red Hat support than here. > servers. I've received kernel panics occasionally in > the past, but they are more frequent now as the load > on the system has increased. Below is a capture of the > kernel panic. Are the initial BUGs usually of that kind - rmap.c:434? (The subsequent scheduling-while-atomics and highmem.c:42s are not interesting, just consequences of the original BUG in an untidy place.) > If anything below screams it's coming from a certain > source (defective RAM? Bad application or device > driver?), please let me know as I'm pulling what > little hair I have left out on this one. Suggestions > on what to try would be greatly appreciated. Thanks! I've never seen a BUG in page_add_anon_rmap before: there's one in page_remove_rmap which comes up from time to time, but this is different. The page allocator has just dished out a PageReserved page (at physical 1G+8k: interesting that it's so close to 1G), which should never happen - but there was less checking for that in 2.6.9-based kernels. Do check your RAM (memtest86 overnight), maybe that PG_reserved bit is spurious. But if rmap.c:434 is what's happening to you again and again, I'd wonder if a driver has been allocating a high-order page, marking the constituent pages as reserved, later clearing reserved from the first constituent page, then freeing the high-order page while leaving other reserved bits behind - I believe that could sneak a PageReserved page back into the 2.6.9 allocator. If it were a particular application triggering this, it'd still be a kernel bug to allow it to happen. Hugh > [ cut here ] > kernel BUG at mm/rmap.c:434! > invalid operand: [#1] > SMP > Modules linked in: fusedriver(U) md5 ipv6 parport_pc > lp parport autofs4 i2c_dev i2c_core sunrpc > dm_multipath button battery ac uhci_hcd ehci_hcd e1000 > floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod > 3w_9xxx(U) sd_mod scsi_mod > CPU:5 > EIP:0060:[]Not tainted VLI > EFLAGS: 00010202 (2.6.9-22.ELsmp) > EIP is at page_add_anon_rmap+0xe/0x66 > eax: 4964 ebx: c1800040 ecx: 090a100c edx: > e5b5a544 > esi: d1837e8c edi: fff25508 ebp: c1800040 esp: > cf12ae40 > ds: 007b es: 007b ss: 0068 > Process check-enqueued- (pid: 17602, > threadinfo=cf12a000 task=f57577b0) > Stack: 40002067 8000 c014d034 fff29000 40002025 > 8000 0163 e5b5a544 >f35b9080 fff25508 fff25508 090a100c > c014d0e2 cc5a2240 0001 >090a100c > 8000 > Call Trace: > [] do_anonymous_page+0x19c/0x1db > [] do_no_page+0x6f/0x2f9 > [] handle_mm_fault+0xbd/0x175 > [] do_page_fault+0x1ae/0x5c6 > [] vma_adjust+0x286/0x2d6 > [] vma_merge+0xe1/0x165 > [] finish_task_switch+0x30/0x66 > [] schedule+0x844/0x87a > [] do_page_fault+0x0/0x5c6 > [] error_code+0x2f/0x38 > Code: 83 7b 10 00 74 0b 89 ca 89 d8 e8 fb fe ff ff 01 > c6 89 d8 e8 ac df fe ff 5b 89 f0 5e c3 56 53 89 c3 8b > 00 8b 72 44 f6 c4 08 74 08 <0f> 0b b2 01 ce 52 2e c0 > 85 f6 75 08 0f 0b b3 01 ce 52 2e c0 8b - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
On Thu, 5 Apr 2007, Pat wrote: Yes, there is a specific app which seems to be related to the kernel panic. We use a few third party drivers on the system, so my initial suspicions were on: 3w_9xxx(U) which is the RAID card driver and fusedriver(U) which is a hardware PCI card driver. The app which is kernel panicing is the only application which makes use of the fusedriver. I'd like to confirm my suspicions on the driver. Do you have any suggestions on how I could trace the kernel panic to that specific driver? Indeed, yes, get its source and look to see what it's doing with PageReserved - or mail it to me privately and I'll take a look. But my Google for fusedriver didn't show anything, and clearly it has nothing to do with the FUSE filesystems. Hugh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
On Wed, 4 Apr 2007, Pat wrote: I'm running kernel 2.6.9-22.ELsmp on dual Xeon You'd do better to ask Red Hat support than here. servers. I've received kernel panics occasionally in the past, but they are more frequent now as the load on the system has increased. Below is a capture of the kernel panic. Are the initial BUGs usually of that kind - rmap.c:434? (The subsequent scheduling-while-atomics and highmem.c:42s are not interesting, just consequences of the original BUG in an untidy place.) If anything below screams it's coming from a certain source (defective RAM? Bad application or device driver?), please let me know as I'm pulling what little hair I have left out on this one. Suggestions on what to try would be greatly appreciated. Thanks! I've never seen a BUG in page_add_anon_rmap before: there's one in page_remove_rmap which comes up from time to time, but this is different. The page allocator has just dished out a PageReserved page (at physical 1G+8k: interesting that it's so close to 1G), which should never happen - but there was less checking for that in 2.6.9-based kernels. Do check your RAM (memtest86 overnight), maybe that PG_reserved bit is spurious. But if rmap.c:434 is what's happening to you again and again, I'd wonder if a driver has been allocating a high-order page, marking the constituent pages as reserved, later clearing reserved from the first constituent page, then freeing the high-order page while leaving other reserved bits behind - I believe that could sneak a PageReserved page back into the 2.6.9 allocator. If it were a particular application triggering this, it'd still be a kernel bug to allow it to happen. Hugh [ cut here ] kernel BUG at mm/rmap.c:434! invalid operand: [#1] SMP Modules linked in: fusedriver(U) md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc dm_multipath button battery ac uhci_hcd ehci_hcd e1000 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod 3w_9xxx(U) sd_mod scsi_mod CPU:5 EIP:0060:[c01518c6]Not tainted VLI EFLAGS: 00010202 (2.6.9-22.ELsmp) EIP is at page_add_anon_rmap+0xe/0x66 eax: 4964 ebx: c1800040 ecx: 090a100c edx: e5b5a544 esi: d1837e8c edi: fff25508 ebp: c1800040 esp: cf12ae40 ds: 007b es: 007b ss: 0068 Process check-enqueued- (pid: 17602, threadinfo=cf12a000 task=f57577b0) Stack: 40002067 8000 c014d034 fff29000 40002025 8000 0163 e5b5a544 f35b9080 fff25508 fff25508 090a100c c014d0e2 cc5a2240 0001 090a100c 8000 Call Trace: [c014d034] do_anonymous_page+0x19c/0x1db [c014d0e2] do_no_page+0x6f/0x2f9 [c014d503] handle_mm_fault+0xbd/0x175 [c011addb] do_page_fault+0x1ae/0x5c6 [c014e58e] vma_adjust+0x286/0x2d6 [c014e762] vma_merge+0xe1/0x165 [c011d3d5] finish_task_switch+0x30/0x66 [c02cf368] schedule+0x844/0x87a [c011ac2d] do_page_fault+0x0/0x5c6 [c02d1bab] error_code+0x2f/0x38 Code: 83 7b 10 00 74 0b 89 ca 89 d8 e8 fb fe ff ff 01 c6 89 d8 e8 ac df fe ff 5b 89 f0 5e c3 56 53 89 c3 8b 00 8b 72 44 f6 c4 08 74 08 0f 0b b2 01 ce 52 2e c0 85 f6 75 08 0f 0b b3 01 ce 52 2e c0 8b - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
--- Hugh Dickins [EMAIL PROTECTED] wrote: I'm running kernel 2.6.9-22.ELsmp on dual Xeon You'd do better to ask Red Hat support than here. Thanks for the suggestion. I'll give them a shot too. Are the initial BUGs usually of that kind - rmap.c:434? Yes. From the ones I've recorded so far, they all begin with BUGs on rmap.c:434. Do check your RAM (memtest86 overnight), maybe that I ran memtest86+ (default test) overnight on the system and it's still going strong, so I hope that indicates the RAM is okay. PG_reserved bit is spurious. But if rmap.c:434 is what's happening to you again and again, I'd wonder if a driver has been allocating a high-order page, marking the constituent pages as reserved, later clearing reserved from the first constituent page, then freeing the high-order page while leaving other reserved bits behind - I believe that could sneak a PageReserved page back into the 2.6.9 allocator. If it were a particular application triggering this, it'd still be a kernel bug to allow it to happen. Yes, there is a specific app which seems to be related to the kernel panic. We use a few third party drivers on the system, so my initial suspicions were on: 3w_9xxx(U) which is the RAID card driver and fusedriver(U) which is a hardware PCI card driver. The app which is kernel panicing is the only application which makes use of the fusedriver. I'd like to confirm my suspicions on the driver. Do you have any suggestions on how I could trace the kernel panic to that specific driver? Thanks again for your input Hugh. Pat [ cut here ] kernel BUG at mm/rmap.c:434! invalid operand: [#1] SMP Modules linked in: fusedriver(U) md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc dm_multipath button battery ac uhci_hcd ehci_hcd e1000 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod 3w_9xxx(U) sd_mod scsi_mod CPU:5 EIP:0060:[c01518c6]Not tainted VLI EFLAGS: 00010202 (2.6.9-22.ELsmp) EIP is at page_add_anon_rmap+0xe/0x66 eax: 4964 ebx: c1800040 ecx: 090a100c edx: e5b5a544 esi: d1837e8c edi: fff25508 ebp: c1800040 esp: cf12ae40 ds: 007b es: 007b ss: 0068 Process check-enqueued- (pid: 17602, threadinfo=cf12a000 task=f57577b0) Stack: 40002067 8000 c014d034 fff29000 40002025 8000 0163 e5b5a544 f35b9080 fff25508 fff25508 090a100c c014d0e2 cc5a2240 0001 090a100c 8000 Call Trace: [c014d034] do_anonymous_page+0x19c/0x1db [c014d0e2] do_no_page+0x6f/0x2f9 [c014d503] handle_mm_fault+0xbd/0x175 [c011addb] do_page_fault+0x1ae/0x5c6 [c014e58e] vma_adjust+0x286/0x2d6 [c014e762] vma_merge+0xe1/0x165 [c011d3d5] finish_task_switch+0x30/0x66 [c02cf368] schedule+0x844/0x87a [c011ac2d] do_page_fault+0x0/0x5c6 [c02d1bab] error_code+0x2f/0x38 Code: 83 7b 10 00 74 0b 89 ca 89 d8 e8 fb fe ff ff 01 c6 89 d8 e8 ac df fe ff 5b 89 f0 5e c3 56 53 89 c3 8b 00 8b 72 44 f6 c4 08 74 08 0f 0b b2 01 ce 52 2e c0 85 f6 75 08 0f 0b b3 01 ce 52 2e c0 8b 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
I'm running kernel 2.6.9-22.ELsmp on dual Xeon
servers. I've received kernel panics occasionally in
the past, but they are more frequent now as the load
on the system has increased. Below is a capture of the
kernel panic.
If anything below screams it's coming from a certain
source (defective RAM? Bad application or device
driver?), please let me know as I'm pulling what
little hair I have left out on this one. Suggestions
on what to try would be greatly appreciated. Thanks!
[ cut here ]
kernel BUG at mm/rmap.c:434!
invalid operand: [#1]
SMP
Modules linked in: fusedriver(U) md5 ipv6 parport_pc
lp parport autofs4 i2c_dev i2c_core sunrpc
dm_multipath button battery ac uhci_hcd ehci_hcd e1000
floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
3w_9xxx(U) sd_mod scsi_mod
CPU:5
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.9-22.ELsmp)
EIP is at page_add_anon_rmap+0xe/0x66
eax: 4964 ebx: c1800040 ecx: 090a100c edx:
e5b5a544
esi: d1837e8c edi: fff25508 ebp: c1800040 esp:
cf12ae40
ds: 007b es: 007b ss: 0068
Process check-enqueued- (pid: 17602,
threadinfo=cf12a000 task=f57577b0)
Stack: 40002067 8000 c014d034 fff29000 40002025
8000 0163 e5b5a544
f35b9080 fff25508 fff25508 090a100c
c014d0e2 cc5a2240 0001
090a100c
8000
Call Trace:
[] do_anonymous_page+0x19c/0x1db
[] do_no_page+0x6f/0x2f9
[] handle_mm_fault+0xbd/0x175
[] do_page_fault+0x1ae/0x5c6
[] vma_adjust+0x286/0x2d6
[] vma_merge+0xe1/0x165
[] finish_task_switch+0x30/0x66
[] schedule+0x844/0x87a
[] do_page_fault+0x0/0x5c6
[] error_code+0x2f/0x38
Code: 83 7b 10 00 74 0b 89 ca 89 d8 e8 fb fe ff ff 01
c6 89 d8 e8 ac df fe ff 5b 89 f0 5e c3 56 53 89 c3 8b
00 8b 72 44 f6 c4 08 74 08 <0f> 0b b2 01 ce 52 2e c0
85 f6 75 08 0f 0b b3 01 ce 52 2e c0 8b
<0>Fatal exception: panic in 5 seconds
bad: scheduling while atomic!
[] schedule+0x2d/0x87a
[] poke_blanked_console+0x3d/0x9a
[] vt_console_print+0x294/0x2a5
[] __mod_timer+0x101/0x10b
[] schedule_timeout+0xd3/0xee
[] process_timeout+0x0/0x5
[] printk+0xe/0x11
[] die+0x15a/0x16b
[] do_invalid_op+0xcf/0xf2
[] ext3_get_inode_loc+0x4f/0x226 [ext3]
[] page_add_anon_rmap+0xe/0x66
[] __wake_up+0x29/0x3c
[] __rmqueue+0xc1/0x10c
[] rmqueue_bulk+0x5b/0x65
[] do_invalid_op+0x0/0xf2
[] error_code+0x2f/0x38
[] page_add_anon_rmap+0xe/0x66
[] do_anonymous_page+0x19c/0x1db
[] do_no_page+0x6f/0x2f9
[] handle_mm_fault+0xbd/0x175
[] do_page_fault+0x1ae/0x5c6
[] vma_adjust+0x286/0x2d6
[] vma_merge+0xe1/0x165
[] finish_task_switch+0x30/0x66
[] schedule+0x844/0x87a
[] do_page_fault+0x0/0x5c6
[] error_code+0x2f/0x38
[ cut here ]
kernel BUG at arch/i386/mm/highmem.c:42!
invalid operand: [#2]
SMP
Modules linked in: fusedriver(U) md5 ipv6 parport_pc
lp parport autofs4 i2c_dev i2c_core sunrpc
dm_multipath button battery ac uhci_hcd ehci_hcd e1000
floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
3w_9xxx(U) sd_mod scsi_mod
CPU:5
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.9-22.ELsmp)
EIP is at kmap_atomic+0x73/0x178
eax: c000a928 ebx: 8000 ecx: 90b52163 edx:
00c4
esi: f467a380 edi: d898bbe8 ebp: c000af48 esp:
eee66e7c
ds: 007b es: 007b ss: 0068
Process search_pe (pid: 17511, threadinfo=eee66000
task=f511e030)
Stack: 0001 f5646900 0001
fff25000 c182d280 e19cb630 f467a380
d898bbe8 0c00 c014b006
e19cb630 e19cb630 e19cb630 f467a3b0 d898bbe8
afb80004 c014d4d1 f3aae22c
Call Trace:
[] pte_alloc_map+0xd9/0xe2
[] handle_mm_fault+0x8b/0x175
[] do_page_fault+0x1ae/0x5c6
[] vma_merge+0x156/0x165
[] do_mmap_pgoff+0x3cd/0x666
[] do_mmap_pgoff+0x568/0x666
[] sys_mmap2+0x7e/0xaf
[] do_page_fault+0x0/0x5c6
[] error_code+0x2f/0x38
[] __lock_text_end+0x11a/0x100f
Code: c8 40 c0 01 c2 8d 42 16 c1 e0 0c 29 c1 89 4c 24
24 8d 04 d5 00 00 00 00 89 e9 29 c1 89 c8 8b 09 8b 58
04 85 c9 75 04 85 db 74 08 <0f> 0b 2a 00 04 27 2e c0
8b 5c 24 28 8b 0d 78 29 32 c0 8b 03 89
<0>Fatal exception: panic in 5 seconds
bad: scheduling while atomic!
[] schedule+0x2d/0x87a
[] poke_blanked_console+0x3d/0x9a
[] vt_console_print+0x294/0x2a5
[] __mod_timer+0x101/0x10b
[] schedule_timeout+0xd3/0xee
[] process_timeout+0x0/0x5
[] printk+0xe/0x11
[] die+0x15a/0x16b
[] do_invalid_op+0xcf/0xf2
[] autoremove_wake_function+0xd/0x2d
[] kmap_atomic+0x73/0x178
[] __wake_up+0x29/0x3c
[] __kfree_skb+0xf4/0xf7
[] unix_stream_recvmsg+0x2cc/0x39d
[] do_invalid_op+0x0/0xf2
[] error_code+0x2f/0x38
[] kmap_atomic+0x73/0x178
[] pte_alloc_map+0xd9/0xe2
[] handle_mm_fault+0x8b/0x175
[] do_page_fault+0x1ae/0x5c6
[] vma_merge+0x156/0x165
[] do_mmap_pgoff+0x3cd/0x666
[] do_mmap_pgoff+0x568/0x666
[] sys_mmap2+0x7e/0xaf
[] do_page_fault+0x0/0x5c6
[] error_code+0x2f/0x38
[] __lock_text_end+0x11a/0x100f
[ cut
Invalid operand: kernel BUG at mm/rmap.c:434! and arch/i386/mm/highmem.c:42!)
I'm running kernel 2.6.9-22.ELsmp on dual Xeon
servers. I've received kernel panics occasionally in
the past, but they are more frequent now as the load
on the system has increased. Below is a capture of the
kernel panic.
If anything below screams it's coming from a certain
source (defective RAM? Bad application or device
driver?), please let me know as I'm pulling what
little hair I have left out on this one. Suggestions
on what to try would be greatly appreciated. Thanks!
[ cut here ]
kernel BUG at mm/rmap.c:434!
invalid operand: [#1]
SMP
Modules linked in: fusedriver(U) md5 ipv6 parport_pc
lp parport autofs4 i2c_dev i2c_core sunrpc
dm_multipath button battery ac uhci_hcd ehci_hcd e1000
floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
3w_9xxx(U) sd_mod scsi_mod
CPU:5
EIP:0060:[c01518c6]Not tainted VLI
EFLAGS: 00010202 (2.6.9-22.ELsmp)
EIP is at page_add_anon_rmap+0xe/0x66
eax: 4964 ebx: c1800040 ecx: 090a100c edx:
e5b5a544
esi: d1837e8c edi: fff25508 ebp: c1800040 esp:
cf12ae40
ds: 007b es: 007b ss: 0068
Process check-enqueued- (pid: 17602,
threadinfo=cf12a000 task=f57577b0)
Stack: 40002067 8000 c014d034 fff29000 40002025
8000 0163 e5b5a544
f35b9080 fff25508 fff25508 090a100c
c014d0e2 cc5a2240 0001
090a100c
8000
Call Trace:
[c014d034] do_anonymous_page+0x19c/0x1db
[c014d0e2] do_no_page+0x6f/0x2f9
[c014d503] handle_mm_fault+0xbd/0x175
[c011addb] do_page_fault+0x1ae/0x5c6
[c014e58e] vma_adjust+0x286/0x2d6
[c014e762] vma_merge+0xe1/0x165
[c011d3d5] finish_task_switch+0x30/0x66
[c02cf368] schedule+0x844/0x87a
[c011ac2d] do_page_fault+0x0/0x5c6
[c02d1bab] error_code+0x2f/0x38
Code: 83 7b 10 00 74 0b 89 ca 89 d8 e8 fb fe ff ff 01
c6 89 d8 e8 ac df fe ff 5b 89 f0 5e c3 56 53 89 c3 8b
00 8b 72 44 f6 c4 08 74 08 0f 0b b2 01 ce 52 2e c0
85 f6 75 08 0f 0b b3 01 ce 52 2e c0 8b
0Fatal exception: panic in 5 seconds
bad: scheduling while atomic!
[c02ceb51] schedule+0x2d/0x87a
[c020a293] poke_blanked_console+0x3d/0x9a
[c02096a5] vt_console_print+0x294/0x2a5
[c0129715] __mod_timer+0x101/0x10b
[c02cf8a0] schedule_timeout+0xd3/0xee
[c0129fba] process_timeout+0x0/0x5
[c0122320] printk+0xe/0x11
[c0106092] die+0x15a/0x16b
[c01063f5] do_invalid_op+0xcf/0xf2
[f88aa3d6] ext3_get_inode_loc+0x4f/0x226 [ext3]
[c01518c6] page_add_anon_rmap+0xe/0x66
[c011e5b5] __wake_up+0x29/0x3c
[c0142c1b] __rmqueue+0xc1/0x10c
[c0142cc1] rmqueue_bulk+0x5b/0x65
[c0106326] do_invalid_op+0x0/0xf2
[c02d1bab] error_code+0x2f/0x38
[c01518c6] page_add_anon_rmap+0xe/0x66
[c014d034] do_anonymous_page+0x19c/0x1db
[c014d0e2] do_no_page+0x6f/0x2f9
[c014d503] handle_mm_fault+0xbd/0x175
[c011addb] do_page_fault+0x1ae/0x5c6
[c014e58e] vma_adjust+0x286/0x2d6
[c014e762] vma_merge+0xe1/0x165
[c011d3d5] finish_task_switch+0x30/0x66
[c02cf368] schedule+0x844/0x87a
[c011ac2d] do_page_fault+0x0/0x5c6
[c02d1bab] error_code+0x2f/0x38
[ cut here ]
kernel BUG at arch/i386/mm/highmem.c:42!
invalid operand: [#2]
SMP
Modules linked in: fusedriver(U) md5 ipv6 parport_pc
lp parport autofs4 i2c_dev i2c_core sunrpc
dm_multipath button battery ac uhci_hcd ehci_hcd e1000
floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
3w_9xxx(U) sd_mod scsi_mod
CPU:5
EIP:0060:[c011c6e6]Not tainted VLI
EFLAGS: 00010286 (2.6.9-22.ELsmp)
EIP is at kmap_atomic+0x73/0x178
eax: c000a928 ebx: 8000 ecx: 90b52163 edx:
00c4
esi: f467a380 edi: d898bbe8 ebp: c000af48 esp:
eee66e7c
ds: 007b es: 007b ss: 0068
Process search_pe (pid: 17511, threadinfo=eee66000
task=f511e030)
Stack: 0001 f5646900 0001
fff25000 c182d280 e19cb630 f467a380
d898bbe8 0c00 c014b006
e19cb630 e19cb630 e19cb630 f467a3b0 d898bbe8
afb80004 c014d4d1 f3aae22c
Call Trace:
[c014b006] pte_alloc_map+0xd9/0xe2
[c014d4d1] handle_mm_fault+0x8b/0x175
[c011addb] do_page_fault+0x1ae/0x5c6
[c014e7d7] vma_merge+0x156/0x165
[c014ec91] do_mmap_pgoff+0x3cd/0x666
[c014ee2c] do_mmap_pgoff+0x568/0x666
[c010b67f] sys_mmap2+0x7e/0xaf
[c011ac2d] do_page_fault+0x0/0x5c6
[c02d1bab] error_code+0x2f/0x38
[c02d007b] __lock_text_end+0x11a/0x100f
Code: c8 40 c0 01 c2 8d 42 16 c1 e0 0c 29 c1 89 4c 24
24 8d 04 d5 00 00 00 00 89 e9 29 c1 89 c8 8b 09 8b 58
04 85 c9 75 04 85 db 74 08 0f 0b 2a 00 04 27 2e c0
8b 5c 24 28 8b 0d 78 29 32 c0 8b 03 89
0Fatal exception: panic in 5 seconds
bad: scheduling while atomic!
[c02ceb51] schedule+0x2d/0x87a
[c020a293] poke_blanked_console+0x3d/0x9a
[c02096a5] vt_console_print+0x294/0x2a5
[c0129715] __mod_timer+0x101/0x10b
[c02cf8a0] schedule_timeout+0xd3/0xee
[c0129fba] process_timeout+0x0/0x5
[c0122320] printk+0xe/0x11
[c0106092] die+0x15a/0x16b
[c01063f5] do_invalid_op+0xcf/0xf2
[c011ffbe] autoremove_wake_function+0xd/0x2d
[c011c6e6]
