00:02:18 <gitomat> [illumos-gate] 15204 libpcsc could use some additional routines -- Joshua M. Clulow <josh⊙so>
02:04:00 <Smithx10> Anyone get this to work?  https://github.com/grpc/grpc/issues/17748.   third_party/cares/cares/src/lib/ares_setup.h:32:10: fatal error: ares_config.h: No such file or directory
14:13:25 <jbk> how upset would people get if ::walk sd_state (which is just iterating the soft_state array) skipped empty slots?
14:14:00 <jbk> it makes it slightly annoying when trying to use it with other commands when it returns 0
15:20:46 <tsoome> less annoying is good:)
15:25:03 <tsoome> it seems, gitomat is on vacation:)
15:31:23 <pmooney> gerrit and GH are out of sync
15:31:30 <pmooney> please hold off on pushes until it's addressed
15:46:38 <tsoome> ou.
15:47:25 <tsoome> meanwhile in libsocket: movl   $0x49000,0x8(%esi) and %esi = 0x00000000 
16:04:29 <gitomat> [illumos-gate] 15493 zfs: 'spare_guid' may be used uninitialized -- Toomas Soome <tsoome⊙mc>
16:25:58 <gwr> Has anyone here looked into mutex contention issues in $UTS/common/os/callout.c callout_table->ct_mutex ?
16:29:23 <rmustacc> Nothing at my end.
16:31:47 <gwr> Open to ideas on design improvements.  Haven't looked much yet at what other systems do for timeouts.
16:35:02 <rmustacc> The simplest thing is to probably just shard the table based on id space.
16:35:07 <rmustacc> Or something similar.
16:35:23 <rmustacc> That's what done in a number of other kernel subsystems.
16:35:39 <rmustacc> At least if you want the 60 second thought process.
16:48:47 <pmooney> It'd be good to at least write up the contention you observed in an issue?
16:49:01 <andyf> jbk I don't think I'd be keen on walkers skipping entries in general.. usually one wants to see what's there
16:49:22 <andyf> but it could take a flag - I just do something like '::walk sd_state  | ::grep '.!=0''
16:50:44 <pmooney> ::grep is admittedly unwieldly (at least in my inexperienced hands) when one needs to dig a condition out of a subordinate structure
16:53:54 <andyf> Yes, but works well for the case that jbk described.
16:56:31 <gwr> The callouts are sorted by expiration (IIRC) which slightly complicates splitting them up.
17:07:51 <rmustacc> gwr: So there are already supposed to be O(CPU) callout tables based on where the callout lives.
17:08:04 <rmustacc> And they each have their own mutex.
17:08:25 <rmustacc> So if you have more details on what you're seeing that'd probably help.
17:09:48 <rmustacc> Makes me wonder if we're spreading out at all or what.
17:14:10 <jbk> 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
17:14:27 <jbk> if you think of say prtconf
17:15:01 <jbk> it doesn't give you a bunch of empty entries if for some reason sd10-sd12 don't exist
17:52:13 <gitomat> [illumos-gate] 13316 ipmgmtd inconsistent with kernel on failure -- Dan Cross <cross⊙oc>
17:54:05 <gitomat> [illumos-gate] 15624 svm_getdesc does not properly heed vCPU CPL -- Patrick Mooney <pmooney⊙pc>
18:26:02 <gwr> 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
18:26:29 <gwr> That taskq_destory signals all those threads at once, of course...
18:27:18 <richlowe> we have mechanisms to avoid thundering herds, usually
18:28:25 <gwr> Maybe this would be a good case for waking one, and letting it wake the next etc.
18:40:17 <spuos> if a tty is too far to the left of a screen to be seen, is that a driver issue? 
20:12:00 <tsoome> spuos on plain console?
20:21:01 <spuos> tsoome: if you mean bare metal and vga, yes
20:21:43 <tsoome> vga text mode or framebuffer?
20:22:36 <spuos> tsoome: uhhh... does UEFI imply one? 
20:22:51 <tsoome> ah, with uefi it is framebuffer
20:23:44 <spuos> I was pretty sure that was the case, but I am not that knowledgeable in the difference 
20:25:11 <tsoome> is the terminal shifted already while in bootloader?
20:25:24 <spuos> nope
20:26:06 <tsoome> latest illumos?
20:26:16 <spuos> though I think it starts in BIOS mode, and starts up uefi
20:26:25 <spuos> well I just got the ISO
20:27:26 <spuos> it's Openindiana, and I was wondering if the issue was related to drivers or something 
20:28:53 <tsoome> when the screen does shift?
20:29:03 <tsoome> with X11 starting?
20:29:21 <spuos> from the OI bootloader 
20:30:18 <tsoome> is kernel name/copyright line in place?
20:30:28 <spuos> I didn't even start X11, it's a minimal install vers
20:30:42 <spuos> let me check, I'll boot in again
20:30:46 <tsoome> sec
20:31:26 <tsoome> press esc to get out of the menu, then enter: boot -v -B prom_debug=true
20:32:12 <tsoome> that will spit out a lot of text, but will allow us to see when it will happen
20:36:11 <spuos> ok what am I looking for?
20:36:33 <spuos> I'm seeing plenty of stuff, but it is still cut off
20:39:40 <tsoome> 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.
20:42:02 <spuos> the whole output is shifted, and it's still listing.
20:50:24 <tsoome> since the "Booting.." text?
20:52:29 <spuos> even before the "welcome to illumos" bootloader 
20:53:09 <tsoome> ou, you mean, the loader screen is also shifted?
20:53:47 <spuos>  yep
20:54:41 <tsoome> 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.
20:55:36 <spuos> ok prompt? 
20:56:05 <tsoome> when you get the loader menu, press esc - that will give you loader ok prompt
20:56:13 <spuos> ah 
20:58:20 <tsoome> basically, the firmware seems ti pick the gfx mode which is not working too well with your display
20:58:30 <tsoome> s/ti/to/
20:59:42 <tsoome> or loader :)
21:01:30 <spuos> is there a way to select a different mode
21:01:32 <spuos> ?
21:02:52 <spuos>  oh I got it
21:02:55 <tsoome> framebuffer set 
21:03:24 <spuos> thank you :)
21:03:46 <tsoome> did it help?
21:03:53 <spuos> yep
21:04:09 <tsoome> what does framebuffer get tell?
21:06:04 <tsoome> anyhow, once installed, you can add that framebuffer set command into /boot/loader.rc.local
21:13:31 <spuos> I'll tell you once I get through the impossibly slow boot.
21:20:32 <spuos> 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
21:21:24 <spuos> looks like \n does not count as a return in my client
21:21:53 <tsoome> 1280x1024 was causing shifted screen?
21:22:25 <spuos> yep 
21:27:48 <tsoome> hm. on EDID line, first one printed is supposed to be preferred resolution, yet obviously it was not good in your case.
21:35:01 <spuos> strange, is it possibly related to the monitor I am using?
21:36:05 <tsoome> or maybe something I did miss:D
21:39:52 <spuos> after all of that I forgot to make vdisks from my RAID controller :\
23:46:31 <jbk> 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)
23:46:34 <jbk> right?
23:46:52 <jbk> (just want to be sure i'm not missing something before I spend a lot of time on this)
23:49:31 <rmustacc> I don't think you need -w, but yes.
23:49:52 <rmustacc> The original ::typedef -r was for something related to a qemu without ctf IIRC.
23:50:17 <rmustacc> The best feature I implemented because jclulow wrote python instead of me.
23:56:40 <jclulow> ha
23:59:29 <jbk> heh