kernel cores tend to be large (all of wired memory after all) and unless I have
exactly the same kernel as you with the same sources at the same changeset, not
useful. A backtrace is a good place to start.
> kgdb /boot/kernel/kernel /var/crash/vmcore.last
---- On Fri, 06 Jan 2017 10:53:03 -0800 Pete Wright <p...@nomadlogic.org>
> On 1/6/17 10:44 AM, Jonathan Anderson wrote:
> > On 6 Jan 2017, at 12:48, Pete Wright wrote:
> >> On 1/6/17 9:14 AM, Matthew Macy wrote:
> >>> I just did the merge and it's using a relatively untested new KPI so
> >>> regressions aren't too surprising I'm afraid. #96 is more or less
> >>> content free in terms of providing useful information. Getting a core
> >>> + backtrace would be a lot more helpful. See the repo's wiki for
> >>> details on improving your odds of getting a core.
> >> I have found the following has enabled me to catch kernel panic's
> >> pretty reliably on the drm-next branch when i have the i915kms module
> >> loaded:
> >> dev.drm.skip_ddb=1
> > Excellent: I turned that on and got a core, then got another core while
> > tar'ing up the first core. :)
> > The machine in question is currently not connected to any network (iwm
> > is being a bit unhappy), but once it is, where can I put the tarball?
> oh great!
> i've been having the same problems with iwm too (failing to load
> firmware on boot). my trick has been to either boot into an old kernel
> where iwm was mostly usable. also i've commented out the line enabling
> wlan0 in my rc.conf then uncommented it after boot and manually running
> "service netif start" to bring up iwm. that method works most of the
> Pete Wright
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"