[illumos-gate] 17903 loader: expose addresses of firmware tables in loader env -- Toomas Soome <tsoome⊙mc>

Hello. I can't seem to find a way to get Illumos (Tribblix) to work with KVM/qemu on a Linux host. It always panics after the welcome message after loading the kernel. I've tried all kinds of combinations of virt-install options (--os-variant openindiana,solaris10/11, i440fx, q35... ) but nothing works. Information on this is extremely sparse on search engines. Is there a magic virt-install incantation and best practices to get it to work?

What goes furthest so far: privatebin.net/?521c6d0a57fcc3bc#D9…uBXMwCv8gPVyj7JP2srdjTwgjvGzXMt7rry

a better way is to share the panic info

Here is the panic info: privatebin.net/?cdae4f8181580a97#HY…NnUKoUDraMFixbFwg3H5i2XiG7xnYSkuBj1

you can boot with -kv flags, it will stop in kmdb instead of rebooting

somebody broke src.illumos.org, I got 502 bad gateway

denk: privatebin.net/?f5d740e028c4caa0#Dt…Zrq2fQywh3JSVJPQU14hQkqP6imRm1Bu4EY

Bad kernel fault at addr=0xfffffe0b8b006370

type 0xfffffe0b8b006370::whatis

or without 0x...

fffffe0b8b006370 is unknown

Can you show the output of "$C -vt" ?

(quotes are mine)

andyf: privatebin.net/?c3f300f88d996ef3#CS…5yXKroycgorFRmk41zSpb44TtQituoFHHdE

and "::regs"?

startup_modules+10a::dis

I would disassemble startup_modules near the point 0x10a to locate it in the source code

I think this is going to be the smbios_open() call

we don't see it in the backtrace, it is somewhere else

90% that is an unexpected field for the parser

Would you like me to type in more commands in the debugger?

Yes, please do "startup_modules+10a::dis"

indeed, the problem somewhere in smbios_open()

*is somewhere

there are 6 points with bcopy() inside the function

DptPirate - if qemu has options to control the smbios information presented to the guest I suggest playing with a few of them to see if you can get past this, but it is a bug that it panics.

does 'show' from loader oK prompt list smbios data?

tsoome: "kmdb: failed to dereference symbol: unknown symbol name"

andyf: I'll have to investigate this.

not from mdb but from loader ok prompt (press esc in boot menu)

tsoome: privatebin.net/?2e304b1880640bac#3U…3BwMoDukm5JG9kGDLLZezWAUBPMwhNWsJjj

It looks like there is smbios info in that dump

yes, its bios boot and you do have smbios.

Would using EFI instead help?

wont hurt to try.

ok I'll try that in a bit.

Unfortunately doesn't get to the boat loader (privatebin.net/?0726237e6e2439bd#37…iaQKTbgSmkGqzuVfrhvtWAEq2KXL4RWh5Xa). And using EFI somehow hosed libvirtd.

7 is device error - device did report an error condition.

[illumos-gate] 18027 smbd: dereferencing freed memory -- Toomas Soome <tsoome⊙mc>

it wouldn't be the first time virtualized media doesn't behave correctly

though i wonder if maybe the VM config is missing some parameters

though it does remind me... anyone want to review code.illumos.org/c/illumos-gate/+/4…common/io/sata/adapters/ahci/ahci.c ?

→ CODE REVIEW 4679: 18011 ahci could handle buggy emulators better (NEW) | illumos.org/issues/18011

^^^ done

thanks

so I'm more stupid even than usual lately, and I have a question: Why is `ctrun nightly ...` insufficient to 1) catch the children of make(1) in nightly's contract, 2) keep the contract up until they all quit?

[illumos-gate] 18040 vtfontcvt: struct file_header needs __nonstring attribute -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 17992 libdevinfo: enable smatch and fix issues -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 13157 maxbw can kill link with hires tick -- Kyle Simpson <kyle⊙oc>

[illumos-gate] 18078 snoop should report drops when capturing to file -- Ryan Zezeski <ryan⊙zc>

I guess the person who approved 18078 didn't copy the list?

or is my mail fucking up?

No... turns out MY mail is fucking up. Engaging with my local mail-runners now. I'm super-pissed.

Four mails got gagged, the fourth was a test email.

richlowe: the ctrun thing is mystifying (as I don't see how children wouldn't get attached barring something in an intermediate process detaching them). Unless the newtask invocation does something weird to the contract..

if there's a long enough running child, could you use ps to look at the contract ids of the children?

or maybe ptree -c[g] ?

i tripped over illumos.org/issues/18083 just now and i'm wondering what a good way to improve things would be. maybe just changing pbind -u output when a pid has >1 (bound?) lwp?

→ BUG 18083: pbind -u is confusing with LWPs (New)

i struggle to imagine processor_bind() returning One Of The Previously Bound Processors to be useful if LWPs are bound in interesting ways, but going and just changing *that* feels pretty reckless :D

Specifically you didn't specify an lwp right?

right, just unbound the whole pid

I think it's probably impractical for it to report all unbindings.

Which doesn't answer the question.

But maybe reduces the state?

s/state/space

why do you think it's impractical? that's actually one of the options i was considering. it's just annoying to go through each lwp when we really want to unbind them all. that's what we'd do with something like pid/0-

that's just clumsy when we know we want P_PID and the old bindings aren't necessarily that interesting

Well, I assume you could have probably at least 10k+ threads with bindings.

And so that's a lot of data to copy out.

oh, yeah

And you don't even know how much memory to hold to get it all.

The other thing and the reason it's differnt with walking all threads is that you're able to do it in one atomic-ish action.

Where as the other mechanism allows the process reign to move and have others intervene.

yeah

i was wondering what happens if you unbind `pid/0-` while the process spawns more and binds them. don't love it

it's almost like being less specific there would at least let you not be confused

if it wasn't trying to help, you'd have been fine

I wonder if we could change add a return flag to basically say there was a lot.

Yeah. Basically it seems that what's more useful is being less helpful when there was more than one unbinding.

yeah. i'm happy to go have pbind just say "process id $PID: was bound, now not bound" when processor_bind() succeeds and returned an old binding

rmustacc: are you imagining a sentinel obind to say there was more than one processor unbound in the action?

Kind of yeah.

Some variant of none.

Dunno exactly. Just thinking out loud.

something like "threads were bound to multiple cpus, now not bound"

seems reasonable

In this case it'd be threads, but it'd be whatever the constinuents of the id type were.