I just filed fenix illumos#16537 and I have a dumb question.

BUG 16537: cxgbe: update firmware version to 1.27.5.0 (New)

↳ illumos.org/issues/16537

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.

you mean fwflash?

also i thought it was delivered as a binary blob in the driver

though i suppose that doesn't help with ipxe

it looks like there might be an ioctl to do it, but no glue to use it in fwflash

danmcd: you can simply copy it to /kernel/firmware/cxgbe/ and then change the symlink for the relevant tNfw.bin file.

nomad you are missing few packages

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

jbk it was, but I split that out into files a while ago.

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.

andyf: do those files get burned into the card if they're newer (if not, probably not going to help much with iPXE)

I thought they did, but I'm not 100% sure.

i've never used those cards unfortunately, so i don't know

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.

Seems to survive a power cycle too

ahh nice

tsoome: do you have a binary for #14321 which I can install without having to update my system?

Thank you re: cxgbe

Agnar just a moment.... :)

actually 84.50.115.54/loader.efi has it

thanks!

I wonder if that could solve my nvidia issues ;)

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

what issue the nvidia has?

tsoome: vbios loading fails and I read something weird about uefi vbios fw from nvidia...I'm grabbing for every tine breach :)

jbk: Yes, the driver does update the device's SPI flash.

Agnar I doubt. Loader is using this area to boost screen updates and kernel will use its own allocation....

and this does not really concern the card firmware itself because kernel will draw things by writing into framebuffer area...

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?

tsoome, well, *something* changed overnight. The export is working, and the mount on the test host reports sec=krb5 as expected.

nomad tim sync?

nomad time*

tsoome, we use kerberos heavily. I shouldn't have even been able to ssh to the fileserver if its clock were that off.

we do run ntp on all OmniOS hosts.

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.

I did manually uncomment those lines

and then when restarting NFS serves didn't do anything I rebooted the host but testing right after the reboot showed no change.

I just tried again with my other test host, even after reboot the sharenfs command fails.

at least that one is in a test BE so I can just roll around and try things.

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?

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)

tsoome, figured it out.

(there's some head-scratching things with the satl layer that's making me question my sanity on this :P)

I had installed pkg:/system/security/kerberos-5 so I could run kclient -n -T ms_ad but that run had failed.

I just installed security/kerberos-5 on the other test host and share -o sec=krb5 worked.

so there you go. Don't need to configure but do need something that package supplies.

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.

yeah.. but (there's other examples in there) I see this: github.com/illumos/illumos-gate/blo…mon/io/sata/impl/sata.c#L6099-L6113

so i like to make sure i'm not brain farting :)

like there's at least two thing wrong there

(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)

but at least sg_log fails on SATA disks.. and this is probably part of it

[illumos-gate] 16529 TIOCGWINSZ returns EINVAL on a freshly-created pty -- Bill Sommerfeld <sommerfeld⊙ho>