hello everybody. :)

hi

moin

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

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

rmustacc oh, seems disks are missing

neirac: Is this vioscsi'

smartos.org/bugview/OS-8418 hasn't yet been integrated. I can literally build it.

Oooh and is pci1af4,1000 needed as well for vioif?

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

@neirac ^^^

danmcd yes, it seems its viosci but when I tried update_drv -a -I pci1af4,1000 I got a kernel panic

Wait... pci1af4,1000 isn't vioscsi.

vioscsi "pci1af4,1004"

Does vioif ALSO have pci1af4,1000 in addition to pci1af4,1 ?

Oooh my mistake I used 1000 that was vioif again instead of 1100

Well, the panic is probably in need of fixing.

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?

I'll have an ISO ready in 75mins or less. Want this?

Oh no the vioif was 1000 , I used 1100 for viosci

Vioif works viosci panics , I don't have the dump as I cannot install smartos yet due the lack of nic and disk

Is 1100 what your prtconf is seeing? I thought vioscsi is 1004.

danmcd let me check again on the vm

I'm going to fire off this build with vioscsi fix AND your additional vioif PCI ID.

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

Oh shit... need that too?

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 ?

No.

Still under review. Really want it in before this WEd's branch however.

If you can bringup vioscsi on with what I"m building that'd be an excellent testing data point.

Ok, I'll use your image I just use kmdb again to set pit_is_broken to 1

Oh I hardcoded it in, I think, but you can check with kmdb.

You want an ISO right?

Yes, an iso please

I'll have it (or whatever deliverable you need) on kebe.com for download.

Watch here for the URL.

Ok, thanks for your help!

danmcd the platform iso works perfectly now vioif and vioscsi works just have problems installing smartos

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?

I don't think it's unreasonable, but it might be noisy regardless

may or may not be

if it was quiet, that'd be a nice bit of reassurance

the more useful thing would be to diff the source, honestly?

you'd really need both, to be sure

but we nominally know what the difference in the source should be

I just want to make sure our blessed compiler(s) aren't making some new weird decision based on that

yeah, I was just thinking double checking both meant we could work out what any differences were because of (hopefully)

also I honestly can't tell if you mean "blessed" or "blesséd"

but I hope it's the latter

what's the difference?

colloquially "blessed" as in "having been blessed", "blesséd" an intensifier like a PG rated "fucking".

oh, I definitely meant the former, haha

Both seem appropriate a lot of the time.

I am about to open some PRs against the blessed ones, coincidentally

Oh, and pmooney, experiments mostly complete, omnios is growing -fforce-omit-frame-pointer

should I know things about them for merging into mine?

(without the suggested -because-i-do-not-care-about-dtrace-and-mdb suffix)

andyf: exciting! thanks for picking that up

I shouldn't have dropped the ball on it like I did

then probably I do

richlowe - just teaching it that the kernel printf supports h and hh length modifiers

I hope gcc 10 primary is still ticking a long as time exists for you.

'cos obviously I'm going to need it _eventually_

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.

(toomas found and fixed that bug)

time to switch properly when you have a breather at work?

It was this fun one.. illumos.org/issues/14948

→ BUG 14948: loader: do_cpuid does corrupt memory when built with gcc 10 (Closed) | code.illumos.org/c/illumos-gate/+/2332

ouch

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

and the transition with the exposed variable lists in IP would make that less fun too

good evening

the symbol lists in ip etc, which I think are related to ip instances, are annoying as hell.

they also change if you adjust the optimization levels of uts for any reason

so you can't do it temporarily without everything going sideways

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.

On balance, I think we should just make the switch.

because it called me out for `rcsid` or something like that, which didn't please me

Oh dear, yes

pmooney I'll create some wsdiff. hopefully gcc will eat away those default: cases.

yeah, that's my hope, thanks

[illumos-gate] 15156 WPTS FSA FileInfo_Query_FileModeInformation -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15157 WPTS FSA FileInfo_Query_FilePositionInformation -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15158 WPTS FSA FileInfo_Set_FileBasicInformation_Dir_Negative -- Gordon Ross <gwr⊙rc>

pmooney only debug info differences. issue updated.

dwarf or ctf?

/code/15182/usr/src/lib/libidmap/amd64/pics/idmap_xdr.o

NOTE: ELF .debug_info difference detected.

thats what wasdiff report is telling

oh, I think we all assumed you'd run it on the proto areas

where dwarf wouldn't be :)

that's why I was confused, anyway

@neirac --> you should file a bug for the missing PCI ID for vioif (unless it's a special one for your particular cloud).

Even if it is a special one

as long as it doesn't break something else I imagine we would include it

yeah, bugs are lightweight and free, if something is broken or desirable, file one.

we don't even have a bot to come through and close them for no reason.

though I know jclulow loves that feature

I will burn down any building that contains stale bot

hm.... my robot is stuck sometimes, I'll keep that in mind.... :P

So am I on crack or is my filing of illumos.org/issues/15216 correct in that we need to specify "pci1af4,1000" for vioif as well?

→ BUG 15216: vioif should attach to device 0x1000 also (New)

danmcd - I'm confused, certainly

neirac today had problems attaching to Oracle Cloud's vioif w/o this modification.

bhyve presents vioif as 1af4,1000 and omnios guests attach ok

How?

remember `compatible`

it ends up in the devices tree as name='compatible' type=string items=9

value='pci1af4,1000.1af4.1.0' + 'pci1af4,1000.1af4.1' + 'pci

1af4,1,s' + 'pci1af4,1' + 'pci1af4,1000.0' + 'pci1af4,1000,p' + 'pci1af4,1000' +

'pciclass,020000' + 'pciclass,0200'

so svid/spid there?

Ahhh compatiable.

checking with pcieadm

Some hosts aren't so generous, I'm guessing.

perhaps oracle's hypervisor doesn't list the full set?

richlowe: I'll bet it doesn't.

won't paste this time, sorry about that

It pasted enough.

we should put 0x1000 in though

I'll submit a gerrit. I want this in this week's SmartOS (and will do so regardless of upstream acceptance).

If it works I'll approve it lol

neirac already tested it for me as part of his headbanging against Oracle Cloud.

it'd be nice to see pcieadm prtconf etc from the system

just to see what they're doing, and get it written down

→ CODE REVIEW 2535: 15216 vioif should attach to device 0x1000 also (NEW) | illumos.org/issues/15216

do tou

oops, focus issues

Yeah, this is a case where we may want to be explicit about using the primary versus subsystem IDs.

I'm on a linux box in Oracle's cloud, and trying to make lspci show me all the IDs..

Here - paste.ec/paste/LCWbSDsN#i6i6XMMU++Ig3VykUFTDKOFStSKReuwnledRLatkZ+-

@rmustacc - are you suggesting alias=pci1af4,1000,p ?

I'll need to double check the oasis spec.

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.

It's not for most things.

It may be here.

So I would probably move it to ,p for both given the text in docs.oasis-open.org/virtio/virtio/v…virtio-v1.1-csprd01.html#x1-1020002

But then again given that we're relying on the subsystem match for bhyve today, not sure where else we are.

So I might only do it for the new ID.

4.1.2.3 is interesting

> Transitional devices MUST have the PCI Subsystem Device ID matching the Virtio Device ID,

which is why bhyve has a the subsystem did of 1, presumably

in oracle cloud in freebsd image, network is vendor=0x1af4 device=0x1041 subvendor=0x108e subdevice=0x1100

arm64

was this an amd64?

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

danmcd I'm going the route to use ipxe there as using dd to write to disk seems to not work on the installer