i haven't been able to follow the many layers of functions yet to tell if this is true, so I'm curious if someone knows offhand -- will a USCSICMD ioctl always end up passing a struct buf (9S) where b_bufsize will be a multiple of DEV_BSIZE?

there's a couple of missing SCSI commands that our sata layer doesn't translate, so I was going to add them based off the guidance of SAT-5

but they require that the buffer passed to the ATA device be sized in units of DEV_BSIZE, so i'm not sure if I need to worry about possibly reallocating or not

copec yep, I found it while trying to dd disk image to zvol backed lun and found it getting corrupted:D

hi

Morning

update_drv -a -i '"pci9005,28f"' aac; update_drv -a -i '"pciex9005,28f"' aac;

devfsadm: driver failed to attach: aac

Warning: Driver (aac) successfully added to system but failed to attach

devfsadm: driver failed to attach: aac

Warning: Driver (aac) successfully added to system but failed to attach

I can get driver working for my adaptec card ....

freebsd commit 7cb209f5d08322ca30faf6aaec2c3bb27c0ea40f : cgit.freebsd.org/src/commit/?id=7cb…9f5d08322ca30faf6aaec2c3bb27c0ea40f

anyhow, I need to get back to digging in those zfs tests now:P

do you know when the 28f can beed added ?

update_drv -a -i '"pci14e4,16d8"' bge; update_drv -a -i '"pciex14e4,16d8"' bge;

("pci14e4,16d8") already in use as a driver or alias.

("pciex14e4,16d8") already in use as a driver or alias

I could not remove it even after a reboot

it is perssistant

gstoeh: use pkg fix to fix changes to the driver .conf file or update_drv

If it fails to attach it is not supported

toasterson : not sure how to do this can you guide me ?

gstoeh: tsoome already gave you the commands in the openindiana channel. did anything not work as expected?

yes I used the command : update_drv -a -i '"pci9005,28f"' aac; update_drv -a -i '"pciex9005,28f"' aac;

no luck

Yes, that was just a try to see if you are lucky and the device is wupported but not added to the configuration. Since it failed we would need to update the driver to the latest one from freebsd

ok, thank you, is that something you can do "soon" ? ot it takes time...

it takes time

time, means like in days ?

nope, in the scale of no clue maybe months or years

that is difficult on us ... no other alternative you can think of ?

The only other options are either 1. finance a consultant to do the porting work sooner (although it won't happen within days) or 2. buy another card that is in the HCL

i see ...

3. passthrough the device to a guest in the bhyve VM where you can use it

denk then one could also install linux directly on the host with OpenZFS

Since the requirement was for illumos I assume that gstoeh has other backup plans.

The default one being Use the OS supported by the vendor

Or pay a vendor of an of to support your hardware

s/of/OS/

yea, and our problem is that .... where is the HCL?:)

gstoeh: To add a bit of economical background. Linux is also not for free but with OSS the funding model changed and more ways of funding where possible. So not only vendors funded the development but also consumers could fund the development and that is what kept it going. Now with the vendor funding monopolized and consumer funding having died down there is just no funding going into certain drivers. the one of your card being one of them.

Joyent funded some development for us but since they have switched and Oxide has it's own hardware we are in the middle of changes happening. So sadly no luck at the moment for that card.

tsoome: we sent that some days ago to him so I doubt that is the problem :) So far as I can see he simply doen't have Hardware where illumos can run at the moment

yep:(

And there are not that many updates from our side too, unfortunately.

Well I managed to get my ARM packaging setup to the point where I will be able to release this months so we got that going for us which is nice :)

ou, thats good

@danmcd for illumos.org/issues/15271 it would be nice to get some confirmation the other var is indeed safe to use (it looks like it)

→ FEATURE 15271: Want tunable to force viona to always copy tx buffers (New) | code.illumos.org/c/illumos-gate/+/2565

Okay, and the ZFS one is for a kmem_free() that dies deep in its vmem arena allocation. Also a case of too-big-to-kgrep right now. :(

And perhaps figure out where to document this as it will probably help other people to.

Wrong window.

sjorge: I see. That's a good reason to not close it yet.

It works and we (andyf and me) think it should be fine, but having someone else weigh in would be nice

Not sure who would be most qualified though to say if setting an enum via /etc/system is not going to cause issues somewhere down the time

But in the end an int, boolean_t or enum are all well... int

They are, but I have been asked to change a boolean_t to an int in the past for a tuneable, since system(4/5?) says that it modifies ints

I don't see that it's any problem to use an enum since it compiles as an int and the kernel checks the size of the variable and does the right thing

as long as it does compile as 32-bit int.

fun will start, when it does not;)

That should be ok even with C23 enums

well, C23 enums are not always 32-bit int..

but tunables can be 8/16 bit today

we might want to update the system man page, that's all

We have currently loader env (or -B var = val) translation to system property. I have been thinking, there should be mechanism to translate property to tunable and to have userland tool to set/get property (when applicable). Since properties have type, some control can be applied...

Question is if we want to purely rely on c types or make a custom type check system to enforce custom limits on tunables

May also close a whole type of security bug

So Hetzner has ARM64 Physical HW rentable to 100 EUR a month cheaper than comparable AMD version hetzner.com/dedicated-rootserver/matrix-rx

we'd need to know about the hardware, etc, to have any hope of it working.

and ideally toomas to find time to port loader. :)

Ampere altra

They have UEFI

well, none of that code exists, so that definitely will take work.

for tsoome :)

there's other stuff that needs to know about EFI and other related things.

presumably if it's efi it's armsbsa so there's also acpi etc.

l/win 12

[illumos-gate] 15294 Successful read/write calls should not set errno -- Andy Fiddaman <illumos⊙fn>

That reminds me of this: github.com/illumos/illumos-gate/blo…b/libfakekernel/common/kmisc.c#L106

The comment in the latest commit says: "isatty(3C) will set errno as a side-effect of returning 0." - that is exactly what ddi_strtoull() does in libfakekernel.

There is no errno in the kernel, though, so consuming software is unlikely to notice

Good point.