01:29:39 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? 01:31:15 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 01:31:47 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 07:21:47 copec yep, I found it while trying to dd disk image to zvol backed lun and found it getting corrupted:D 08:32:14 hi 08:41:41 Morning 08:42:13 update_drv -a -i '"pci9005,28f"' aac; update_drv -a -i '"pciex9005,28f"' aac; 08:42:14 devfsadm: driver failed to attach: aac 08:42:16 Warning: Driver (aac) successfully added to system but failed to attach 08:42:18 devfsadm: driver failed to attach: aac 08:42:20 Warning: Driver (aac) successfully added to system but failed to attach 08:42:54 I can get driver working for my adaptec card .... 08:45:20 freebsd commit 7cb209f5d08322ca30faf6aaec2c3bb27c0ea40f : https://cgit.freebsd.org/src/commit/?id=7cb209f5d08322ca30faf6aaec2c3bb27c0ea40f 08:46:33 anyhow, I need to get back to digging in those zfs tests now:P 09:13:20 do you know when the 28f can beed added ? 09:15:39 update_drv -a -i '"pci14e4,16d8"' bge; update_drv -a -i '"pciex14e4,16d8"' bge; 09:15:41 ("pci14e4,16d8") already in use as a driver or alias. 09:15:43 ("pciex14e4,16d8") already in use as a driver or alias 11:25:50 I could not remove it even after a reboot 11:25:56 it is perssistant 11:46:53 gstoeh: use pkg fix to fix changes to the driver .conf file or update_drv 11:47:07 If it fails to attach it is not supported 15:17:14 toasterson : not sure how to do this can you guide me ? 15:18:42 gstoeh: tsoome already gave you the commands in the openindiana channel. did anything not work as expected? 15:21:45 yes I used the command : update_drv -a -i '"pci9005,28f"' aac; update_drv -a -i '"pciex9005,28f"' aac; 15:21:49 no luck 15:23:20 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 15:25:56 ok, thank you, is that something you can do "soon" ? ot it takes time... 15:26:11 it takes time 15:26:50 time, means like in days ? 15:27:19 nope, in the scale of no clue maybe months or years 15:29:29 that is difficult on us ... no other alternative you can think of ? 15:31:55 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 15:32:40 i see ... 15:34:29 3. passthrough the device to a guest in the bhyve VM where you can use it 15:36:40 denk then one could also install linux directly on the host with OpenZFS 15:37:03 Since the requirement was for illumos I assume that gstoeh has other backup plans. 15:37:42 The default one being Use the OS supported by the vendor 15:37:55 Or pay a vendor of an of to support your hardware 15:38:13 s/of/OS/ 15:43:32 yea, and our problem is that .... where is the HCL?:) 15:45:00 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. 15:45:00 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. 15:46:12 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 15:46:35 yep:( 15:47:35 And there are not that many updates from our side too, unfortunately. 15:49:54 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 :) 15:52:17 ou, thats good 15:58:36 @danmcd for https://www.illumos.org/issues/15271 it would be nice to get some confirmation the other var is indeed safe to use (it looks like it) 15:58:37 → FEATURE 15271: Want tunable to force viona to always copy tx buffers (New) | https://code.illumos.org/c/illumos-gate/+/2565 15:58:52 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. :( 15:58:53 And perhaps figure out where to document this as it will probably help other people to. 15:58:59 Wrong window. 16:00:25 sjorge: I see. That's a good reason to not close it yet. 16:16:52 It works and we (andyf and me) think it should be fine, but having someone else weigh in would be nice 16:17:19 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 16:17:34 But in the end an int, boolean_t or enum are all well... int 16:18:16 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 16:19:00 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 16:19:25 as long as it does compile as 32-bit int. 16:19:39 fun will start, when it does not;) 16:19:59 That should be ok even with C23 enums 16:20:11 well, C23 enums are not always 32-bit int.. 16:21:12 but tunables can be 8/16 bit today 16:21:29 we might want to update the system man page, that's all 16:25:03 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... 16:59:02 Question is if we want to purely rely on c types or make a custom type check system to enforce custom limits on tunables 16:59:24 May also close a whole type of security bug 20:02:09 So Hetzner has ARM64 Physical HW rentable to 100 EUR a month cheaper than comparable AMD version https://www.hetzner.com/dedicated-rootserver/matrix-rx 20:03:28 we'd need to know about the hardware, etc, to have any hope of it working. 20:03:38 and ideally toomas to find time to port loader. :) 20:03:43 Ampere altra 20:04:25 They have UEFI 20:04:46 well, none of that code exists, so that definitely will take work. 20:06:47 for tsoome :) 20:25:56 there's other stuff that needs to know about EFI and other related things. 20:26:14 presumably if it's efi it's armsbsa so there's also acpi etc. 21:46:17 l/win 12 23:08:39 [illumos-gate] 15294 Successful read/write calls should not set errno -- Andy Fiddaman 23:37:59 That reminds me of this: https://github.com/illumos/illumos-gate/blob/9ecd05bdc59e4a1091c51ce68cce2028d5ba6fd1/usr/src/lib/libfakekernel/common/kmisc.c#L106 23:39:05 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. 23:39:51 There is no errno in the kernel, though, so consuming software is unlikely to notice 23:53:09 Good point.