Bug 193360 - [panic] [syscons] random syscons panic
Summary: [panic] [syscons] random syscons panic
Status: Closed Not Enough Information
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 9.1-RELEASE
Hardware: i386 Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
: 185476 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-06 06:03 UTC by sasamotikomi
Modified: 2019-02-13 01:53 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.