07:23:07 <jclulow> rzezeski: https://www.illumos.org/issues/16328 haha
07:23:08 <fenix> → BUG 16328: IP Filter code is ifdef soup (New)
07:25:08 <jclulow> I guess https://www.illumos.org/issues/3017 also contains some notes about where I think we could probably go
07:25:09 <fenix> → FEATURE 3017: Upgrade IPFilter to 5.1.2 (New)
07:37:17 <tsoome_> wouldn't it better to put this effort to pf instead?
07:48:09 <Woodstock> why pf and not npf? :)
07:49:00 <tsoome_> or npf. something what is actually not dead....  :)
08:11:20 <tsoome_> well, I mean, sure, its good to get ipf cleaned while we still do have it and we most likely will have it for a while (like fbsd is having 3 packet filters;)
08:53:51 <warden> Hi to all, I added relevant lines of my IPFilter configuration (ipf6.conf, ipnat.conf) in the same file (https://box.messagecloud.it/index.php/s/2Agx3n367zmi6M8)
08:55:07 <warden> Please let me know if/how I can help you to further analyze the problem. And thank you so much for your invaluable support!
10:09:43 <tsoome_> what you get from ::stack -t
10:12:11 <warden> tsoome_: I just added the output of "::stack -t" to the same file, thanks!
10:22:00 <tsoome_> ok, so fr_tcp_age() does not have call to mutex_enter(), but at fr_tcp_age+0x25b it calls fr_movequeue() which does have mutex_enter calls (2), so the question would be, which one is blowing us up. 
10:35:40 <tsoome_> if you can reproduce the crash, then it would be good to get dtrace -n 'ipf:fr_movequeue:entry {printf("tqe: 0x%p oifq: 0x%p nifq: 0x%p ifs: 0x%p", arg0, arg1, arg2, arg3);}'  or something like that, so we can try to check oifq and nifq 
10:55:48 <warden> unfortunately, as you can see in the first lines of that file, crashes are very sporadic and I do not have idea about how to reproduce. That command should be run immediately before the crash?
11:11:05 <tsoome_> you can have dtrace running in terminal with history, so you could catch the output;)
11:58:16 <rzezeski> warden: I updated the 17584 ticket with some of your details. The trick is going to be someone finding the time to dig into it more.
13:17:48 <warden> rzezeski: thanks! It would help if I'll make you available the vmdump file?
18:04:35 <jayjwa> I got OpenIndiana to boot via bhyve, but it has no GUI at startup. Looks like it's trying to use Nvidia. At least it mentions Nvidia in the startup errors. Is there any parameter I can give bhyve to set the GPU so OI boots to GUI?
18:05:42 <jayjwa> I ask because last time I tried (via Qemu) it did boot to GUI but I wanted to use bhyve.
18:19:29 <danmcd> jayjwa: It's theoretically possible to use PCI Pass-through if you have an Intel CPU, but I've heard it's not practical.
18:29:43 <jayjwa> It's AMD. I made the system unbootable messing with passthru awhile back. Maybe just XDM and remote X is the best way to do this. 
19:12:04 <sommerfeld> jayjwa: the nvidia message at boot is printed regardless of what graphics hardware is present.   it means that the driver is installed; it does not mean "it's trying to use Nvidia" in any real sense.
19:29:13 <jayjwa> I see. Wonder why it went to GUI with Qemu but not Bhyve then?
19:52:40 <sommerfeld> may depend on what devices were configured in the guest.   I haven't tried openindiana GUI under bhyve (haven't needed it).