[illumos-gate] 17863 libsff_8472 test needs update to libsff_8472.out post-17827 -- Jason King <jason.brian.king⊙gc>

[illumos-gate] 17855 bhyve: VirtIO devices do not support MSI -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 17869 aio_done: concurrent pollq completions race with aio_cleanup_exit -- Andy Fiddaman <illumos⊙fn>

tsoome: pasteboard.co/M7aqSd1zk20m.png ever seen that before?

thats a lot of memory to allocate... for contiguous chunk.

uefi? no i have not seen it, but with uefi I would not be too surprised...

oh I didn't check to see if it was doing a UEFI boot or not.. I just sort of assumed it was...

show efi-version

ok it is uefi

let me open up this ISO image and see if I can figure out why the archive was that large..

memmap will show the current map, but thats more like statistics... we can not do much about it.

hrm.. the boot archive itself is about 200MB.. though that's compressed...

i'm guessing that's probably the uncompressed amount? e.g. loader uncompresses it when it reads it into memory?

uncompressed, yes. because thats how our current "rootfs" image implementation is built. I guess its coming from time where ufs was considered to be good choice there and block level compression was not there at the time;)

or hsfs for that matter...

having to have every go binary have it's own copy of the go runtime probably doesn't help with size :)

hmm.. but even omnios seems to either take a _really_ long time, or is hanging (but it does at least jump into the kernel)

(it's a dell amd box)

why do you have go in your boot archive?

that should be things we need to boot and mount root, exclusively.

(see also why /usr/kernel, even, isn't there)

that depends on the desired outcome, isnt it so;)

sure, that's why I'm asking what the desired outcome is

i mean binaries written in go

me too

whicn includes our isntaller

ok, ok

and our install image

so it's not a boot archive it's a miniroot

pulls lever, moves points, switches tracks

though doesn't seem to matter... even this omnios ISO is hanging after it enumerates the serial ports

and sending an NMI (despite kmdb being set) seems to be acting like the goggles

(does nothing)

can you hit esc fast enough to play around at the prompt?

and then toomas can show you memory maps, etc.

and do your install images contain the boot archive hash?

if we even get far enough to try to check it :(

I think the first thing I would like to know is whether the memory I put the boot archive contents in actually exists

and the second thing is to double check it's actually memory

... and of course kmdb also doesn't accept keypresses..

i really need to figure out what the missing bit there...

because like I don't think I've found a server less than 5 years old where kmdb works from whatever BMC's KVM they have

well at least 5 years old...

not the easiest thing, given your debugger and keyboard don't work

but I guess I'd start on where we poll and hope for the best from there

printf and dreams

worth checking whether it never works, or whether `-d` is just too soon, too

dropping on at boot doesn't work at least..

err in

i'm hoping i can maybe get SOL working

though every vendor makes it more complicated than it probably shuold be

since I think almost no one uses it (but perhaps us)

tsoome: if i change the serial port settings, is tehre a way for loader to 'reread' them?

change where?

in firmware?

well loader spits out one line and then nothing when I setup console redirection

your port is 115200?

yes

booting from disk?

ISO

well trying to at least

does it provide /boot/solaris/bootenv.rc?

i have no idea, i'm trying an omnios iso since it seems to be slimmer

and it can at least load the kernel

it probably does. if the firmware allows, set port to 9600

problem is, bootenv.rc is delivered with port settings 9600,8,n,1,- and it will override what you get from firmware...

(and some systems will hung when you try to do that, and some systems will just lose input till kernel driver is loaded).

i see loading /boot/defaults/loader.conf then nothing

from the serial consoel window

yes, because bootenv.rc does its thing....

heh..

yeah, that's what toomas is trying to explain I think

we need defaults that are good and carry through

but ug

so I changed the setting in bios to 9600... still that from loader, but then if I do select ttyb, the kernel actually prints out on ttyb

like, loader should know things, and should tell the OS what it learned, and the OS should trust it

like anything else that goes through the bootinfo

right?

or does x86 have a smarter way to get early console access?

code.illumos.org/c/illumos-gate/+/3327

→ CODE REVIEW 3327: 16330 loader: SPCR needs better handling (NEW) | illumos.org/issues/16330

we can make some steps to protect us, but IMO its time to nuke tty lines from bootenv.rc.

right that's what I meant, shouldn't the default be "discovered from loader"

given here in the future, it's not really a predictable thing

9600,8,n,1 is not a great default anymore, and it's not obviously there's a better one

the 8,n,1 are fine I suppose

yep

on the plus side, using bloody seems to get to userland, but then can't find the install media... so progress

(given the stable was dieing after enumerating teh asy devices, I wonder if maybe some of those fixes are the difference)

that sounds plausible

unfortunately, the fixes came before the debugging help

but your console is on serial, so you can not boot -B disable-asy=true ?:)

yeah, I'd still like to figure out what needs to be done for kmdb to work better

on aarch64 we still don't/can't use asy, for unknown reasons

I keep meaning to merge the newer fixes and see if they fix the older fixes

rather than having an Nth copy/paste of that driver

kmdb as started with -kd?

I believe jbk had said so

that's why I asked if `-d` was just too soon to work in that context

I have considered, again on aarch64, adding a separate debug_enter later in boot when we were firing on all cylinders

like, just before sched()

so `-d` was as soon as possible, and a hypothetical `-D` was when everything would definitely work

kmdb does basically rely on keyboard IO port acess, but if the keyboard is usb device and they did stop providing the emulation.... then there is no keyboard for kmdb.

I was pretyt sure kmdb would poll usb in a weird cooperative way

jlevon: memory man?

kmdb loaded with -k may have chance for that, if it will bind itself to usb keyboard (with poll mode available), but -kd can not, usb is not available for i86pc/boot/ bits.

altho, it would be nice if kmdb would continue on its own when started with -kd and there is no usable input device...

I have no memory of kmdb doing usb io stuff. but my memory is ... weak

I thought I'd run into something with polledio in the name that seemed like magic that looked like it was for that, when I was porting

but my memory is no bettter

it does look like there is code that steals cons_polledio and uses it

but as tsoome said, not that early in boot

(which is where my `-D` idea came in, where it could help)

yeah, that exists. just dunno if or how that does usb. only ever explicitly saw it doing port io

yeah, probably need usb to do polling...

well assuming these virtual devices are presented as USB

richlowe: yeah, -D as you describe it makes sense as a pragmatic measure when the console is iffy.

oh to have PCI ID decoding in kmdb :)

while loader seems to dislike the serial port, after tweakign the speed in the BIOS setting, the kernel seems ok with it...

and omnios bloody gets to userland

except that we don't seem to attach any drivers for the virtual cdrom

tsoome: how is loader allocating that memory? is it calling AllocatePool or AllocatePages() ?

for modules? AllocatePages(), see efi/loader/copy.c

but. when we are to jump to kernel, we switch off boot services (so we will "own" the machine - no more memory map changes), we copy kernel in place (fixed location - we need to pray hard its actually usable), followed by modules -- the final location must be below 4GB or dboot will blow us up (32-bit code).

we should fix that

though nothing you can do about the fixed kernel

well, nothing you should do on a whim anyway

a pic kernel is possible, but frustrating to debug. a pie kernel is probably an adventure too far, unless you _really_ need it

there's downsides to all of loader relocating unix, dboot relocating unix, and unix relocating unix

references internal to unix, that is.

better have some sleep...

i kinda want to take the zfs bits from loader and turn it into a UEFI filesystem driver (so you could also for example have zpool / zfs commands from the uefi shell or browse a dataset (read only))