Re: Does someone keep track of how long it takes to buildworld/kernel?
On Mon, 16 Jan 2017 07:41:06 -0800, jungle Boogie wrote: > On 13 January 2017 at 12:23, Eric Joyner wrote: > > > > It takes forever, but I keep on forgetting to time how long it takes, so I > > don't know how long "forever" is. > > > My last buildworld on a severely under powered i386 for 11stable: 420:41 > minutes > Build kernel is around 85 minutes. Some "manual copy & paste" data from the past (original post is from 2008, repost from 11/2015): *** quote *** FreeBSD 5 on Pentium 4 with 2 GHz and 1 GB RAM: b.world+b.kern: 17494.415u 2562.134s 5:46:42.25 96.4% (with CFLAGS) 17474.169u 2481.368s 5:46:30.40 95.9% (without CLFAGS) 5608.712u 1595.130s 2:13:18.67 90.0% 6382.185u 1788.433s 2:26:36.06 92.8% buildworld: 5086.993u 1431.086s 1:58:16.33 91.8% 11457.047u 2151.158s 3:54:15.31 96.8% buildkernel 2326.380u 234.457s 43:42.15 97.6% 1102.491u 278.194s 25:18.58 90.9% 1182.203u 294.622s 26:12.71 93.9% 1518.402u 310.741s 34:16.96 88.9% 3289.368u 529.669s 1:05:25.90 97.2% installkernel: 5.718u6.898s0:30.97 40.6% 6.655u7.389s0:32.08 43.7% 6.994u7.734s0:33.19 44.3% (...software advance happens here...) FreeBSD 7 on Pentium 4 with 2 GHz and 1 GB RAM: b.world+b.kern: 16574.070u 2516.128s 6:06:03.90 86.9% (with debug) 18232.967u 2427.404s 7:19:49.24 78.2% (with debug) 18992.839u 2569.146s 9:12:00.28 65.1% buildworld: 11457.047u 2151.158s 3:54:15.31 96.8% buildkernel: 3289.368u 529.669s 1:05:25.90 97.2% 3503.732u 524.399s 1:11:05.53 94.4% 4032.019u 572.636s 1:58:29.08 64.7% (with debug) installkernel: 17.396u 12.587s0:46.89 63.9% 18.890u 12.131s1:11.85 43.1% As you can see, 5 hours was a possible value on a single-core single-threat slow-as-ass CPU. But then the system became more advanced, and 7 - 9 hours compile time became possible. :-) *** end quote *** Sadly I don't have a "copy" of my build time on my current home PC, including a Core 2 Duo 4600 with 1.8 GHz and 2 GB RAM, using a SATA disk, with FreeBSD 8-STABLE, but I think it was around 5 hours for everything (including a custom kernel). It would be nice if the build system would automatically issue a log file or at least log message about build time and usage statistics. If it wouldn't tell about my brain's age, I would politely ask to have a "flower box"... ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: igb is broken, even across reboots, at r312294
On 01/16/17 13:52, Alan Somers wrote: > Today I updated my machine from 311787 to 312294. After the update, > my igb ports can pass no traffic. If I reboot into kernel.old, they > still can't pass any traffic. They won't even work in the PXE ROM. I > have to power off, pull the power cables, then boot into kernel.old > before they'll work. This behavior is repeatable. > > $ pciconf -lv > ... > igb0@pci0:1:0:0:class=0x02 card=0x34dc8086 chip=0x10a78086 > rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > igb1@pci0:1:0:1:class=0x02 card=0x34dc8086 chip=0x10a78086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > ... > > $ dmesg # on 311787, it's identical whether or not the igb ports are working > ... > igb0: port > 0x2020-0x203f mem 0xb1b2-0xb1b3,0xb1b44000-0xb1b47fff irq 40 > at device 0.0 on pci1 > igb0: Using MSIX interrupts with 5 vectors > igb0: Ethernet address: 00:1e:67:25:71:bc > igb0: Bound queue 0 to cpu 0 > igb0: Bound queue 1 to cpu 1 > igb0: Bound queue 2 to cpu 2 > igb0: Bound queue 3 to cpu 3 > igb0: netmap queues/slots: TX 4/1024, RX 4/1024 > igb1: port > 0x2000-0x201f mem 0xb1b0-0xb1b1,0xb1b4-0xb1b43fff irq 28 > at device 0.1 on pci1 > igb1: Using MSIX interrupts with 5 vectors > igb1: Ethernet address: 00:1e:67:25:71:bd > igb1: Bound queue 0 to cpu 4 > igb1: Bound queue 1 to cpu 5 > igb1: Bound queue 2 to cpu 6 > igb1: Bound queue 3 to cpu 7 > igb1: netmap queues/slots: TX 4/1024, RX 4/1024 > ... > > $ dmesg # on 312294, when the igb ports are not working > ... > igb0: port > 0x2020-0x203f mem 0xb1b2-0xb1b3,0xb1b44000-0xb1b47fff irq 40 > at device 0.0 on pci1 > igb0: attach_pre capping queues at 4 > igb0: using 1024 tx descriptors and 1024 rx descriptors > igb0: msix_init qsets capped at 4 > igb0: pxm cpus: 8 queue msgs: 9 admincnt: 1 > igb0: using 4 rx queues 4 tx queues > igb0: Using MSIX interrupts with 5 vectors > igb0: allocated for 4 tx_queues > igb0: allocated for 4 rx_queues > igb0: Ethernet address: 00:1e:67:25:71:bc > igb0: netmap queues/slots: TX 4/1024, RX 4/1024 > igb1: port > 0x2000-0x201f mem 0xb1b0-0xb1b1,0xb1b4-0xb1b43fff irq 28 > at device 0.1 on pci1 > igb1: attach_pre capping queues at 4 > igb1: using 1024 tx descriptors and 1024 rx descriptors > igb1: msix_init qsets capped at 4 > igb1: pxm cpus: 8 queue msgs: 9 admincnt: 1 > igb1: using 4 rx queues 4 tx queues > igb1: Using MSIX interrupts with 5 vectors > igb1: allocated for 4 tx_queues > igb1: allocated for 4 rx_queues > igb1: Ethernet address: 00:1e:67:25:71:bd > igb1: netmap queues/slots: TX 4/1024, RX 4/1024 > ... > > Any ideas? > > -Alan > Yeah, fighting with EARLY_AP_STARTUP with regards to initialization of the interfaces. em(4) seems to be ok with my change today, but that change makes igb(4) *very* angry. I'm aware and trying to find a happy medium. sean signature.asc Description: OpenPGP digital signature
Re: Strange issue after early AP startup
On 01/16/17 20:31, John Baldwin wrote: On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote: Hi, When booting I observe an additional 30-second delay after this print: Timecounters tick every 1.000 msec ~30 second delay and boot continues like normal. Checking "vmstat -i" reveals that some timers have been running loose. cpu0:timer 44300442 cpu1:timer 40561404 cpu3:timer 48462822 483058 cpu2:timer 48477898 483209 Trying to add delays and/or prints around the Timecounters printout makes the issue go away. Any ideas for debugging? I have generally used KTR tracing to trace what is happening during boot to debug EARLY_AP_STARTUP issues. Hi John, What happens is that getnextcpuevent(0) keeps on returning "state->nextcall" which is in the past for CPU #2 and #3 on my box. In "cpu_new_callout()" there is a check if "bt >= state->nextcall", which I suspect is true, so "state->nextcall" never gets set to real minimum sbintime. The attached patch fixes the problem for me, but I'm not 100% sure if it is correct. --HPS diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c index 7f7769d..454a130 100644 --- a/sys/kern/kern_clocksource.c +++ b/sys/kern/kern_clocksource.c @@ -511,7 +511,7 @@ configtimer(int start) state->nexthard = next; state->nextstat = next; state->nextprof = next; - state->nextcall = next; + state->nextcall = SBT_MAX; state->nextcallopt = next; hardclock_sync(cpu); } ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
igb is broken, even across reboots, at r312294
Today I updated my machine from 311787 to 312294. After the update, my igb ports can pass no traffic. If I reboot into kernel.old, they still can't pass any traffic. They won't even work in the PXE ROM. I have to power off, pull the power cables, then boot into kernel.old before they'll work. This behavior is repeatable. $ pciconf -lv ... igb0@pci0:1:0:0:class=0x02 card=0x34dc8086 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet igb1@pci0:1:0:1:class=0x02 card=0x34dc8086 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet ... $ dmesg # on 311787, it's identical whether or not the igb ports are working ... igb0: port 0x2020-0x203f mem 0xb1b2-0xb1b3,0xb1b44000-0xb1b47fff irq 40 at device 0.0 on pci1 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 00:1e:67:25:71:bc igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: netmap queues/slots: TX 4/1024, RX 4/1024 igb1: port 0x2000-0x201f mem 0xb1b0-0xb1b1,0xb1b4-0xb1b43fff irq 28 at device 0.1 on pci1 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 00:1e:67:25:71:bd igb1: Bound queue 0 to cpu 4 igb1: Bound queue 1 to cpu 5 igb1: Bound queue 2 to cpu 6 igb1: Bound queue 3 to cpu 7 igb1: netmap queues/slots: TX 4/1024, RX 4/1024 ... $ dmesg # on 312294, when the igb ports are not working ... igb0: port 0x2020-0x203f mem 0xb1b2-0xb1b3,0xb1b44000-0xb1b47fff irq 40 at device 0.0 on pci1 igb0: attach_pre capping queues at 4 igb0: using 1024 tx descriptors and 1024 rx descriptors igb0: msix_init qsets capped at 4 igb0: pxm cpus: 8 queue msgs: 9 admincnt: 1 igb0: using 4 rx queues 4 tx queues igb0: Using MSIX interrupts with 5 vectors igb0: allocated for 4 tx_queues igb0: allocated for 4 rx_queues igb0: Ethernet address: 00:1e:67:25:71:bc igb0: netmap queues/slots: TX 4/1024, RX 4/1024 igb1: port 0x2000-0x201f mem 0xb1b0-0xb1b1,0xb1b4-0xb1b43fff irq 28 at device 0.1 on pci1 igb1: attach_pre capping queues at 4 igb1: using 1024 tx descriptors and 1024 rx descriptors igb1: msix_init qsets capped at 4 igb1: pxm cpus: 8 queue msgs: 9 admincnt: 1 igb1: using 4 rx queues 4 tx queues igb1: Using MSIX interrupts with 5 vectors igb1: allocated for 4 tx_queues igb1: allocated for 4 rx_queues igb1: Ethernet address: 00:1e:67:25:71:bd igb1: netmap queues/slots: TX 4/1024, RX 4/1024 ... Any ideas? -Alan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Strange issue after early AP startup
On Monday, January 16, 2017 04:51:42 PM Hans Petter Selasky wrote: > Hi, > > When booting I observe an additional 30-second delay after this print: > > > Timecounters tick every 1.000 msec > > ~30 second delay and boot continues like normal. > > Checking "vmstat -i" reveals that some timers have been running loose. > > > cpu0:timer 44300442 > > cpu1:timer 40561404 > > cpu3:timer 48462822 483058 > > cpu2:timer 48477898 483209 > > Trying to add delays and/or prints around the Timecounters printout > makes the issue go away. Any ideas for debugging? I have generally used KTR tracing to trace what is happening during boot to debug EARLY_AP_STARTUP issues. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic on boot current amd64
On 01/16/17 11:33, Manfred Antar wrote: >>From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get >>panic on boot. > reverting to r312235 boot ok > > random: harvesting attach, 8 bytes (4 bits) from uhub9 > ugen1.3: at usbus1 > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x64 > fault code= supervisor read data, page not present > instruction pointer = 0x20:0x80660449 > stack pointer = 0x28:0xfe0466aa9010 > frame pointer = 0x28:0xfe0466aa9030 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 60445 (ifconfig) > [ thread pid 60445 tid 100131 ] > Stopped at grouptaskqueue_enqueue+0x19:cmpl$0,0x64(%rbx) > db> bt > Tracing pid 60445 tid 100131 td 0xf800088df500 > grouptaskqueue_enqueue() at grouptaskqueue_enqueue+0x19/frame > 0xfe0466aa9030 > em_intr() at em_intr+0x8c/frame 0xfe0466aa9060 > iflib_fast_intr() at iflib_fast_intr+0x2c/frame 0xfe0466aa9080 > intr_event_handle() at intr_event_handle+0x9b/frame 0xfe0466aa90d0 > intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe0466aa9100 > lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe0466aa9120 > Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfe0466aa9120 > --- interrupt, rip = 0x809639ad, rsp = 0xfe0466aa91f0, rbp = > 0xfe0466aa9200 --- > spinlock_exit() at spinlock_exit+0x2d/frame 0xfe0466aa9200 > smp_rendezvous_cpus() at smp_rendezvous_cpus+0x272/frame 0xfe0466aa9270 > smp_rendezvous() at smp_rendezvous+0x40/frame 0xfe0466aa92a0 > counter_u64_alloc() at counter_u64_alloc+0x3e/frame 0xfe0466aa92c0 > rtentry_zinit() at rtentry_zinit+0x11/frame 0xfe0466aa92e0 > keg_alloc_slab() at keg_alloc_slab+0x1e3/frame 0xfe0466aa9350 > keg_fetch_slab() at keg_fetch_slab+0x16e/frame 0xfe0466aa93a0 > zone_fetch_slab() at zone_fetch_slab+0x9e/frame 0xfe0466aa93e0 > zone_import() at zone_import+0x52/frame 0xfe0466aa9430 > uma_zalloc_arg() at uma_zalloc_arg+0x450/frame 0xfe0466aa94a0 > rtrequest1_fib() at rtrequest1_fib+0xfc/frame 0xfe0466aa95c0 > rtinit() at rtinit+0x390/frame 0xfe0466aa9740 > in_addprefix() at in_addprefix+0xef/frame 0xfe0466aa97b0 > in_control() at in_control+0x9dc/frame 0xfe0466aa9850 > ifioctl() at ifioctl+0xdcc/frame 0xfe0466aa98d0 > kern_ioctl() at kern_ioctl+0x274/frame 0xfe0466aa9950 > sys_ioctl() at sys_ioctl+0x13c/frame 0xfe0466aa9a20 > amd64_syscall() at amd64_syscall+0x488/frame 0xfe0466aa9bb0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0466aa9bb0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x4b194a, rsp = > 0x7fffe478, rbp = 0x7fffe4d0 --- > db> > > > > > Just to make sure, you're running GENERIC? sean signature.asc Description: OpenPGP digital signature
Panic on boot current amd64
>From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get >panic on boot. reverting to r312235 boot ok random: harvesting attach, 8 bytes (4 bits) from uhub9 ugen1.3: at usbus1 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x64 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80660449 stack pointer = 0x28:0xfe0466aa9010 frame pointer = 0x28:0xfe0466aa9030 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 60445 (ifconfig) [ thread pid 60445 tid 100131 ] Stopped at grouptaskqueue_enqueue+0x19:cmpl$0,0x64(%rbx) db> bt Tracing pid 60445 tid 100131 td 0xf800088df500 grouptaskqueue_enqueue() at grouptaskqueue_enqueue+0x19/frame 0xfe0466aa9030 em_intr() at em_intr+0x8c/frame 0xfe0466aa9060 iflib_fast_intr() at iflib_fast_intr+0x2c/frame 0xfe0466aa9080 intr_event_handle() at intr_event_handle+0x9b/frame 0xfe0466aa90d0 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe0466aa9100 lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe0466aa9120 Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfe0466aa9120 --- interrupt, rip = 0x809639ad, rsp = 0xfe0466aa91f0, rbp = 0xfe0466aa9200 --- spinlock_exit() at spinlock_exit+0x2d/frame 0xfe0466aa9200 smp_rendezvous_cpus() at smp_rendezvous_cpus+0x272/frame 0xfe0466aa9270 smp_rendezvous() at smp_rendezvous+0x40/frame 0xfe0466aa92a0 counter_u64_alloc() at counter_u64_alloc+0x3e/frame 0xfe0466aa92c0 rtentry_zinit() at rtentry_zinit+0x11/frame 0xfe0466aa92e0 keg_alloc_slab() at keg_alloc_slab+0x1e3/frame 0xfe0466aa9350 keg_fetch_slab() at keg_fetch_slab+0x16e/frame 0xfe0466aa93a0 zone_fetch_slab() at zone_fetch_slab+0x9e/frame 0xfe0466aa93e0 zone_import() at zone_import+0x52/frame 0xfe0466aa9430 uma_zalloc_arg() at uma_zalloc_arg+0x450/frame 0xfe0466aa94a0 rtrequest1_fib() at rtrequest1_fib+0xfc/frame 0xfe0466aa95c0 rtinit() at rtinit+0x390/frame 0xfe0466aa9740 in_addprefix() at in_addprefix+0xef/frame 0xfe0466aa97b0 in_control() at in_control+0x9dc/frame 0xfe0466aa9850 ifioctl() at ifioctl+0xdcc/frame 0xfe0466aa98d0 kern_ioctl() at kern_ioctl+0x274/frame 0xfe0466aa9950 sys_ioctl() at sys_ioctl+0x13c/frame 0xfe0466aa9a20 amd64_syscall() at amd64_syscall+0x488/frame 0xfe0466aa9bb0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0466aa9bb0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x4b194a, rsp = 0x7fffe478, rbp = 0x7fffe4d0 --- db> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs zvol's inaccessible after reboot
The volmode was set to default, which is geom. Setting to 2, dev fixes the issue! thanks Allan for the speedy solution! On Mon, Jan 16, 2017 at 1:01 PM, Allan Jude wrote: > On 2017-01-16 12:59, Ultima wrote: > > Currently there is a bug with zvols. I have a few Bhyve containers that > > startup at boot. I'v noticed in middle December of last year that after a > > restart the zvols become inaccessible to the container. Nothing can be > done > > to the zvol, other than rename. It cannot even be destroyed in this > state. > > The only way to make it accessible again is to renaming the zvol, after > > this occurs, functionality is restored. > > > > The bug is still present in head r312232. > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > > Is this because they are being used by GEOM? > > Try: zfs set volmode=2 > > Reboot, and see if that solves it > > -- > Allan Jude > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs zvol's inaccessible after reboot
On 2017-01-16 12:59, Ultima wrote: > Currently there is a bug with zvols. I have a few Bhyve containers that > startup at boot. I'v noticed in middle December of last year that after a > restart the zvols become inaccessible to the container. Nothing can be done > to the zvol, other than rename. It cannot even be destroyed in this state. > The only way to make it accessible again is to renaming the zvol, after > this occurs, functionality is restored. > > The bug is still present in head r312232. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Is this because they are being used by GEOM? Try: zfs set volmode=2 Reboot, and see if that solves it -- Allan Jude signature.asc Description: OpenPGP digital signature
zfs zvol's inaccessible after reboot
Currently there is a bug with zvols. I have a few Bhyve containers that startup at boot. I'v noticed in middle December of last year that after a restart the zvols become inaccessible to the container. Nothing can be done to the zvol, other than rename. It cannot even be destroyed in this state. The only way to make it accessible again is to renaming the zvol, after this occurs, functionality is restored. The bug is still present in head r312232. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: recent change to vim defaults?
> On 16 Jan, 2017, at 9:25, Baptiste Daroussin wrote: > > On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote: >> I noticed that suddenly vim is grabbing mouse movements, which makes life >> really hard. >> >> Was there a specific revision that brought in this change, and can it be >> removed? > > This change appeared in one of the last patchset of vim 7.4 and was one of the > "features" of the vim 8.0 release. > > I do agree this is just totally painful :( > > Best regards, > Bapt One of the things that I inherited with the Vim port was the DEFAULT_VIMRC option (which installs /usr/ports/editors/vim/files/vimrc), and I haven't touched it. I have moused disabled in all my boxes so I have no idea about bad mouse behaviour in Vim. If there is a bad default that is causing grief, let's just fix it in that default vimrc. I'm not really understanding what the unexpected behaviour is so I can't make an intelligent recommendation myself, but I'll go with whatever you folks suggest. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: recent change to vim defaults?
On Mon, Jan 16, 2017 at 07:46:41PM +0300, Slawa Olhovchenkov wrote: > On Mon, Jan 16, 2017 at 05:25:26PM +0100, Baptiste Daroussin wrote: > > > On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote: > > > I noticed that suddenly vim is grabbing mouse movements, which makes life > > > really hard. > > > > > > Was there a specific revision that brought in this change, and can it be > > > removed? > > > > This change appeared in one of the last patchset of vim 7.4 and was one of > > the > > "features" of the vim 8.0 release. > > > > I do agree this is just totally painful :( > > Wat about edit 8-bit files in utf-8 locale? > Still corrupted files? What are you speaking about I never had this issue with vim We had this issue with vi in base which is now worked arounded so it just fails so save instead of corrupting (which is still bad but a bit better :)) Bapt signature.asc Description: PGP signature
Re: recent change to vim defaults?
On Mon, Jan 16, 2017 at 05:25:26PM +0100, Baptiste Daroussin wrote: > On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote: > > I noticed that suddenly vim is grabbing mouse movements, which makes life > > really hard. > > > > Was there a specific revision that brought in this change, and can it be > > removed? > > This change appeared in one of the last patchset of vim 7.4 and was one of the > "features" of the vim 8.0 release. > > I do agree this is just totally painful :( Wat about edit 8-bit files in utf-8 locale? Still corrupted files? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: recent change to vim defaults?
On Mon, Jan 16, 2017 at 12:03:08AM +0800, Julian Elischer wrote: > I noticed that suddenly vim is grabbing mouse movements, which makes life > really hard. > > Was there a specific revision that brought in this change, and can it be > removed? This change appeared in one of the last patchset of vim 7.4 and was one of the "features" of the vim 8.0 release. I do agree this is just totally painful :( Best regards, Bapt signature.asc Description: PGP signature
Re: Re: recent change to vim defaults?
___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Strange issue after early AP startup
Hi, When booting I observe an additional 30-second delay after this print: Timecounters tick every 1.000 msec ~30 second delay and boot continues like normal. Checking "vmstat -i" reveals that some timers have been running loose. cpu0:timer 44300442 cpu1:timer 40561404 cpu3:timer 48462822 483058 cpu2:timer 48477898 483209 Trying to add delays and/or prints around the Timecounters printout makes the issue go away. Any ideas for debugging? Looks like a startup race to me. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does someone keep track of how long it takes to buildworld/kernel?
On 13 January 2017 at 12:23, Eric Joyner wrote: > > It takes forever, but I keep on forgetting to time how long it takes, so I > don't know how long "forever" is. My last buildworld on a severely under powered i386 for 11stable: 420:41 minutes Build kernel is around 85 minutes. How I track: https://github.com/dschep/ntfy + https://pushover.net I get a notification on my phone, otherwise I would forget to check and/or check too frequently. I set it up in a tmux session and detach until it's finished. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TSC as timecounter makes system lag
On Mon, Jan 16, 2017 at 8:00 PM, Konstantin Belousov wrote: > On Mon, Jan 16, 2017 at 12:28:54PM +0800, Jia-Shiun Li wrote: > > BTW please see my other mail of this thread. It seems to be related to > > EARLY_AP_STARTUP option. > Yes, I noted, I might have an idea, but the report that changing the > timecounter makes the lags go away still does not fit into my understanding > of the code. > > Most likely this is an interaction between the EARLY_AP_STARTUP and the > fact that HPET interrupt is global, while most modern systems use LAPIC > event timer, which is per-cpu, and the testing of the option was done > on them. There are some differences in handling the configurations, see > sys/kern/kern_clocksource.c, the option and ET_FLAG_PERCPU. > > And, changing the _timecounter_ fixes the issue ? Can you double-check > this ? > Yes. I noticed this because systat refreshes looked slower, and keystroke did not repeat smoothly for 30/s. I have system clock shown on tmux status line. On c2d it drifted away. Setting timecounter brings it back to normal. See also eventtimer & timecounter tests below. > > With the settings above, i.e. HPET for both eventtimer and timecounter, > please show vmstat -ia output for two times with the interval of 2 secs. > Attached. > > What if you change _eventtimer_ to APIC and then immediately back to HPET, > does the problem go away ? > > It doesn't look so. But keeping LAPIC as eventtimer helps. jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer.timer=LAPIC && sysctl kern.eventtimer.timer=HPET && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.eventtimer.timer: HPET -> LAPIC kern.eventtimer.timer: LAPIC -> HPET 16 Jan 22:00:21 ntpdate[8472]: step time server 203.71.244.7 offset 18.980716 sec 16 Jan 22:01:56 ntpdate[8601]: step time server 103.226.213.30 offset 58.813079 sec jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer.timer=LAPIC && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.eventtimer.timer: HPET -> LAPIC 16 Jan 22:02:36 ntpdate[8666]: step time server 103.226.213.30 offset 19.773086 sec 16 Jan 22:03:13 ntpdate[8776]: adjust time server 103.226.213.30 offset 0.000455 sec jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer.timer=HPET && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.eventtimer.timer: LAPIC -> HPET 16 Jan 22:03:47 ntpdate[8853]: step time server 103.226.213.30 offset 6.344004 sec 16 Jan 22:05:18 ntpdate[8975]: step time server 61.216.153.105 offset 54.908872 sec jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=HPET && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.timecounter.hardware: TSC-low -> HPET 16 Jan 22:06:29 ntpdate[9073]: step time server 59.124.29.241 offset 39.211691 sec 16 Jan 22:07:05 ntpdate[9185]: adjust time server 61.216.153.105 offset 0.001015 sec jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=TSC-low && ntpdate tw.pool.ntp.org && sleep 30 && ntpdate tw.pool.ntp.org kern.timecounter.hardware: HPET -> TSC-low 16 Jan 22:07:28 ntpdate[9244]: step time server 61.216.153.105 offset 3.122954 sec 16 Jan 22:08:58 ntpdate[9357]: step time server 61.216.153.104 offset 53.758451 sec jsli@jsli-bsd:/home/jsli # > Also, if you set the loader tunable kern.eventtimer.timer to LAPIC, > and do not enable C2+, does the system boot into the usable state ? > > Not sure if you mean disabling C2 from BIOS. Right now I don't have BIOS access to the c2d, and my notebook only has minimal BIOS settings to play with. Anyway on notebook set kern.eventtimer.timer=LAPIC in loader prompt to boot , and the system still lags. But after setting sysctl dev.cpu.0.cx_lowest=C1 && sysctl dev.cpu.1.cx_lowest=C1 system clock returns to normal speed. -Jia-Shiun. jsli@jsli-bsd:~ % vmstat -ia 2 2 interrupt total rate ???0 0 irq1: atkbd0 2 0 stray irq1 0 0 irq0: attimer0 0 0 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 irq4: uart00 0 stray irq4 0 0 irq5: 0 0 stray irq5 0 0 irq6: 0 0 stray irq6 0 0 irq7: 0 0 stray irq7 0 0 irq8: atrtc0 0 0 stray irq8 0 0 irq9: acpi00 0 stray irq9 0 0 irq10: 0 0 stray irq100 0 irq11:
Re: TSC as timecounter makes system lag
On Mon, Jan 16, 2017 at 12:28:54PM +0800, Jia-Shiun Li wrote: > BTW please see my other mail of this thread. It seems to be related to > EARLY_AP_STARTUP option. Yes, I noted, I might have an idea, but the report that changing the timecounter makes the lags go away still does not fit into my understanding of the code. Most likely this is an interaction between the EARLY_AP_STARTUP and the fact that HPET interrupt is global, while most modern systems use LAPIC event timer, which is per-cpu, and the testing of the option was done on them. There are some differences in handling the configurations, see sys/kern/kern_clocksource.c, the option and ET_FLAG_PERCPU. > > > On Mon, Jan 16, 2017 at 4:20 AM, Konstantin Belousov > wrote: > > > I still do not understand. Is the sysctl output below from the pristine > > boot where no timecounter/eventtimer reconfiguration were done ? > > > > Show me exact command which you used to revive the machine. Do not > > describe > > it by words, copy/paste from the console. > > > > > Don't have access to the exact machine right now. > Let me reproduce it on another with a c2d E7400. > > login as: jsli > Authenticating with public key "rsa-key-20160711@jsli-pc" > Last login: Mon Jan 16 11:11:28 2017 from tmux(1074).%1 > FreeBSD 12.0-CURRENT (GENERIC-NODEBUG) #24 r312210: Sun Jan 15 15:03:40 CST > 2017 > > Welcome to FreeBSD! > > Release Notes, Errata: https://www.FreeBSD.org/releases/ > Security Advisories: https://www.FreeBSD.org/security/ > FreeBSD Handbook: https://www.FreeBSD.org/handbook/ > FreeBSD FAQ: https://www.FreeBSD.org/faq/ > Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd- > questions/ > FreeBSD Forums:https://forums.FreeBSD.org/ > > Documents installed with the system are in the /usr/local/share/doc/freebsd/ > directory, or can be installed later with: pkg install en-freebsd-doc > For other languages, replace "en" with a language code like de or fr. > > Show the version of FreeBSD installed: freebsd-version ; uname -a > Please include that output and any error messages when posting questions. > Introduction to manual pages: man man > FreeBSD directory layout: man hier > > Edit /etc/motd to change this login announcement. > jsli@jsli-bsd:~ % sysctl kern.eventtimer kern.timecounter > kern.eventtimer.periodic: 0 > kern.eventtimer.timer: HPET > kern.eventtimer.idletick: 0 > kern.eventtimer.singlemul: 2 > kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) > LAPIC(100) i8254(100) RTC(0) > kern.eventtimer.et.HPET3.quality: 440 > kern.eventtimer.et.HPET3.frequency: 14318180 > kern.eventtimer.et.HPET3.flags: 3 > kern.eventtimer.et.HPET2.quality: 440 > kern.eventtimer.et.HPET2.frequency: 14318180 > kern.eventtimer.et.HPET2.flags: 3 > kern.eventtimer.et.HPET1.quality: 440 > kern.eventtimer.et.HPET1.frequency: 14318180 > kern.eventtimer.et.HPET1.flags: 3 > kern.eventtimer.et.HPET.quality: 450 > kern.eventtimer.et.HPET.frequency: 14318180 > kern.eventtimer.et.HPET.flags: 3 > kern.eventtimer.et.RTC.quality: 0 > kern.eventtimer.et.RTC.frequency: 32768 > kern.eventtimer.et.RTC.flags: 17 > kern.eventtimer.et.i8254.quality: 100 > kern.eventtimer.et.i8254.frequency: 1193182 > kern.eventtimer.et.i8254.flags: 1 > kern.eventtimer.et.LAPIC.quality: 100 > kern.eventtimer.et.LAPIC.frequency: 0 > kern.eventtimer.et.LAPIC.flags: 15 > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > dummy(-100) > kern.timecounter.hardware: TSC-low > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 5046106 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 1449012340 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 10698 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1400076588 > kern.timecounter.tc.TSC-low.counter: 2260820915 > kern.timecounter.tc.TSC-low.mask: 4294967295 > jsli@jsli-bsd:~ % su > Password: > jsli@jsli-bsd:/home/jsli # sysctl kern.timecounter.hardware=HPET > kern.timecounter.hardware: TSC-low -> HPET > jsli@jsli-bsd:/home/jsli # sysctl kern.eventtimer kern.timecounter > kern.eventtimer.periodic: 0 > kern.eventtimer.timer: HPET > kern.eventtimer.idletick: 0 > kern.eventtimer.singlemul: 2 > kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) > LAPIC(100) i8254(100) RTC(0) > kern.eventtimer.et.HPET3.quality: 440 >