linux-um archives
 help / color / mirror / Atom feed
* [uml-devel] Errors in schedule / _switch_to
@ 2011-09-09 12:51 Oscar Hellström
  0 siblings, 0 replies; 4+ messages in thread
From: Oscar Hellström @ 2011-09-09 12:51 UTC (permalink / raw)
  To: user-mode-linux-devel

Hi,

I'm running an older version of the kernel, 2.6.32.3, and I'm experiencing
segmentations faults in _switch_to, which is called from schedule. My
stacktrace looks like:
...
#13 <signal handler called>
#14 _switch_to (prev=0x43ff1340, next=0xffffffd4, last=0x43ff1340) at
arch/um/kernel/process.c:82
#15 0x08205cd9 in schedule () at kernel/sched.c:2886
#16 0x08205dda in io_schedule () at kernel/sched.c:6784
#17 0x0809af72 in sync_page (word=0x96ba180) at mm/filemap.c:187
#18 0x08205fde in __wait_on_bit_lock (wq=0x980b7d8, q=0x43fd5ce4,
action=0x809af37 <sync_page>, mode=2) at kernel/wait.c:229
#19 0x0809af21 in __lock_page (page=0x96ba180) at mm/filemap.c:601
#20 0x0809afbd in find_lock_page (mapping=0x47608668, offset=2596) at
include/linux/pagemap.h:317
#21 0x0809c888 in filemap_fault (vma=0x43d70764, vmf=0x43fd5d8c) at
mm/filemap.c:1538
#22 0x080a88ad in __do_fault (mm=0x478855e0, vma=0x43d70764,
address=2437412980, pmd=0x472c0914, pgoff=2596, flags=0, orig_pte={pte =
0}) at mm/memory.c:2719
#23 0x080a9fec in handle_mm_fault (mm=0x478855e0, vma=0x43d70764,
address=2437412980, flags=0) at mm/memory.c:2917
#24 0x0805c5f1 in handle_page_fault (address=2437412980, ip=1076410045,
is_write=0, is_user=1, code_out=0x43fd5e40) at arch/um/kernel/trap.c:71
#25 0x0805c729 in segv (fi={error_code = 4, cr2 = 2437412980, trap_no =
14}, ip=1076410045, is_user=1, regs=0x43ff1550) at
arch/um/kernel/trap.c:178
#26 0x0805c91e in segv_handler (sig=11, regs=0x43ff1550) at
arch/um/kernel/trap.c:150
#27 0x0806c00a in userspace (regs=0x43ff1550) at
arch/um/os-Linux/skas/process.c:421
#28 0x0805aa75 in fork_handler () at arch/um/kernel/process.c:179
#29 0x00000000 in ?? ()

I've compiled in a driver into the kernel which fakes interrupts by sending
signals to the UML process. I guess this could interfere with something,
but I do believe I've seen this without the signals being enabled.
Unfortunately I don't have any easy way to reproduce this, it happens
seemingly at random.

Any pointer to what this can be and where I can start looking would be
appreciated!

Thanks
/Oscar

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


^ permalink raw reply	[flat|nested] 4+ messages in thread
* [uml-devel] Errors in schedule / _switch_to
@ 2011-09-09 12:13 Oscar Hellström
  2011-09-10 11:10 ` richard -rw- weinberger
  0 siblings, 1 reply; 4+ messages in thread
From: Oscar Hellström @ 2011-09-09 12:13 UTC (permalink / raw)
  To: user-mode-linux-devel

Hi,

I'm running an older version of the kernel, 2.6.32.3 and I'm experiencing
segmentations faults in _switch_to, which is called from schedule. My
stacktrace looks like:
3 <signal handler called>
#14 _switch_to (prev=0x43ff1340, next=0xffffffd4, last=0x43ff1340) at
arch/um/kernel/process.c:82
#15 0x08205cd9 in schedule () at kernel/sched.c:2886
#16 0x08205dda in io_schedule () at kernel/sched.c:6784
#17 0x0809af72 in sync_page (word=0x96ba180) at mm/filemap.c:187
#18 0x08205fde in __wait_on_bit_lock (wq=0x980b7d8, q=0x43fd5ce4,
action=0x809af37 <sync_page>, mode=2) at kernel/wait.c:229
#19 0x0809af21 in __lock_page (page=0x96ba180) at mm/filemap.c:601
#20 0x0809afbd in find_lock_page (mapping=0x47608668, offset=2596) at
include/linux/pagemap.h:317
#21 0x0809c888 in filemap_fault (vma=0x43d70764, vmf=0x43fd5d8c) at
mm/filemap.c:1538
#22 0x080a88ad in __do_fault (mm=0x478855e0, vma=0x43d70764,
address=2437412980, pmd=0x472c0914, pgoff=2596, flags=0, 
orig_pte={pte = 0}) at mm/memory.c:2719
#23 0x080a9fec in handle_mm_fault (mm=0x478855e0, vma=0x43d70764,
address=2437412980, flags=0) at mm/memory.c:2917
#24 0x0805c5f1 in handle_page_fault (address=2437412980, ip=1076410045,
is_write=0, is_user=1, code_out=0x43fd5e40)
at arch/um/kernel/trap.c:71
#25 0x0805c729 in segv (fi={error_code = 4, cr2 = 2437412980, trap_no =
14}, ip=1076410045, is_user=1, regs=0x43ff1550)
at arch/um/kernel/trap.c:178
#26 0x0805c91e in segv_handler (sig=11, regs=0x43ff1550) at
arch/um/kernel/trap.c:150
#27 0x0806c00a in userspace (regs=0x43ff1550) at
arch/um/os-Linux/skas/process.c:421
#28 0x0805aa75 in fork_handler () at arch/um/kernel/process.c:179
#29 0x00000000 in ?? ()

I've compiled in a driver into the kernel which fakes interrupts by sending
signals to the UML process. I guess this could interfere with something,
but I do believe I've seen this without the signals being enabled.
Unfortunately I don't have any easy way to reproduce this, it usually
happens seemingly at random.

Any pointer to what this can be and where I can start looking would be
appreciated!

Thanks
/Oscar
-- 
Oscar Hellström, oscar@hellstrom.st
web: http://oscar.hellstrom.st
xmpp: oscar@hellstrom.st

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-09-12 10:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-09 12:51 [uml-devel] Errors in schedule / _switch_to Oscar Hellström
  -- strict thread matches above, loose matches on Subject: below --
2011-09-09 12:13 Oscar Hellström
2011-09-10 11:10 ` richard -rw- weinberger
2011-09-12 10:46   ` Oscar Hellström

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox