04:01:04 I just filed fenix illumos#16537 and I have a dumb question. 04:01:05 BUG 16537: cxgbe: update firmware version to 1.27.5.0 (New) 04:01:05 ↳ https://www.illumos.org/issues/16537 04:02:13 Can I use fwadm(8) to update cxgbe FW? Or do I have to boot UEFI and use ChelsioUD.efi ? I'm VERY interested in this because this update fixes cxgbe to work with iPXE. 04:40:56 you mean fwflash? 04:41:53 also i thought it was delivered as a binary blob in the driver 04:43:09 though i suppose that doesn't help with ipxe 04:45:16 it looks like there might be an ioctl to do it, but no glue to use it in fwflash 05:15:18 danmcd: you can simply copy it to /kernel/firmware/cxgbe/ and then change the symlink for the relevant tNfw.bin file. 05:35:58 nomad you are missing few packages 07:24:59 nomad I *think* its rpcsec package you are missing, if you run share command manually (share -o sec=krb5 ...), it should tell what is missing 08:49:52 jbk it was, but I split that out into files a while ago. 08:59:39 danmcd_ - dropping the new firmware in will work as long as nothing about the firmware interface has changed, otherwise we also need a driver update. Looking at Chelsio's commit in freebsd or wherever is a good indication. 13:20:45 andyf: do those files get burned into the card if they're newer (if not, probably not going to help much with iPXE) 13:24:50 I thought they did, but I'm not 100% sure. 13:30:38 i've never used those cards unfortunately, so i don't know 13:31:37 Dec 28 02:20:48 gimlet-sn06 t4nex: WARNING: t4nex0: firmware on card (1.27.4.0) is older than the version bundled with this driver, installing firmware 1.27.5.0 on card. 13:33:16 Seems to survive a power cycle too 13:33:39 ahh nice 14:09:40 tsoome: do you have a binary for #14321 which I can install without having to update my system? 14:10:28 Thank you re: cxgbe 14:11:01 Agnar just a moment.... :) 14:13:06 actually http://84.50.115.54/loader.efi has it 14:13:53 thanks! 14:14:31 I wonder if that could solve my nvidia issues ;) 14:15:28 to verify, you should be able to find the allocated chunk (type loaderdata) with memmap command -- you would need to compare maps before and after... 14:16:10 what issue the nvidia has? 14:16:54 tsoome: vbios loading fails and I read something weird about uefi vbios fw from nvidia...I'm grabbing for every tine breach :) 14:17:57 jbk: Yes, the driver does update the device's SPI flash. 14:21:54 Agnar I doubt. Loader is using this area to boost screen updates and kernel will use its own allocation.... 14:24:08 and this does not really concern the card firmware itself because kernel will draw things by writing into framebuffer area... 14:28:58 danmcd: If it's alright, can we make sure to run through some extra testing stuff with firmware at our end just to help build confidence in regressions? 15:14:47 tsoome, well, *something* changed overnight. The export is working, and the mount on the test host reports sec=krb5 as expected. 16:02:45 nomad tim sync? 16:02:51 nomad time* 16:03:50 tsoome, we use kerberos heavily. I shouldn't have even been able to ssh to the fileserver if its clock were that off. 16:04:06 we do run ntp on all OmniOS hosts. 16:11:50 always worth to check. anyhow, as it is working now, and unless there is something in logs, it is impossible to tell what was wrong. 16:13:56 I did manually uncomment those lines 16:14:21 and then when restarting NFS serves didn't do anything I rebooted the host but testing right after the reboot showed no change. 16:25:30 I just tried again with my other test host, even after reboot the sharenfs command fails. 16:25:35 * nomad sighs 16:25:47 at least that one is in a test BE so I can just roll around and try things. 16:38:17 just as a sanity check, when transferring data from a disk (e.g. read, inquiry, log sense, etc) scsi_pkt->pkt_resid should reflect the amount of data the disk couldn't send (e.g. how much was truncated) because the supplied buffer was too small, right? 16:55:59 like say you want to read a log, so you send a log sense cdb w/ say 512 bytes, if the resulting log data is 512 bytes or less, you'd expect pkt_resid to be 0, and if pkt_resid was say 10, that'd suggest the device wanted to return 522 bytes, but could only write 512 (leaving 10 remaining) 16:56:18 tsoome, figured it out. 16:56:27 (there's some head-scratching things with the satl layer that's making me question my sanity on this :P) 16:56:40 I had installed pkg:/system/security/kerberos-5 so I could run kclient -n -T ms_ad but that run had failed. 16:56:57 I just installed security/kerberos-5 on the other test host and share -o sec=krb5 worked. 16:58:01 so there you go. Don't need to configure but do need something that package supplies. 17:27:21 jbk: I have no SCSI-specific knowledge on this but that's consistent with my memory of other things that have "resid" in their name. 18:36:26 yeah.. but (there's other examples in there) I see this: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/sata/impl/sata.c#L6099-L6113 18:36:41 so i like to make sure i'm not brain farting :) 18:36:47 like there's at least two thing wrong there 18:38:45 (alc_len is computed incorrectly, and it seems like pkg_resid is returning the amount of space left over in the buffer (basically inverted from what I thought it should be) 18:42:35 but at least sg_log fails on SATA disks.. and this is probably part of it 22:32:02 [illumos-gate] 16529 TIOCGWINSZ returns EINVAL on a freshly-created pty -- Bill Sommerfeld