jclulow: yeah, i'd like to fix that as well (HPET) if no one else gets to it before I can (since it was my fault).. it would be nice if it was just a matter of increasing the sample interval to a sufficiently larger value, but i'd want to re-do the math and if i'm lucky maybe see if someone that had issues could test the fix

since on the systems I had available, apprently the particular model HPET was good enough that it produced basically identical (and more consistent) results than the PIT

so they're probably not good systems to verify any fix

jbk: Everybody had issues haha

So it won't be hard to find them

Like, it's structurally likely to produce a consistently high result right now, at least based on surveys and the ppm maths

So if you want to bump the interval it may indeed be an easy change

Anybody ever had cc1plus: out of memory allocating 262144 bytes after a total of 4251648 bytes ?

VM has 16Gb RAM

toasterson how much swap ?

I tried with 2GB and none

What does swap -s says ?

total: 85172k bytes allocated + 16948k reserved = 102120k used, 5424584k available

thats with no swap device

with no swap device and max concurrent jobs 1 it works

jbk: was that the change that caused massive clock drift with ntpd and bhyve to randomly lock up because it's. ??vcpu rendeavous failed??

My Ivybridge suffered hard from this, box is now gone though. There is a broadwell in it's place.

sjorge: Yes, if you were seeing NTP drift values of 500-1000 ppm that's pretty likely to have been the cause

Toasters try increasing swap and try again

toasterson try increasing swap

Is it possible to replicate in VMware or any other hypervisor to not use virtio legacy devices?, the main idea is to try working on virtio to attach a nic on the new spec

vmware does not do virtio; modern qemu on linux should have those though?

yuripv oh right, thanks

neirac: I also took another look at the spec last night. It turns out the Id 0x1000 is a transitional device, meaning it'll support both the legacy and new format. This means that you should actually be able to just add that PCI ID 14af,1000 to vioif and it may wokr.

*work

rmustacc thanks a lot!, where do I need to add 14af,1000 is there a kernel/drv/virtio.conf ?

In smartos

I would first test this by manually running update_drv

rmustacc. I tried update_drv -a -i '"14af,1000"' virtio but failed to attach

That's the wrong driver.

You need to add that to 'vioif'

update_drv -a -i '"14af,1000"' vioif returns devfsadm: driver failed to attach, I checked in /etc/driver_aliases and the alias is there vioif "14af,1000"

OK. Is there anything in /var/adm/messages?

rmustacc I don't see anything related to vioif in /var/adm/messages

Did you delete the 14af,1000 relation to virtio?

neirac: Sorry, I should have looked closer. You didn' do quite the right thing. You want it to be:

update_drv -a -i '"pci14af,1000"' vioif

rmustacc I tried again but did not attach pastebin.com/pTCgbnuf

neirac: with 50G of swap I now get `g++: internal compiler error: Bus Error (program cc1plus)`

must be doing a lot of pre-processing

toasterson what are you building?

binutils-gdb from the arm64 gate

single make job?

I had to serialize gmake in many places, that build is fork bomb

3

oh, is it the problem with the process server passing in makefiles?

we had one like this in OI userland

toasterson maybe you could check kstats when the thing is building

eh, not if it's parallelism errors I don't want to waste time on fork bombs like this. It just has to build so I can get to the things I actually wanted to use to help.

Here is me hoping fo better tools

pgrep make | wc -l

that will give some idea

or pgrep gcc\|g++ | wc -l

yep. For binutils-gdb I simply had to remove the -j argument from the make that was called by the makefile so that was easy enough :) The main Makefile I now set to NOTPARALLEL

and since I am in there i might aswell fix KEEP_STATE

neirac: OK. I think the thing to do is to either build a SmartOS image with a fixed /etc/driver_aliases, or try to debug the attach failure with dtrace and triggering the attach with the `devfsadm` command.

rmustacc I'll do that I'll create a omnios image now with the alias

Others have the transitional ID, so it seems likely to work. Not sure why vioscsi wasn't coming up there though.

the builds as they default aren't _that_ parallel toasterson

I mean, they do make the logs all unreadable because gmake, but they should not make anything explode

richlowe: Welcome to the should not make things explode defaults of gmake :) Oi-userland is notorious for components that cannot run with paralellism enabled. It's our most frequent CI failure

rmustacc I cannot use dtrace as I used kmdb to modify the is_pit_broken variable to make it boot, I'll create a new image with the /etc/driver_aliases

Is going to take time, my pc is slow and my connection is not very fast as now I'm running pkg update will take some hours.

we read etc/system earlier than you'd think, you might be able to poke is_pit_broken in there.

or set it on the kernel command line (I'm less sure about that)

i don't think you can set that one from the bootloader -- ISTR I had to explicitly check for specifying an explicit source because of when this all happens in the boot process

though it likely wouldn't take much to change that

richlowe: The SMF issues you had on ARM. Where they in an way related to nvlists?

*any

no

Good :)

today is the day I am finding ALL the bugs

toasterson there are free ampere instances on oracle cloud, they have lots of cpu and ram maybe that's helpful for arm64 porting

there's no support for the ampere stuff

and I'm not sure if anyone's cloud-accessible stuff is sufficiently useful for right now

richlowe oh that's right at least you could test that It boots

it definitely doesn't :)

@jclulow yep around that range