Re: ntp problems stratum 2 to 14?
Hi Dewayne, Sorry for the delay. Unfortunately, I can't really suggest anything - it's not clear to me why ntpd would prefer a stratum 14 clock over a stratum 2 clock. Have you tried looking through the debugging hints page (https://www.eecis.udel.edu/~mills/ntp/html/debug.html)? I haven't seen that problem but I don't use the local clock. During startup, it would not seem unreasonable for the local clock to become valid first because it will have a lower jitter. But ntpd should switch to the stratum 2 clock and stay with in as the better time source. One problem is that if ntpd decides to switch away from the clock for any reason (eg a burst of jitter), it may get stuck on the local clock as it drifts further from "real" time. -- Peter Jeremy signature.asc Description: PGP signature
Re: jedec_dimm fails to boot
On Wed, Mar 04, 2020 at 11:41:22PM +0300, Yuri Pankov wrote: ! On 04.03.2020 19:09, Peter wrote: ! > When I kldload jedec_dimm durig runtime, it works just as expected, ! > and the DIMM data appears in sysctl. ! > ! > But when I do ! > * load the jedec_dimm at the loader prompt, or ! > * add it to loader.conf, or ! > * compile it into a custom kernel, ! > it does not boot anymore. ! Could you try backporting r351604 and see if it helps? Yepp, that works. Thank You! :) ___ 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"
kldunload geom_journal hangs with jfini
Hi everyone, a recent 12-stable rev 358557 amd64 build hangs on kldunload of geom_journal. To reproduce: kldload geom_journal kldunload geom_journal kldunload just hangs indefinitely. top says the state is "jfini:". It's using some cpu time though. procstat -k hangs as well. Very reproducable, on both virtualbox as well as real hardware. Any extra info that could help? Johannes ___ 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: jedec_dimm fails to boot
On 04.03.2020 19:09, Peter wrote: I met an Issue: When I kldload jedec_dimm durig runtime, it works just as expected, and the DIMM data appears in sysctl. But when I do * load the jedec_dimm at the loader prompt, or * add it to loader.conf, or * compile it into a custom kernel, it does not boot anymore. My custom kernel does just hang somewhere while switching the screen, i.e. no output. The GENERIC does immediate-reboot during the device probe phase. So both are not suitable for gathering additional info in an easy way. (And since my DIMM appear to have neither thermal nor serial, there is not much to gain for me here, so I will not pursue this further, at least not before switching to R.12.) But I fear there are some general problems with sorting out of the modules during system bringup - see also my other message titled "panic: too many modules". Some data for those interested: FreeBSD 11.3-RELEASE-p6 CPU: Intel(R) Core(TM) i5-3570T CPU (IvyBridge) Board: https://www.asus.com/Motherboards/P8B75V/specifications/ Config: hint.jedec_dimm.0.at="smbus12" hint.jedec_dimm.0.addr="0xa0" hint.jedec_dimm.1.at="smbus12" hint.jedec_dimm.1.addr="0xa2" hint.jedec_dimm.2.at="smbus12" hint.jedec_dimm.2.addr="0xa4" hint.jedec_dimm.3.at="smbus12" hint.jedec_dimm.3.addr="0xa6" ichsmb0: port 0xf040-0xf05f mem 0xf7d1500 0-0xf7d150ff irq 18 at device 31.3 on pci0 smbus12: on ichsmb0 smb12: on smbus12 With GENERIC it becomes smbus0 (because drm2 is not loaded) and I need to load "smbus" and "ichsmb" frontup. Could you try backporting r351604 and see if it helps? ___ 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: jedec_dimm fails to boot
On Wed, Mar 4, 2020 at 9:14 AM Peter wrote: > > I met an Issue: > > When I kldload jedec_dimm durig runtime, it works just as expected, > and the DIMM data appears in sysctl. > > But when I do > * load the jedec_dimm at the loader prompt, or > * add it to loader.conf, or > * compile it into a custom kernel, > it does not boot anymore. > > My custom kernel does just hang somewhere while switching the screen, > i.e. no output. The GENERIC does immediate-reboot during the device > probe phase. So both are not suitable for gathering additional info > in an easy way. (And since my DIMM appear to have neither thermal nor > serial, there is not much to gain for me here, so I will not pursue > this further, at least not before switching to R.12.) > But I fear there are some general problems with sorting out of the > modules during system bringup - see also my other message titled > "panic: too many modules". > > Some data for those interested: > > FreeBSD 11.3-RELEASE-p6 > CPU: Intel(R) Core(TM) i5-3570T CPU (IvyBridge) > Board: https://www.asus.com/Motherboards/P8B75V/specifications/ > Config: > hint.jedec_dimm.0.at="smbus12" > hint.jedec_dimm.0.addr="0xa0" > hint.jedec_dimm.1.at="smbus12" > hint.jedec_dimm.1.addr="0xa2" > hint.jedec_dimm.2.at="smbus12" > hint.jedec_dimm.2.addr="0xa4" > hint.jedec_dimm.3.at="smbus12" > hint.jedec_dimm.3.addr="0xa6" > > ichsmb0: port 0xf040-0xf05f mem > 0xf7d1500 > 0-0xf7d150ff irq 18 at device 31.3 on pci0 > smbus12: on ichsmb0 > smb12: on smbus12 > > With GENERIC it becomes smbus0 (because drm2 is not loaded) and I need > to load "smbus" and "ichsmb" frontup. > > Cheerio, > PMc > Looks like you just need the module loaded a bit later. Does adding kld_list="jedec_dimm.kld" to /etc/rc.conf work? If you already have kld_list, append "jedec_dimm". -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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"
panic: too many modules
Front up: I do not like loadable modules. They are nice to try something out, but when you start to depend on some dozen loaded modules, debugging becomes a living hell: say you hunt some spurious misbehaviour and compare logfiles with those from four weeks ago, you will not know exactly which modules were loaded at that time. Compiling everything into the kernel has the advantage that the 'uname' does change on every change and so does precisely describe the running kernel. So I came across the cc_vegas and cc_cdg modules, and they aren't provided to compile into the kernel straightaway. But that should not be a big deal: just add some arbitrary new device to the KERNCONF, and then add the required files to sys/conf/files appropriately. Should work. But it doesn't. Right after the startup message, before even probing devices, it says panic: module_register_init: module named ertt not found and a stacktrace from kern/init_main.c:mi_startup(). But definitely the h_ertt is present in the kernel (I checked). To have a closer look, I added VERBOSE_SYSINIT to the kernel, and - the panic is gone, everything working as expected. Without even activating the output from VERBOSE_SYSINIT. Then, I moved netinet/khelp/h_ertt.c to the very end of sys/conf/files - and this also avoids the panic and things do work. While this change does nothing but change the sequence in which the files are compiled (and probably linked). I think this is not good. Everybody likes modules, (although -see above- they come with a serious tradeoff on reproducability). But if we now deliver components only as loadable modules because a compound kernel is no longer able to sort them out on boot, that's a more serious issue. I wouldn't complain if the module would simply not work (reproducible) when compiled into the kernel - but this here appears to be a race, most likely a timing race. And such being possible to happen at the point where the kernel sorts out it's own components - ups, that does worry me indeed... There seems also to be a desire for a *fast* system bringup. I don't share that. I do boot once a quarter, and if that takes a hour I don't mind. Maybe there is need for an option, to give fast boot to those who want a gaming console alike to be available immediately, and slow boot for those who want a reliable system in 24/7 operation? Maybe I'll take a closer look at the issue after switching to R.12 (probably not this year). Or, maybe somebody would like to point me to some paper describing how the module fabric is supposed to interface and by which steps the runtime linkage is achieved? Platform: FreeBSD 11.3-RELEASE-p6, Intel(R) Core(TM) i5-3570T CPU (IvyBridge) cheerio, PMc ___ 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"
jedec_dimm fails to boot
I met an Issue: When I kldload jedec_dimm durig runtime, it works just as expected, and the DIMM data appears in sysctl. But when I do * load the jedec_dimm at the loader prompt, or * add it to loader.conf, or * compile it into a custom kernel, it does not boot anymore. My custom kernel does just hang somewhere while switching the screen, i.e. no output. The GENERIC does immediate-reboot during the device probe phase. So both are not suitable for gathering additional info in an easy way. (And since my DIMM appear to have neither thermal nor serial, there is not much to gain for me here, so I will not pursue this further, at least not before switching to R.12.) But I fear there are some general problems with sorting out of the modules during system bringup - see also my other message titled "panic: too many modules". Some data for those interested: FreeBSD 11.3-RELEASE-p6 CPU: Intel(R) Core(TM) i5-3570T CPU (IvyBridge) Board: https://www.asus.com/Motherboards/P8B75V/specifications/ Config: hint.jedec_dimm.0.at="smbus12" hint.jedec_dimm.0.addr="0xa0" hint.jedec_dimm.1.at="smbus12" hint.jedec_dimm.1.addr="0xa2" hint.jedec_dimm.2.at="smbus12" hint.jedec_dimm.2.addr="0xa4" hint.jedec_dimm.3.at="smbus12" hint.jedec_dimm.3.addr="0xa6" ichsmb0: port 0xf040-0xf05f mem 0xf7d1500 0-0xf7d150ff irq 18 at device 31.3 on pci0 smbus12: on ichsmb0 smb12: on smbus12 With GENERIC it becomes smbus0 (because drm2 is not loaded) and I need to load "smbus" and "ichsmb" frontup. Cheerio, PMc ___ 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: pkg breakage ?
On 3/3/2020 6:04 PM, Mark Saad wrote: > Mike > Not the best solution but switch from “latest” to “quarterly” in the pkg > config . The quarterly repos are unaffected. Thanks! That will be good enough for this project and works for now ---Mike ___ 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"
