15:39:45 <gitomat> [illumos-gate] 17006 ZTS: left over spare-dev1 and spare-dev2 -- Toomas Soome <tsoome⊙mc>
17:27:32 <twobitsahead> Hello, I'm scratching my head at something to do with ioctl() and TIOCGWINSZ. I am trying to find the width of the screen. Here's the C code https://pastebin.com/Ejd9N8mU which does run on Linux, but not on OpenIndiana. Here's the error being produced while trying to compile the same code on OpenIndiana https://pastebin.com/7pPY9URi
17:28:42 <twobitsahead> I read through the ioctl manual pages, and Google, and haven't come across much useful information as to what is causing this issue
17:31:11 <rmustacc> twobitsahead: So when I looked at the manuals that mention the winsize structure, I'd expect you to have to include termios.h.
17:31:41 <rmustacc> Including that makes it work for me and is where POSIX defines it to be in POSIX 2024.
17:31:48 <rmustacc> (You also don't need sys/ioctl.h).
17:32:40 <twobitsahead> That solved it
17:32:42 <twobitsahead> Thank you!
17:33:54 <rmustacc> https://illumos.org/man/4I/termio is what I was looking at for some context.
17:35:59 <twobitsahead> Thanks, I was just Googling for this. I don't know how this didn't turn up / how I missed this during the search. This is the page that I have been looking for
17:37:06 <rmustacc> All good, glad it's sorted.
18:07:35 <gitomat> [illumos-gate] 17016 libzfs: zpool_clear_label fixes -- Ahelenia Ziemiańska <nabijaczleweli⊙nx>
18:24:14 <gitomat> [illumos-gate] 16960 nxge: possible memory leak -- Toomas Soome <tsoome⊙mc>
18:52:57 <jimklimov> Cheers, is anyone planning to meet up at FOSDEM this year? Is there an illumos table this time? Any events before/after the weekend itself (e.g. hackathons etc.)? :)
18:56:58 <nomad> jclulow, so far testing of the new tar binary is going well. I've started a huge set that will take a few days to create the tarball and a few more to extract/verify but so far I'm not seeing any red flags.
19:01:21 <andyf> jimklimov - there is a planned dinner on the Friday, see https://illumos.topicbox.com/groups/discuss/Te4c03ebcea1e86d2-M7533e75de1778dc0dc269c49/fosdem25-illumos-and-friends-dinner
19:02:31 <andyf> but unfortunately no table/stand. It is becoming more Linux-centric each year.
19:05:43 * nomad realizes he should update the ticket with that information... (pls. pardon the duplication).
19:13:43 <jimklimov> thanks for the info, hope to be there (and go at all this year)
21:07:56 <tsoome> sigh.... panic[cpu1]/thread=fffffe00108e2c20: programming error: LBA out of range in cmd fffffe0bddf7b840
21:09:23 <tsoome> we do get blown up too eagerly 
21:13:12 <richlowe> not sure what you're getting at
21:13:49 <richlowe> I wish I could find the time, or find a victim, to fix dev_err(..., CE_PANIC, ...)  though
21:14:07 <richlowe> it pretty obviously should prepend the formatted dev to the panic string
21:14:17 <tsoome> well, in this case, we got LBA from (bad) disk label, attempted to use it and nvme did panic;)
21:14:44 <richlowe> Right, that seems like a fatal programming error?
21:14:49 <richlowe> I think
21:15:08 <richlowe> it seems like the theory is the consumer (label?) sanity checks itself?
21:16:12 <tsoome> well, the label structure was good;) just that the LBA numbers were bad.
21:19:10 <tsoome> ofc the question would be, should cmlb verify the data properly (probably it should) or should nvme error out there (and not panic?) or both:)
21:24:12 <richlowe> nvme seems written on the assumption cmlb would check
21:24:24 <richlowe> I don't claim to know whether that's a good idea, just that it seems to be what nvme thinks should happen
21:24:48 <richlowe> it seems like every command field it doesn't like we .panic on, anyway 
21:24:58 <tsoome> kind of makes sense, well that is quite clear that cmlb should check.
21:25:04 <richlowe> except for the charming, `NVME_CMD_F_DONTPANIC`
21:25:16 <richlowe> which I haven't looked deeper into yet
21:25:39 <richlowe> it seems to mean "This came from userland, just fail"
21:59:46 <jclulow> nomad: Thanks!
22:00:24 <rmustacc> Yes, I think most blkdev consumers are written assuming they're getting mostly valid I/O requests.
22:01:14 <jclulow> I think if we're going to panic down there, then blkdev should probably handle checking for out of range I/O on its own based on what it gets told about the size of the disk
22:15:46 <gitomat> [illumos-gate] 16964 ptrconf: potential memory corrupting cast 4 vs 1 bytes -- Toomas Soome <tsoome⊙mc>
23:18:47 <tsoome> https://www.illumos.org/issues/17029
23:18:48 <fenix> → BUG 17029: cmlb should check label better (New)