01:26:24 <jbk> hmm.. it appears fwflash cannot (currently) work with SATA devices
01:26:57 <jbk> the mode it uses doesn't get translated by our sata framework
01:28:51 <jbk> we also don't translate READ_BUFFER(10)
06:28:27 <jbk> ok.. so our ATA PASSTHROUGH 16 implementation is broken
06:29:34 <jbk> (whcih is probably why you have to use -d sat,12 w/ smartctl)
08:20:37 <tsoome> jbk and occasional panic at weird times
08:38:54 <sjorge> OK ar FOSDEM, now to find everyone and drop the goods
08:44:20 <sjorge> Found freebsd but the table is tiny, waitint near the wall
08:46:01 <otis> who's there from freebsd?
09:39:03 <andyf> sjorge (and anyone else) chez theo in building F has good coffee and no queue (and a few of us are here)
09:40:10 <sjorge> I'm in the freebsd devroom atm
14:10:21 <sjorge> So ... for the viona always copy on tx tunable... do I add it to the bhyve manpage?
14:10:49 <sjorge> There is no viona manpage and I haven't found a driver that mentions any /etc/system tunables either.
17:40:18 <jbk> tsoome: i'm not surprised... there's even more stuff I need to add to that bug..
18:21:44 <jbk> ... and my god.. i tried building sata.c w/o warnings... i'm pretty sure my server cried a bit from the results :)
18:22:11 <jbk> (definitely needs its own ticket for that)
18:28:30 <jbk> i guess it's probably good that the ATA PASS-THROUGH (16) command has apparently only ever been used for commands that don't modify drive contents in any way
18:29:06 <jbk> at least I hope no one's ever attempted it
18:51:19 <jbk> alanc: i am kinda curious to know if this was fixed in solaris..
19:33:40 <sommerfeld> jbk: thanks for wading in and trying to make it better.
20:00:33 <jbk> i was actually working on something else (I'd like to update the firmware on my SATA drives in my home server, but fwflash(8) won't work because we're missing support for translating the WRITE BUFFER mode
20:01:35 <jbk> when I noticed the pass-through function was setting lba_{mid,low}_msb values to the same expression
20:01:46 <jbk> and knew that was wrong
20:02:14 <jbk> and a few hours later, the sweater was unraveled :)
20:03:59 <sjorge> so you're going to use that yarn to make a new sweater or? 😅
20:15:14 <jbk> well at least now you can do 'smartctl -a <sata disk>' and have it work :)
20:24:45 <jbk> well I can at least (since i'm running these bits to test).. but soon
20:36:01 <igork> jbk: did you try to run zfs tests on SATA drives with your SATA update ?
20:36:46 <jbk> not yet.. AFAIK there's nothing in zfs that would touch this
20:37:00 <jbk> zfs doesn't try to send RAW ATA commands to disks
20:37:27 <igork> they will produce a lot of IO with tests, will be interest to see results with sata ssd and sas hdd with SATA controller over zfs tests
20:37:59 <jbk> but none of that goes through the code being changed
20:38:07 <rmustacc> A SATA controller can't drive a SAS SSD.
20:38:09 <rmustacc> Or hdd.
20:38:13 <igork> jbk: it is not ZFS itself, it's proposal how to generate a lot of IO to SATA controller and check your update
20:39:07 <igork> rmustacc: is it AHCI controller not SATA ?
20:39:27 <rmustacc> Doesn't matter.
20:39:42 <jbk> i think there's a misunderstanding of what's impacted
20:39:43 <rmustacc> Also, ahci is an interface to a standardized sata controller.
20:39:52 <igork> sas hdd -> sata hdd - it was wisprint
20:39:57 <igork> *mossprint
20:40:19 <igork> *missprint
20:41:18 <jbk> pretty much everything (and basically everything in illumos-gate) sends SCSI commands to SATA disks, sata.c translates them to ATA commands
20:41:31 <jbk> so your normal read, writes, .. those are SCSI commands that get translated
20:41:50 <rmustacc> Very little actually uses the pass-through commands directly.
20:41:58 <jbk> yeah
20:42:12 <igork> if i'm correct we are using sata <=> scsi sd translation 
20:42:40 <richlowe> that's not relevant.
20:42:41 <rmustacc> Commands are translated igork, but jbk's change only effects one specific SCSI command basically.
20:42:51 <jbk> well two
20:42:52 <rmustacc> And that SCSI command is not issued by the stack.
20:43:13 <igork> ok, thanks for info
20:43:14 <richlowe> imagine everything was like "SCSI SCSI SCSI" and some specific tools needed a "But not this one..."
20:43:19 <richlowe> it's the last kind that's busted
20:43:23 <sommerfeld> it's a specific code path, off the beaten track for filesystem I/O.
20:45:05 <rmustacc> Thanks for tracking that down, Jason.
20:58:16 <toasterson> richlowe: do you know whne in the ARM build we build libgcc? is that the gcc build we do?
21:00:54 <richlowe> yeah
21:01:06 <richlowe> if you're trying to deliver gcc _into the image_ you have to build it all over again, after the image is built.
21:01:15 <richlowe> sorry, after a full sysroot exists.
21:01:38 <jbk> rmustacc: it was more of an accident but the '-d sat,12' had annoyed me in the past, so I was happy to fix it
21:01:46 <jbk> (accident that I noticed it)
21:01:48 <richlowe> both so it's built for the right platform, obviously, but also because a real useful build is going to require an entire sysroot to exist. 
21:01:57 <toasterson> Thats clear. Was more trying to figure the best way to integrate it into a build env.
21:02:22 <toasterson> I want a cross build env and a sysroot
21:02:43 <richlowe> arm64-gate does all that, but sucks, efforts to not suck you want to talk to andyf and such.
21:03:00 <toasterson> And I don't want to rebuild gcc that often that takes a lot of time.
21:03:12 <rmustacc> You kind of have to.
21:03:15 <richlowe> and the piece I was talking about is less obvious than you think, for eg, we build a static libgcc (only) to bootstrap, because a dynamic libgcc would require the CRT, which we need the gcc to build...
21:03:20 <toasterson> Yeah one of those efforts is mine :)
21:03:47 <toasterson> But somehow I am missing libgcc from that gcc build I just did
21:03:49 <richlowe> so you need to build everything at least twice to deliver it onto the target, and _ideally_ twice to deliver a full service bootstrap environment.
21:04:05 <rmustacc> The only shortcuts here lead to sadness.
21:04:08 <richlowe> are you missing the static libgcc or the shared one?
21:04:22 <richlowe> because the shared one, in an arm64-gate environment doesn't exist at all.
21:04:24 <richlowe> (as above)
21:04:41 <toasterson> the one needed to build libm
21:05:05 <richlowe> then that I don't know what's happened.
21:05:19 <richlowe> but, especially if you're all at fosdem, talking to andy certainly can't hurt.
21:05:31 <rmustacc> Why does libm need a libgcc_s?
21:05:31 <toasterson> I am not there
21:06:10 <toasterson> Well somehow -lgcc is added to the command
21:06:31 <richlowe> it doesn't need libgcc_s, it needs libgcc for FPU intrinsics stuff, that I haven't implemented in libc yet  
21:06:50 <richlowe> remember also, robert, it's not the "Real" libm.
21:07:20 <rmustacc> I think this is the point where I shoudn't ask more questsions and get back to the x86 fpu that's killing me.
21:07:34 <toasterson> Ok, but somehow in my process I lost libgcc... Now to find it :)
21:07:34 <richlowe> well, if you want to I can answer anything you want to know (I hope)
21:11:52 <toasterson> richlowe: libgcc is a .a file right?....
21:12:18 <richlowe> it should be libgcc.a in the .../cross/  structure
21:12:39 <toasterson> ah, that makes things clear thanks :)
21:14:04 <toasterson> it is missing because the transforms drop it by default
21:14:19 <toasterson> need to not do that for the cross tools