hmm.. it appears fwflash cannot (currently) work with SATA devices

the mode it uses doesn't get translated by our sata framework

we also don't translate READ_BUFFER(10)

ok.. so our ATA PASSTHROUGH 16 implementation is broken

(whcih is probably why you have to use -d sat,12 w/ smartctl)

jbk and occasional panic at weird times

OK ar FOSDEM, now to find everyone and drop the goods

Found freebsd but the table is tiny, waitint near the wall

who's there from freebsd?

sjorge (and anyone else) chez theo in building F has good coffee and no queue (and a few of us are here)

I'm in the freebsd devroom atm

So ... for the viona always copy on tx tunable... do I add it to the bhyve manpage?

There is no viona manpage and I haven't found a driver that mentions any /etc/system tunables either.

tsoome: i'm not surprised... there's even more stuff I need to add to that bug..

... and my god.. i tried building sata.c w/o warnings... i'm pretty sure my server cried a bit from the results :)

(definitely needs its own ticket for that)

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

at least I hope no one's ever attempted it

alanc: i am kinda curious to know if this was fixed in solaris..

jbk: thanks for wading in and trying to make it better.

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

when I noticed the pass-through function was setting lba_{mid,low}_msb values to the same expression

and knew that was wrong

and a few hours later, the sweater was unraveled :)

so you're going to use that yarn to make a new sweater or? 😅

well at least now you can do 'smartctl -a <sata disk>' and have it work :)

well I can at least (since i'm running these bits to test).. but soon

jbk: did you try to run zfs tests on SATA drives with your SATA update ?

not yet.. AFAIK there's nothing in zfs that would touch this

zfs doesn't try to send RAW ATA commands to disks

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

but none of that goes through the code being changed

A SATA controller can't drive a SAS SSD.

Or hdd.

jbk: it is not ZFS itself, it's proposal how to generate a lot of IO to SATA controller and check your update

rmustacc: is it AHCI controller not SATA ?

Doesn't matter.

i think there's a misunderstanding of what's impacted

Also, ahci is an interface to a standardized sata controller.

sas hdd -> sata hdd - it was wisprint

*mossprint

*missprint

pretty much everything (and basically everything in illumos-gate) sends SCSI commands to SATA disks, sata.c translates them to ATA commands

so your normal read, writes, .. those are SCSI commands that get translated

Very little actually uses the pass-through commands directly.

yeah

if i'm correct we are using sata <=> scsi sd translation

that's not relevant.

Commands are translated igork, but jbk's change only effects one specific SCSI command basically.

well two

And that SCSI command is not issued by the stack.

ok, thanks for info

imagine everything was like "SCSI SCSI SCSI" and some specific tools needed a "But not this one..."

it's the last kind that's busted

it's a specific code path, off the beaten track for filesystem I/O.

Thanks for tracking that down, Jason.

richlowe: do you know whne in the ARM build we build libgcc? is that the gcc build we do?

yeah

if you're trying to deliver gcc _into the image_ you have to build it all over again, after the image is built.

sorry, after a full sysroot exists.

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

(accident that I noticed it)

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.

Thats clear. Was more trying to figure the best way to integrate it into a build env.

I want a cross build env and a sysroot

arm64-gate does all that, but sucks, efforts to not suck you want to talk to andyf and such.

And I don't want to rebuild gcc that often that takes a lot of time.

You kind of have to.

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...

Yeah one of those efforts is mine :)

But somehow I am missing libgcc from that gcc build I just did

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.

The only shortcuts here lead to sadness.

are you missing the static libgcc or the shared one?

because the shared one, in an arm64-gate environment doesn't exist at all.

(as above)

the one needed to build libm

then that I don't know what's happened.

but, especially if you're all at fosdem, talking to andy certainly can't hurt.

Why does libm need a libgcc_s?

I am not there

Well somehow -lgcc is added to the command

it doesn't need libgcc_s, it needs libgcc for FPU intrinsics stuff, that I haven't implemented in libc yet

remember also, robert, it's not the "Real" libm.

I think this is the point where I shoudn't ask more questsions and get back to the x86 fpu that's killing me.

Ok, but somehow in my process I lost libgcc... Now to find it :)

well, if you want to I can answer anything you want to know (I hope)

richlowe: libgcc is a .a file right?....

it should be libgcc.a in the .../cross/ structure

ah, that makes things clear thanks :)

it is missing because the transforms drop it by default

need to not do that for the cross tools