early boot netisr_init() panic on older AMD SMP machine with recent 11-STABLE
My desktop machine has an older AMD SMP CPU and tracks 11-STABLE. For about six months or so it frequently panics early in boot. If I retry a sufficient number of times I can get a successful boot, but this is rather annoying. A normal boot looks like this: Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.2-STABLE #16 r339017M: Sat Sep 29 19:18:41 PDT 2018 d...@mousie.catspoiler.org:/usr/obj/usr/src/sys/GENERICDDB amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1 ) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD Athlon(tm) II X3 450 Processor (3214.60-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x100f53 Family=0x10 Model=0x5 Stepping=3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff SVM: NP,NRIP,NAsids=64 TSC: P-state invariant real memory = 34359738368 (32768 MB) avail memory = 33275473920 (31733 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 1607298818 Hz quality 800 random: entropy device external interface [SNIP] An unsuccessful boot looks like this (hand transcribed): [SNIP] ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1607298818 Hz quality 800 panic: netisr_init: not on CPU 0 cpuid = 2 KDB: stack backtrace: db_trace_selfwrapper() ... vpanic() ... doadump() ... netisr_init() ... mi_startup() ... btext() ... This problem may be silently occuring on many other machines. This machine is running a custom kernel with INVARIANTS and WITNESS. The panic is coming from a KASSERT(), which is only checked when the kernel is built with INVARIANTS. This KASSERT was removed from 12.0-CURRENT with this commit: https://svnweb.freebsd.org/base/head/sys/net/netisr.c?r1=301270&r2=302595 Revision 302595 - (view) (download) (annotate) - [select for diffs] Modified Mon Jul 11 21:25:28 2016 UTC (2 years, 2 months ago) by nwhitehorn File length: 44729 byte(s) Diff to previous 301270 Remove assumptions in MI code that the BSP is CPU 0. Perhaps this should be MFC'ed, but it seems odd that the BSP is non-deterministic. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Latest update to ATI driver broke in same way as using DRM-next did
So this is kind of interesting - I posted here last month about trying to use drm-next and it not finding my 2nd monitor properly. I did try and subscribe to x11@ but for some reaosn that didnt work, and I didnt worry abotu it too much so didnt investigate further as I wont be running 12.0 for a while. But this morning I just did a small update of ports, and it upgraded the driver from xf86-video-ati-7.9.0_3,1 to 18.1.0,1 ... and that acts in the same way, i.e. only runs on one monitor and cant see the 2nd. I thought it was a bit too much of a co-incidence, as I would guess both the old and new drivers share substantial amounts of code. I rolled back to the old driver and this is the dmesg outoput it gives if thats of any help... info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] DP-1 info: [drm] HPD4 info: [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c info: [drm] Encoders: info: [drm] DFP1: INTERNAL_UNIPHY2 info: [drm] Connector 1: info: [drm] DP-2 info: [drm] HPD5 info: [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 0x647c info: [drm] Encoders: info: [drm] DFP2: INTERNAL_UNIPHY2 info: [drm] Connector 2: info: [drm] DVI-I-1 info: [drm] HPD1 info: [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c info: [drm] Encoders: info: [drm] DFP3: INTERNAL_UNIPHY info: [drm] CRT1: INTERNAL_KLDSCP_DAC1 info: [drm] Internal thermal controller with fan control info: [drm] radeon: power management initialized info: [drm] Connector DP-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DP-1 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DP-2: get mode from tunables: info: [drm] - kern.vt.fb.modes.DP-2 info: [drm] - kern.vt.fb.default_mode info: [drm] Connector DVI-I-1: get mode from tunables: info: [drm] - kern.vt.fb.modes.DVI-I-1 info: [drm] - kern.vt.fb.default_mode info: [drm] fb mappable at 0xE0142000 info: [drm] vram apper at 0xE000 info: [drm] size 9437184 info: [drm] fb depth is 24 info: [drm]pitch is 8192 fbd0 on drmn0 VT: Replacing driver "vga" with new "fb". info: [drm] Initialized radeon 2.29.0 20080528 for drmn0 on minor 0 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dmesg submission service -- please submit today
On 9/10/18 3:15 am, Matt S wrote: > It really seems like the project would benefit from having better hardware > stats. If you make it a package, people have to be educated to get it and > use it--not that it doesn't have value, it just isn't well exposed and you > will only get stats from the most clueful users. > > I would suggest making anonymized stat upload part of the install and > upgrade process, to get wider coverage. > > - When installing, there's a new step or checkbox with an opt-in for > hardware data sharing, defaulting to off > - If you opt in, your info is uploaded as part of the install process > - Expose the same functionality in a new system-level command like > 'freebsd-uploadstats' and make it an optional but suggested part of the > upgrade process, which is something most users will see repeatedly if they > continue to be users. > > Perhaps the local machine can generate a hash of the report, check that > with the server before the upload goes through. Hardware doesn't change > that often. There is the bsdstats port for system version and hardware details, as the site has had errors listing hardware details for some time it may not last much longer. With the amount of TrueOS entries, it would indicate that they probably have (had?) it as a default install. If the FreeBSD project or foundation doesn't want to collect this data then a company that relies on *BSD, like iX Systems, may want to step up and provide servers to collect this data. I do think it would be better as an official project data collection rather than a third party service. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
