I'm trying to print sd_ssc_t using dtrace but I'm just getting struct sd_ssc_t <forward decl> 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'

no struct

(just use 'sd_ssc_t')

however.. sd_tg_rdwr passes in a dev_info_t for it's first argument

so not sure that'll do what you're wanting

jbk thanks my mistake, I wanted to check src.illumos.org/source/xref/illumos…/scsi/targets/sd.c?r=93686a1e#19907

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'

jbk I wanted to print ssc_un from that struct

I don't know if this is correct dtrace -x switchrate=1000hz -q -n 'fbt:sd:sd_send_scsi_READ_CAPACITY:entry { prii

nt(*(struct sd_lun *)args[0]->ssc_un); }' -c 'fdisk /dev/rdsk/c1t0d1p0'

args[nn] should have the type already

arg0, arg1, don't (or are actually int64_t IIRC)

jbk thanks!

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 termbin.com/whq99

there is also that mdb module.. disk_label i think..

disk_label is just helping you to read and check MBR/VTOC and GPT.

<

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

hi all, i hit very strange panic on old supermicro x8 with dual xeon:

ideas what can be related and how to try to fix it ?

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.

sommerfeld: how to try to fix it ?

ideas?

Focus on understanding what's wrong.

you're getting way ahead of yourself. no idea what's actually wrong yet, so no way yet to know what to fix.

rmustacc: i try. i'll try clear bios to default

probably it's broken hw, but i have no direct access, just remote and very slow

why?

I mean, that's not understanding the problem.

Understand why we panicked, what was it that's wrong.

ok, i'll try

btw, does anyone have emulex fc hba (emlxs), need to get code.illumos.org/c/illumos-gate/+/1942 tested...

→ CODE REVIEW 1942: 14394 emlxs: array subscript is partly outside array bounds (NEW) | illumos.org/issues/14394

jbk is it too bad that vioscsi_tran_getcap returns -1 on geometry ?

[illumos-gate] 15541 wrong pointer passed to ddi_soft_state_fini() in dam_map_alloc() -- Hans Rosenfeld <rosenfeld⊙gho>

neirac: probably? I've not looked at the vioscsi driver in a while, but sounds less than desirable

though looking at the function, 'cap' there is i think short for 'capability' and not 'capacity'

i guess it depends on what capability is being queried

yes, is capability, the requested capability is geometry and that one fails.

I'll fix that to see how far it goes, but I already tried hardcoding hte geometry in sd, at least I'm learning

also.. this bespoke persistent database code for dlmgmtd is annoying...

(and tedious)

the choices there are all pretty bad.

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.

SMF has shown us that sqlite isn't a good idea

because there's absolutely no upgrade path.

(you have to dump with the old sqlite and restore with the new. which obviously we can't arrange for in any realistic sense)

I guess marshalled nvlists? especially if marshalled to something readably textual.

(which I don't think we do bidirectionally at present)

well, ancient sqlite isn't a good idea.

sqlite 3.0.0 was released in 2004; we're on a 2.x version of sqlite

right, the thing I said above is _why_ we're on 2.x

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.

as the 3rd process we run, foolproofly. I don't think anyone has wanted to tackle it.

(or you could have init do it before it starts configd, etc, my point is very early and with high stakes)

or linker magic to let both versions coexist in the same namespace

well, yeah, you could put them on different link maps, but that makes it more exciting :)

s/namespace/address space/

the underlying code in svc.configd already plays database-swapping games to cope with the filesystem potentially being read-only early in boot.

if this is you volunteering, I would be _incredibly_ happy :)

actually, there's another time you can do the conversion: before reboot into a new BE.

ship two versions of svc.configd - one linked against sqlite2, one against sqlite3

startd looks for some semaphore file to indicate conversion has happened

picks the version of svc.configd that matches

beadm or some such grows a command that will do the db dump/reload and create the semaphore file if successful.

then you can do the conversion with a fully functional OS rather than one that has just woken up and is still groggy.

you don't convert the running repo, you convert the quiescent one in the other BE

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

igork: that's not the hard part

sommerfeld: sure

because we save smf db in every BE

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.

and pkg doesn't have postinstall scripts.

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

it looks like for svc.configd that the sqlite stuff is confined to backend.c

(from first glance)

so as long as the SQL syntax itself hasn't changed incompatibily (would need to check, but probably not likely)

so it could just use whatever version is there.. and defer upgrading to some other point later when the system is up

or maybe allow the operator to control when it switches

did a spot check, .dump in sqlite of the repository.db into .sql syntax, and .read it into a sqlite3 database

sqlite3 is similarly lean

but I believe the API is slightly different.

so some headstands in backend.c would be needed

(BTW, for the system I tried, the repository.db file is half the size when created by sqlite3)

a round-trip load and re-dump sqlite3 turned up a few quirks when I diffed the dump

a few large integers turned into floats.

ah, one large integer (18446744073709551615, perhaps better known as 0xffffffffffffffff) appeared a bunch of times

sqlite3 interpreted it as 1.84467440737096e+19

lots of integers ended up dumped back out as strings

only diff is to rows of value_tbl