Re: Does someone keep track of how long it takes to buildworld/kernel?

[Polytropon]

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

[Sean Bruno]

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

[Hans Petter Selasky]

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

[Alan Somers]

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

[John Baldwin]

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

[Sean Bruno]

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

[Manfred Antar]

>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

[Ultima]

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

[Allan Jude]

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

[Ultima]

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?

[Adam Weinberger]

> 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?

[Baptiste Daroussin]

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?

[Slawa Olhovchenkov]

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?

[Baptiste Daroussin]

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?

[ohauer]

___
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

[Hans Petter Selasky]

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?

[jungle Boogie]

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

[Jia-Shiun Li]

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

[Konstantin Belousov]

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)
>