[illumos-gate] 15204 libpcsc could use some additional routines -- Joshua M. Clulow <josh⊙so>

Anyone get this to work? grpc/grpc #17748. third_party/cares/cares/src/lib/ares_setup.h:32:10: fatal error: ares_config.h: No such file or directory

how upset would people get if ::walk sd_state (which is just iterating the soft_state array) skipped empty slots?

it makes it slightly annoying when trying to use it with other commands when it returns 0

less annoying is good:)

it seems, gitomat is on vacation:)

gerrit and GH are out of sync

please hold off on pushes until it's addressed

ou.

meanwhile in libsocket: movl $0x49000,0x8(%esi) and %esi = 0x00000000

[illumos-gate] 15493 zfs: 'spare_guid' may be used uninitialized -- Toomas Soome <tsoome⊙mc>

Has anyone here looked into mutex contention issues in $UTS/common/os/callout.c callout_table->ct_mutex ?

Nothing at my end.

Open to ideas on design improvements. Haven't looked much yet at what other systems do for timeouts.

The simplest thing is to probably just shard the table based on id space.

Or something similar.

That's what done in a number of other kernel subsystems.

At least if you want the 60 second thought process.

It'd be good to at least write up the contention you observed in an issue?

jbk I don't think I'd be keen on walkers skipping entries in general.. usually one wants to see what's there

but it could take a flag - I just do something like '::walk sd_state | ::grep '.!=0''

::grep is admittedly unwieldly (at least in my inexperienced hands) when one needs to dig a condition out of a subordinate structure

Yes, but works well for the case that jbk described.

The callouts are sorted by expiration (IIRC) which slightly complicates splitting them up.

gwr: So there are already supposed to be O(CPU) callout tables based on where the callout lives.

And they each have their own mutex.

So if you have more details on what you're seeing that'd probably help.

Makes me wonder if we're spreading out at all or what.

andyf: but I'm not really sure how useful it really is -- basically you have a growable array to hold the ddi softstates, indexed by instance #.. currently it's just iterating each index without regard to if that instance actually exists or not

if you think of say prtconf

it doesn't give you a bunch of empty entries if for some reason sd10-sd12 don't exist

[illumos-gate] 13316 ipmgmtd inconsistent with kernel on failure -- Dan Cross <cross⊙oc>

[illumos-gate] 15624 svm_getdesc does not properly heed vCPU CPL -- Patrick Mooney <pmooney⊙pc>

I'll try to gather details next we see this and post an email. It was taskq tear-down, with all threads fighting over callout table entries for the taskq idle thread cv_tiemedwait

That taskq_destory signals all those threads at once, of course...

we have mechanisms to avoid thundering herds, usually

Maybe this would be a good case for waking one, and letting it wake the next etc.

if a tty is too far to the left of a screen to be seen, is that a driver issue?

spuos on plain console?

tsoome: if you mean bare metal and vga, yes

vga text mode or framebuffer?

tsoome: uhhh... does UEFI imply one?

ah, with uefi it is framebuffer

I was pretty sure that was the case, but I am not that knowledgeable in the difference

is the terminal shifted already while in bootloader?

nope

latest illumos?

though I think it starts in BIOS mode, and starts up uefi

well I just got the ISO

it's Openindiana, and I was wondering if the issue was related to drivers or something

when the screen does shift?

with X11 starting?

from the OI bootloader

is kernel name/copyright line in place?

I didn't even start X11, it's a minimal install vers

let me check, I'll boot in again

sec

press esc to get out of the menu, then enter: boot -v -B prom_debug=true

that will spit out a lot of text, but will allow us to see when it will happen

ok what am I looking for?

I'm seeing plenty of stuff, but it is still cut off

um, well, what I'm interested of is, if the loader screen is ok, and kernel screen is shifted, at which point the screen does shift.

the whole output is shifted, and it's still listing.

since the "Booting.." text?

even before the "welcome to illumos" bootloader

ou, you mean, the loader screen is also shifted?

yep

ok, so, when you get to loader ok prompt, enter: framebuffer list - you will see the supported mode list, try framebuffer set and see if any will work better.

ok prompt?

when you get the loader menu, press esc - that will give you loader ok prompt

ah

basically, the firmware seems ti pick the gfx mode which is not working too well with your display

s/ti/to/

or loader :)

is there a way to select a different mode

?

oh I got it

framebuffer set

thank you :)

did it help?

yep

what does framebuffer get tell?

anyhow, once installed, you can add that framebuffer set command into /boot/loader.rc.local

I'll tell you once I get through the impossibly slow boot.

tsoome: I have some pretty generic options from framebuffer get, framebuffer mode on \n EDID 1280x1024 1280x1024 1152x864 \n GOP mode 2; 1024x768x32, stride=1024 \n frame buffer: adress=d3800000, size=800000 \n color mask: R=00ff0000, G=0000ff00, B=000000ff

looks like \n does not count as a return in my client

1280x1024 was causing shifted screen?

yep

hm. on EDID line, first one printed is supposed to be preferred resolution, yet obviously it was not good in your case.

strange, is it possibly related to the monitor I am using?

or maybe something I did miss:D

after all of that I forgot to make vdisks from my RAID controller :\

rmustacc: in mdb ::typedef -r / -w should allow me to basically 'extract' the ctf from a module (e.g. say module was built w/o ctf, but want to load CTF for module for a dump)

right?

(just want to be sure i'm not missing something before I spend a lot of time on this)

I don't think you need -w, but yes.

The original ::typedef -r was for something related to a qemu without ctf IIRC.

The best feature I implemented because jclulow wrote python instead of me.

ha

heh