08:51:20 <kathe> hello everybody. :)
09:29:58 <tsoome> hi
09:55:36 <Agnar> moin
14:52:47 <neirac> rmustacc we both typed the pci id  wrong, I tried dtrace but nothing useful, then read max brunning tutorial on drivers so I started all the way back and checked prtconf -vp for the id and realized we had it wrong !, just tried  update_drv -a -I pci1af4,1000.0' and now there is nic on the vm on oracle cloud, I'll re-create the smartos image with that to see if the smartos installer finishes
15:05:19 <neirac> rmustacc just tried now the nic works takes the dhcp from oracle cloud and ping works, seems we just needed the alias to make it work and bypass pit
15:06:41 <neirac> rmustacc oh, seems disks are missing 
15:15:37 <danmcd> neirac: Is this vioscsi'
15:16:07 <danmcd> https://smartos.org/bugview/OS-8418 hasn't yet been integrated.  I can literally build it.
15:16:20 <danmcd> Oooh and is pci1af4,1000 needed as well for vioif?
15:17:25 <danmcd> (I'm literally about to build the vioscsi  right now.  I can add the pci1af4,1000 for vioif too if you wish.  I can have an ISO for you in 75mins.)
15:20:08 <danmcd> @neirac ^^^
15:21:43 <neirac> danmcd  yes, it seems its viosci but when I tried update_drv -a -I pci1af4,1000  I got a kernel panic
15:22:05 <danmcd> Wait... pci1af4,1000 isn't vioscsi.
15:22:27 <danmcd> vioscsi "pci1af4,1004"
15:22:54 <danmcd> Does vioif ALSO have pci1af4,1000 in addition to pci1af4,1 ?
15:22:58 <neirac> https://pastebin.com/rLxLMpNW
15:23:26 <neirac> Oooh my mistake I used 1000 that was vioif again instead of 1100
15:23:32 <danmcd> Well, the panic is probably in need of fixing.
15:23:58 <danmcd> I'm about to build a fix for OS-8418 (the lack of vioscsi in SMartOS).  I'll include the pci1af4,1000 fix as well?
15:24:11 <danmcd> I'll have an ISO ready in 75mins or less.  Want this?
15:24:39 <neirac> Oh no the vioif was 1000 , I used 1100 for viosci  
15:25:07 <neirac> Vioif works viosci panics , I don't have the dump as I cannot install smartos yet due the lack of nic and disk 
15:25:29 <danmcd> Is 1100 what your prtconf is seeing?  I thought vioscsi is 1004.
15:25:43 <neirac> danmcd let me check again on the vm 
15:25:59 <danmcd> I'm going to fire off this build with vioscsi fix AND your additional vioif PCI  ID.
15:28:01 <neirac> danmcd thank you very much, my build take longer that 75 minutes oh, there is a thing I was hardcoding pit_is_broken=1 to allow boot using hpet on my images
15:28:13 <danmcd> Oh shit... need that too?
15:28:57 <neirac> Yes,  pit get stuck so we need to bypass it, if I do a git pull now from smartos live, should I get the fixes for vioif and vioscsi ?
15:29:21 <danmcd> No.
15:29:32 <danmcd> Still under review.  Really want it in before this WEd's branch however.
15:29:55 <danmcd> If you can bringup vioscsi on with what I"m building that'd be an excellent testing data point.
15:30:04 <neirac> Ok, I'll use your image I just use kmdb again to set pit_is_broken to 1
15:30:21 <danmcd> Oh I hardcoded it in, I think, but you can check with kmdb.
15:30:25 <danmcd> You want an ISO right?
15:30:38 <neirac> Yes, an iso please
15:30:40 <danmcd> I'll have it (or whatever deliverable you need) on kebe.com for download.
15:30:48 <danmcd> Watch here for the URL.
15:31:03 <neirac> Ok, thanks for your help!
17:58:21 <neirac> danmcd the platform iso works perfectly now vioif and vioscsi works just have problems installing smartos
18:35:41 <pmooney> tsoome: question regarding 15162 - would it be unreasonable to ask for a wsdiff of the binaries compiled from the updated rpcgen output against those from stock bits?
18:40:14 <richlowe> I don't think it's unreasonable, but it might be noisy regardless
18:41:42 <pmooney> may or may not be
18:41:49 <pmooney> if it was quiet, that'd be a nice bit of reassurance
18:42:03 <richlowe> the more useful thing would be to diff the source, honestly?
18:42:29 <richlowe> you'd really need both, to be sure
18:42:38 <pmooney> but we nominally know what the difference in the source should be
18:42:49 <pmooney> I just want to make sure our blessed compiler(s) aren't making some new weird decision based on that
18:43:33 * pmooney shrugs
18:44:45 <richlowe> yeah, I was just thinking double checking both meant we could work out what any differences were because of (hopefully)
18:45:09 <richlowe> also I honestly can't tell if you mean "blessed" or "blesséd"
18:45:11 <richlowe> but I hope it's the latter
18:46:48 <yuripv> what's the difference?
18:47:43 <richlowe> colloquially "blessed" as in "having been blessed", "blesséd" an intensifier like a PG rated "fucking".
18:48:42 <pmooney> oh, I definitely meant the former, haha
18:49:14 <andyf> Both seem appropriate a lot of the time.
18:49:40 <andyf> I am about to open some PRs against the blessed ones, coincidentally
18:50:21 <andyf> Oh, and pmooney, experiments mostly complete, omnios is growing -fforce-omit-frame-pointer
18:50:21 <richlowe> should I know things about them for merging into mine?
18:50:41 <andyf> (without the suggested -because-i-do-not-care-about-dtrace-and-mdb suffix)
18:50:48 <pmooney> andyf: exciting!  thanks for picking that up
18:50:58 <pmooney> I shouldn't have dropped the ball on it like I did
18:51:02 <richlowe> then probably I do
18:51:16 <andyf> richlowe - just teaching it that the kernel printf supports h and hh length modifiers
18:51:20 <richlowe> I hope gcc 10 primary is still ticking a long as time exists for you.
18:51:29 <richlowe> 'cos obviously I'm going to need it _eventually_
18:51:57 <andyf> Apart from the loader cpuid corruption bug, I'm not aware of any fallout from gcc10 primary, and it's been used for a couple of omnios releases now.
18:52:48 <andyf> (toomas found and fixed that bug)
18:53:04 <richlowe> time to switch properly when you have a breather at work?
18:53:29 <andyf> It was this fun one.. https://www.illumos.org/issues/14948
18:53:30 <fenix> → BUG 14948: loader: do_cpuid does corrupt memory when built with gcc 10 (Closed) | https://code.illumos.org/c/illumos-gate/+/2332
18:54:25 <richlowe> ouch
18:54:27 <andyf> I think everything's pretty much set to switch. I was going to spend some time removing 'static' from a load of tunables to try and enable '-fno-unit-at-a-time', but I'm less convinced that's a good idea
18:54:52 <andyf> and the transition with the exposed variable lists in IP would make that less fun too
18:54:54 <Agnar> good evening
18:55:12 <richlowe> the symbol lists in ip etc, which I think are related to ip instances, are annoying as hell.
18:55:31 <richlowe> they also change if you adjust the optimization levels of uts for any reason
18:55:39 <richlowe> so you can't do it temporarily without everything going sideways
18:56:23 <richlowe> I see the value of it, but I sure wish it could be better controlled, or there was a way to say "but these symbols don't matter", or.
18:56:27 <andyf> On balance, I think we should just make the switch.
18:56:55 <richlowe> because it called me out for `rcsid` or something like that, which didn't please me  
18:57:07 <andyf> Oh dear, yes
19:03:42 <tsoome> pmooney I'll create some wsdiff. hopefully gcc will eat away those default: cases.
19:04:11 <pmooney> yeah, that's my hope, thanks
19:06:27 <gitomat> [illumos-gate] 15156 WPTS FSA FileInfo_Query_FileModeInformation -- Gordon Ross <gwr⊙rc>
19:14:37 <gitomat> [illumos-gate] 15157 WPTS FSA FileInfo_Query_FilePositionInformation -- Gordon Ross <gwr⊙rc>
19:17:34 <gitomat> [illumos-gate] 15158 WPTS FSA FileInfo_Set_FileBasicInformation_Dir_Negative -- Gordon Ross <gwr⊙rc>
19:27:27 <tsoome> pmooney only debug info differences. issue updated.
19:27:52 <richlowe> dwarf or ctf?
19:29:06 <tsoome>  /code/15182/usr/src/lib/libidmap/amd64/pics/idmap_xdr.o
19:29:06 <tsoome> NOTE: ELF .debug_info difference detected.
19:29:25 <tsoome> thats what wasdiff report is telling
19:29:27 <richlowe> oh, I think we all assumed you'd run it on the proto areas
19:29:38 <richlowe> where dwarf wouldn't be :)
19:29:43 <richlowe> that's why I was confused, anyway
19:34:14 <danmcd> @neirac --> you should file a bug for the missing PCI ID for vioif (unless it's a special one for your particular cloud).
19:58:15 <jclulow> Even if it is a special one
19:58:36 <jclulow> as long as it doesn't break something else I imagine we would include it
19:58:39 <richlowe> yeah, bugs are lightweight and free, if something is broken or desirable, file one.
19:59:20 <richlowe> we don't even have a bot to come through and close them for no reason.
19:59:24 <richlowe> though I know jclulow loves that feature
19:59:49 <jclulow> I will burn down any building that contains stale bot
20:29:59 <tsoome> hm.... my robot is stuck sometimes, I'll keep that in mind.... :P
20:53:30 <danmcd> So am I on crack or is my filing of https://www.illumos.org/issues/15216 correct in that we need to specify "pci1af4,1000" for vioif as well?
20:53:31 <fenix> → BUG 15216: vioif should attach to device 0x1000 also (New)
20:55:07 <andyf> danmcd - I'm confused, certainly
20:55:25 <danmcd> neirac today had problems attaching to Oracle Cloud's vioif w/o this modification.
20:55:41 <andyf> bhyve presents vioif as 1af4,1000 and omnios guests attach ok
20:56:16 <danmcd> How?
20:56:42 <richlowe> remember `compatible`
20:56:50 <andyf> it ends up in the devices tree as                 name='compatible' type=string items=9
20:56:50 <andyf>                     value='pci1af4,1000.1af4.1.0' + 'pci1af4,1000.1af4.1' + 'pci
20:56:50 <andyf> 1af4,1,s' + 'pci1af4,1' + 'pci1af4,1000.0' + 'pci1af4,1000,p' + 'pci1af4,1000' +
20:56:50 <andyf>  'pciclass,020000' + 'pciclass,0200'
20:57:31 <richlowe> so svid/spid there?
20:57:43 <danmcd> Ahhh compatiable.
20:57:50 <andyf> checking with pcieadm
20:57:58 <danmcd> Some hosts aren't so generous, I'm guessing.
20:58:06 <richlowe> perhaps oracle's hypervisor doesn't list the full set?
20:58:18 <andyf> https://paste.ec/paste/J2VlSZ16#Y4dhX-WjzMonBmIS5mSx6g89G9stGG7/P00OOe0F+yQ
20:58:19 <danmcd> richlowe: I'll bet it doesn't.
20:58:25 <andyf> won't paste this time, sorry about that
20:58:36 <danmcd> It pasted enough.
20:58:59 <andyf> we should put 0x1000 in though
20:59:36 <danmcd> I'll submit a gerrit.  I want this in this week's SmartOS (and will do so regardless of upstream acceptance).
21:01:29 <jclulow> If it works I'll approve it lol
21:02:29 <danmcd> neirac already tested it for me as part of his headbanging against Oracle Cloud.
21:04:18 <richlowe> it'd be nice to see pcieadm prtconf etc from the system
21:04:31 <richlowe> just to see what they're doing, and get it written down
21:07:46 <danmcd> https://code.illumos.org/c/illumos-gate/+/2535
21:07:47 <fenix> → CODE REVIEW 2535: 15216 vioif should attach to device 0x1000 also (NEW) | https://www.illumos.org/issues/15216
21:30:04 <sjorge> do tou
21:30:22 <sjorge> oops, focus issues
21:33:55 <rmustacc> Yeah, this is a case where we may want to be explicit about using the primary versus subsystem IDs.
21:36:55 <andyf> I'm on a linux box in Oracle's cloud, and trying to make lspci show me all the IDs..
21:37:34 <andyf> Here - https://paste.ec/paste/LCWbSDsN#i6i6XMMU++Ig3VykUFTDKOFStSKReuwnledRLatkZ+-
21:51:25 <andyf> @rmustacc - are you suggesting alias=pci1af4,1000,p  ?
21:52:42 <rmustacc> I'll need to double check the oasis spec.
21:53:00 <rmustacc> But in general, when we're adding new pci and not pciex ids, we want to be specific unless binding to the subsystem is correct.
21:53:03 <rmustacc> It's not for most things.
21:53:05 <rmustacc> It may be here.
21:55:40 <rmustacc> So I would probably move it to ,p for both given the text in https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-1020002
21:55:53 <rmustacc> But then again given that we're relying on the subsystem match for bhyve today, not sure where else we are.
21:56:00 <rmustacc> So I might only do it for the new ID.
21:58:23 <andyf> 4.1.2.3 is interesting
21:58:33 <andyf> > Transitional devices MUST have the PCI Subsystem Device ID matching the Virtio Device ID,
21:58:46 <andyf> which is why bhyve has a the subsystem did of 1, presumably
22:06:20 <otis> in oracle cloud in freebsd image, network is vendor=0x1af4 device=0x1041 subvendor=0x108e subdevice=0x1100
22:06:27 <otis> arm64
22:06:45 <otis> was this an amd64?
22:15:56 <danmcd> @rmustacc --> please state your ,p suggestion on the advocates list?  Also, if you're listening @neirac I'll have to spin a new one for you to confirm/deny on Oracle Cloud.
23:23:48 <neirac> danmcd I'm going the route to use ipxe there as  using dd to write to disk seems to not work on the installer