Bug 193360

Summary: [panic] [syscons] random syscons panic
Product: Base System Reporter: sasamotikomi
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Not Enough Information    
Severity: Affects Only Me CC: gonzo, jhb, sasamotikomi
Priority: Normal    
Version: 9.1-RELEASE   
Hardware: i386   
OS: Any   

Description sasamotikomi 2014-09-06 06:03:46 UTC 
core.txt.0
FreeBSD 9.1-RELEASE
instruction pointer     = 0x20:0xc0e1eb8f
current process         = 1911 (sh)
core.txt.1
FreeBSD 9.1-RELEASE 
instruction pointer     = 0x20:0xc0e1ecf1
current process         = 31234 (sh)

 nm -n /boot/kernel.old9.1/kernel | grep 0x
c06ab840 t ed_rtl80x9_media_ioctl
c06ab870 T ed_probe_RTL80x9
c06ac950 t ed_pccard_dl100xx_mii_readbits
c06aca40 t ed_pccard_dl100xx_mii_writebits
c09ac8d0 t xl_txeof_90xB
c09ae640 t xl_start_90xB_locked
c0ed4150 T ed_probe_WD80x3_generic
c0ed4bc0 T ed_probe_WD80x3
c0f36640 T Xint0x80_syscall
c0f40930 t topo_probe_0x4
Comment 1 sasamotikomi 2014-09-06 09:55:05 UTC 
*** Bug 185476 has been marked as a duplicate of this bug. ***
Comment 2 John Baldwin freebsd_committer freebsd_triage 2014-09-08 16:55:32 UTC 
For these and the other various PRs you opened recently, you need to remove the 'grep 0x' from the 'nm -n' output.  That removes most of the useful symbols and isn't helpful.  In addition, far more useful would be to get stack traces, especially if you have core.txt.N files, the kgdb stack trace in that file would be the first thing needed to look at any of these.

As I mentioned on another bug, a dmesg from this machine wouldn't hurt either, but I doubt that either ed(4) or xl(4) is relevant.
Comment 3 sasamotikomi 2014-12-12 13:09:50 UTC 
(In reply to John Baldwin from comment #2)
> For these and the other various PRs you opened recently, you need to remove
> the 'grep 0x' from the 'nm -n' output.  That removes most of the useful
> symbols and isn't helpful.  In addition, far more useful would be to get
> stack traces, especially if you have core.txt.N files, the kgdb stack trace
> in that file would be the first thing needed to look at any of these.
> 
> As I mentioned on another bug, a dmesg from this machine wouldn't hurt
> either, but I doubt that either ed(4) or xl(4) is relevant.

nm -n /boot/kernel9.1/kernel | grep c0e1e
c0e1e170 t pmap_update_pde_user
c0e1e1a0 T pmap_lazyfix_action
c0e1e1f0 T pmap_copy_page
c0e1e350 T pmap_release
c0e1e600 T pmap_activate
c0e1e6f0 T pmap_kenter_temporary
c0e1e730 T pmap_map
c0e1e820 T pmap_unmapdev
c0e1e8c0 t pmap_unuse_pt
c0e1e920 t pmap_remove_pte
c0e1ea00 t pmap_remove_page
c0e1ea50 t get_pv_entry
Comment 4 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-28 02:43:31 UTC 
Provided information is not enough to analyze the problem.