00:06:04 I'm trying to print sd_ssc_t using dtrace but I'm just getting struct sd_ssc_t printed, what I'm missing ? dtrace -x switchrate=1000hz -q -n 'fbt:sd:sd_tg_rdwr:entry { print(*(struct sd_ssc_t *)args[0]); ustack();}' -c 'fdisk /dev/rdsk/c1t0d1p0' 00:20:59 no struct 00:21:13 (just use 'sd_ssc_t') 00:23:22 however.. sd_tg_rdwr passes in a dev_info_t for it's first argument 00:23:35 so not sure that'll do what you're wanting 00:42:55 jbk thanks my mistake, I wanted to check https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/scsi/targets/sd.c?r=93686a1e#19907 00:44:33 jbk thanks that worked ! dtrace -x switchrate=1000hz -q -n 'fbt:sd:sd_send_scsi_READ_CAPACITY:entry { print(*(sd_ssc_t *)args[0]); ustack();}' -c 'fdisk /dev/rdsk/c1t0d1p0' 00:57:06 jbk I wanted to print ssc_un from that struct 01:00:14 I don't know if this is correct dtrace -x switchrate=1000hz -q -n 'fbt:sd:sd_send_scsi_READ_CAPACITY:entry { prii 01:00:14 nt(*(struct sd_lun *)args[0]->ssc_un); }' -c 'fdisk /dev/rdsk/c1t0d1p0' 02:29:24 args[nn] should have the type already 02:29:47 arg0, arg1, don't (or are actually int64_t IIRC) 02:54:48 jbk thanks! 03:01:12 jbk I'm still trying to find out why the scsi disk in oci is not able to be formatted, this the state when trying to fdisk it https://termbin.com/whq99 03:26:09 there is also that mdb module.. disk_label i think.. 11:17:40 disk_label is just helping you to read and check MBR/VTOC and GPT. 11:57:11 < 15:58:25 heh.. this is a fun one.. I need to flush out the details of what's happening but with the right sequence of dladm commands, you can create schrödinger's aggr that both exists and doesn't exist 16:07:21 hi all, i hit very strange panic on old supermicro x8 with dual xeon: 16:07:23 https://paste.dilos.org/?d9d5dd412c27a133#OEga5f2ROfYhgohFd2N1+FZ2NPGlMiUHvSx/TXrNz6Y= 16:07:47 ideas what can be related and how to try to fix it ? 16:21:33 igork1: on my systems, unix:smt_init+a9 is just after a call to smt_find_sibling(). the crash looks very early as its trying to spin up all the threads on all the cores. 16:22:25 sommerfeld: how to try to fix it ? 16:22:30 ideas? 16:22:57 Focus on understanding what's wrong. 16:23:17 you're getting way ahead of yourself. no idea what's actually wrong yet, so no way yet to know what to fix. 16:23:52 rmustacc: i try. i'll try clear bios to default 16:24:48 probably it's broken hw, but i have no direct access, just remote and very slow 16:24:49 why? 16:24:57 I mean, that's not understanding the problem. 16:25:21 Understand why we panicked, what was it that's wrong. 16:26:03 ok, i'll try 16:32:29 btw, does anyone have emulex fc hba (emlxs), need to get https://code.illumos.org/c/illumos-gate/+/1942 tested... 16:32:30 → CODE REVIEW 1942: 14394 emlxs: array subscript is partly outside array bounds (NEW) | https://www.illumos.org/issues/14394 17:16:55 jbk is it too bad that vioscsi_tran_getcap returns -1 on geometry ? 17:18:23 [illumos-gate] 15541 wrong pointer passed to ddi_soft_state_fini() in dam_map_alloc() -- Hans Rosenfeld 17:22:14 neirac: probably? I've not looked at the vioscsi driver in a while, but sounds less than desirable 17:22:38 though looking at the function, 'cap' there is i think short for 'capability' and not 'capacity' 17:23:17 i guess it depends on what capability is being queried 17:23:19 yes, is capability, the requested capability is geometry and that one fails. 17:24:33 I'll fix that to see how far it goes, but I already tried hardcoding hte geometry in sd, at least I'm learning 21:37:37 also.. this bespoke persistent database code for dlmgmtd is annoying... 21:38:08 (and tedious) 21:40:54 the choices there are all pretty bad. 21:41:46 which isn't to defend it, I'm not keen on it either, but I'd also not be keen on any of the other options that spring to mind. 21:42:12 SMF has shown us that sqlite isn't a good idea 21:42:28 because there's absolutely no upgrade path. 21:43:25 (you have to dump with the old sqlite and restore with the new. which obviously we can't arrange for in any realistic sense) 21:45:33 I guess marshalled nvlists? especially if marshalled to something readably textual. 21:45:43 (which I don't think we do bidirectionally at present) 22:19:07 well, ancient sqlite isn't a good idea. 22:20:59 sqlite 3.0.0 was released in 2004; we're on a 2.x version of sqlite 22:21:10 right, the thing I said above is _why_ we're on 2.x 22:22:50 we would have to arrange to use 3, ship something that we can get configd to run when it starts ('cos it needs to be linked with 2) to dump the DB and let configd load it back in. 22:23:18 as the 3rd process we run, foolproofly. I don't think anyone has wanted to tackle it. 22:24:32 (or you could have init do it before it starts configd, etc, my point is very early and with high stakes) 22:24:51 or linker magic to let both versions coexist in the same namespace 22:25:09 well, yeah, you could put them on different link maps, but that makes it more exciting :) 22:25:11 s/namespace/address space/ 22:35:50 the underlying code in svc.configd already plays database-swapping games to cope with the filesystem potentially being read-only early in boot. 22:39:41 if this is you volunteering, I would be _incredibly_ happy :) 22:42:08 actually, there's another time you can do the conversion: before reboot into a new BE. 22:42:42 ship two versions of svc.configd - one linked against sqlite2, one against sqlite3 22:44:15 startd looks for some semaphore file to indicate conversion has happened 22:44:23 picks the version of svc.configd that matches 22:46:49 beadm or some such grows a command that will do the db dump/reload and create the semaphore file if successful. 22:52:27 then you can do the conversion with a fully functional OS rather than one that has just woken up and is still groggy. 22:55:48 you don't convert the running repo, you convert the quiescent one in the other BE 23:20:23 richlowe: about squlite 2 - it can be converted to 3 by upgrade procedure, not on fly. you can move db to temporary one and convert to original by postinst procedure to additional BE 23:20:40 igork: that's not the hard part 23:21:52 sommerfeld: sure 23:22:30 because we save smf db in every BE 23:34:14 the tricky part is building the rest of the system to make that upgrade happen at a time when it is unlikely to fail, and make it so that a failed upgrade can be tried later. 23:35:03 and pkg doesn't have postinstall scripts. 23:38:52 i haven't looked at any deps for sqllite3, but 2 looks like it just depends on libc.. so.. in the 'any problem can be solved with another layer of abstraction' vein, could check the version and dlopen() the correct sqllite library 23:39:09 it looks like for svc.configd that the sqlite stuff is confined to backend.c 23:39:13 (from first glance) 23:39:50 so as long as the SQL syntax itself hasn't changed incompatibily (would need to check, but probably not likely) 23:40:31 so it could just use whatever version is there.. and defer upgrading to some other point later when the system is up 23:41:16 or maybe allow the operator to control when it switches 23:41:16 did a spot check, .dump in sqlite of the repository.db into .sql syntax, and .read it into a sqlite3 database 23:41:29 sqlite3 is similarly lean 23:41:42 but I believe the API is slightly different. 23:42:23 so some headstands in backend.c would be needed 23:44:56 (BTW, for the system I tried, the repository.db file is half the size when created by sqlite3) 23:50:01 a round-trip load and re-dump sqlite3 turned up a few quirks when I diffed the dump 23:50:32 a few large integers turned into floats. 23:53:02 ah, one large integer (18446744073709551615, perhaps better known as 0xffffffffffffffff) appeared a bunch of times 23:53:38 sqlite3 interpreted it as 1.84467440737096e+19 23:56:27 lots of integers ended up dumped back out as strings 23:58:14 only diff is to rows of value_tbl