sommerfeld: one thing i haven't looked at is what the cost is if a disk is offlined for a 'long' time... e.g. does it just note the last txg in the offline case and just start from there, or is more state kept in the rest of the pool that could potentially be problematic if left that way for too long..

if the former, i wonder if it might just be better if either state did the same thing and the distinction is more of just expressing intent

or 'any reason not to allowed a REMOVED disk to just catch up instead of a full resilver if re-inserted' ?

jbk: The former. DTL "dirty time log" is in terms of TXGs and is used to prune the resilver when it comes back online.

[illumos-gate] 15391 Add support for Emulex LPe35000/LPe36000 32Gb/64Gb fibre channel chipsets -- Carsten Grzemba <cgrzemba⊙oo>

github.com/illumos/illumos-gate/blo…scsi_vhci/common/mp_utils.c#L26-L52 -- hmm....

someone using a terminal window with < 10 lines? :)

DUMB question...

If I boot a kernel with the `-kd` flags set (IOW, drop right to kmdb before anything else) has that passed through dboot already? I believe the answer is "yes", but I want to make damned sure.

Yes.

Good.

Thank you! (Means my problems with iPXE-booting the NUC 11 are in illumos itself, likely due to the lack of a console device. My next questions are likely best asked to tsoome directly, but I have errands to run and a short day today.)

[illumos-gate] 16269 SMB could allow persistent opens on directories -- Gordon Ross <gwr⊙rc>

danmcd: if you can pass an /etc/system, might be worth trying forcing the hpet for tsc calibration

i don't know what gen NUC I have here, but the problem with it was that it has no PIT

and there's no reliable way to detect it (i tried basically 'based on a reasonable range of clock speeds from the past 15+ years, we should see _some_ progress after x TSC ticks')

to detect if it was there/broken or not, but it's obviously just a hueristic

though if that works, I'm not sure how to fix the problem of (apparently) shitty HPETs since all the ones I have access to return results more accurate and consistent than using the PIT (or for the NUC w/o a PIT, compared to the known frequency)

but apparently people out there have ones that result in worse results that causes clock drift

does ACPI or whatever not reliably tell you if you have a usable PIT?

[illumos-gate] 16264 spray: 'usecs' defaults to 'int' -- Toomas Soome <tsoome⊙mc>

i've not found any tables that tell you

i couldn't find anything that tells you if the system has one or not

[illumos-gate] 16259 in.comsat: 'offset' defaults to 'int' -- Toomas Soome <tsoome⊙mc>

CPUID leaf 15 _might_ tell you the speed, though I've yet to locate a system that reports the divisor

so i've not put up any code that uses that

Given what's in FreeBSD, it /must/ exist somewhere :)

(I also have not found any system with it)

(teh NUC i have comes close -- you get the numerator, but not the denominator)

well FreeBSD (and Linux) will use the frequency from leaf 16 if there

even though the docs say 'yeah, it's not really meant for that'

but i've not even attempted that because I'm not going to fight the inevitable code review 'yes the vast majority systems in existence will do this, but because technically they shouldn't i'm going to object to all of this'

that will come up from doing that

[illumos-gate] 16256 backup: type of 'status' defaults to 'int' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16257 bnu: parameters default to int -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16253 ypcmd: type of parameter defaults to 'int' -- Toomas Soome <tsoome⊙mc>

Just got back, I'll try that hpet thing, jbk!

@jbk without setting to use hpet in /etc/system, will the NUC *panic* ?

'cause my (can't see) misbehavior is reboot-after-iPXE *UNLESS* "-kd" or "-k" is used as a UNIX flag.

(Suggesting we panic in illumos, but I can't *see* the panic thanks to iPXE -> illumos handoff with UEFI-only console)

it depends i think on what happens with the PIT calibration

do you not see anything at all?

even without kmdb, prom_debug=1 should let you see what's happening with the TSC calibration (and if it gets past that or not) if you can view any console output

I don't see ANYTHING AT ALL. It's like whatever loader does to the EFI console (which I know works because with igc(4D) the NUC 11 boots from USB key with oddness and disk without), iPXE is failing to do.

And my earlier confirmation from RM about yes-we're-past-dboot (which I've confirmed thanks to using just "-k" to unix), is that we're panicking somewhere, but with no console (and no easy serial on NUC) I'm just screwed.

Not like NUCs-as-Triton-Compute-Nodes is a big deal.

I'm also downrev on the NUC Firmware, so there's a chance something there is broken.

loader does call gop->Blt() to put stuff on screen unless BS are switched off. (see gfxfb_blt() in boot/common/gfx_fb.c). This means, if there is no memory mapped framebuffer, we can still see output on loader local console, but, this also means, without memory mapped framebuffer, gfx_private in our kernel can not draw.

so without memory mapped fb, only serial console is possible...

s/are/is/

unfortunately, it sounds like ixpe does something different

danmcd: just to ask, is it the triton ixpe or the upstream ixpe? ISTR there were some local changes in the triton one that never were accepted upstream (though I don't think ones that would matter for this)

there is only 3 things it can possibly do -- in gfx mode either use gop->Blt or direct fb rendering (memory writes), or use SimpleTextOutput protocol to write to console.

ofc SimpleTextOutput protocol is part of boot services, as soon as BS is switched off, that mechanism is gone.

(same for GOP).

I did default to use gop->Blt() to keep visible console in case there is no FB and in hope it might have some internal optimizations to get images on screen fast(er).