01:40:16 jbk: Right, it's kind of the model, for better or worse. I just put a 64KB buffer on the stack to pass to the handler routine, and to give to door return on the way out: https://github.com/oxidecomputer/doorjamb/blob/main/src/server.rs#L82-L109 01:47:19 yeah, i think i did something similar.. though I think I used a pthread key + destructor to at least clean things up whenever the door thread was terminated... 01:47:23 (in C) 01:47:59 when passing around data in packed nvlists 01:49:10 (I figured that was probably less error-prone esp. if the caller is untrusted) 01:49:43 since IIRC libnvpair has gone through a fair amount of fuzzing (by Alex I think) 19:50:50 jbk: if people have afl setups for that, it'd be great to get them into usr/src/test 19:51:09 danmcd: you know how to reach arekinath, I guess 19:52:29 speaking of that.. does anyone know if our gcc is built so it can work with afl? 19:52:45 the pkgsrc gcc is not (it hardcodes absolute paths into the driver IIRC) 19:52:56 so afl can't 'interpose' (for lack of a better term) on the compilation 19:53:19 can it not use specs to avoid that? 19:55:16 (which is basically what I do to make things depend on the smaller -libs packages instead of the full gcc) 19:55:32 it's been a while, but my recollection is that it uses -B 19:55:45 which doesn't work if gcc hardcodes an absolute path 19:56:09 or something like that 19:56:36 -B should work regardless, but perhaps do too much 19:56:43 spec override should work regardless 19:57:02 I don't know about about it's build configuration based 19:57:04 perhaps, but then we'd need to fork afl 19:57:20 is afl assuming cc1 is in $PATH or something? 19:57:30 I don't understand what mis(?)-configuration is happening. 19:57:35 when I was fuzzing the C++ demangler, I had to use clang to build the fuzzed bin as I recall 19:57:58 sounds like questions for arekinath if Dan can rouse 19:58:19 but yeah, I'd really like fuzz setup in test/ (but _not_ in the main test suites) 19:58:22 the only "hardcoding" I'm aware of is that we set local prefix so that users can compile stuff out of the box, I don't think that's unusual 19:58:36 the header namespace tests have taught me that long-running low-churn things in the main suites sure do suck someimes 19:58:51 i think it was the path for the assembler something like instead of it being specified relative to some sort of 'gcc root', pkgsrc was doing /opt/local/....../gas 19:59:09 ok, yeah, --with-* for those take absolute paths 19:59:13 and I think we tend to give them 19:59:27 it's been several years now so details have faded :) 19:59:30 but I still don't understand how that bubbles up to afl I guess 19:59:47 happy to take a look if you can give me something to test 19:59:58 jbk: yeah, no, I'm not complaining about your explanation. I'm just really confused 20:00:16 and I'm _really_ eager to have fuzzing of untrusted data consumers right there in usr/src/test 20:05:56 I haven't in a while richlowe. 21:12:36 hi all, trying to get OpenIndiana on a AMD FX8350, ASUS Sabertooth 990FX motherboard; FreeBSD installs and runs cleanly on it but I have the machine shutting itself down during the boot process of the installer 21:12:48 any ideas as to how to get further with it 21:13:43 is the AMD IOMMU involved perhaps, there are different settings in the BIOS for it; booting off a CD I burned, to avoid any USB/EHCI issues 21:32:15 shmorg83: if you get to boot menu, press esc and on ok prompt enter: boot -kdv -B prom_debug=true,kbm_debug=true 21:36:27 that will, if it works, drop you into the debugger eventually, btw. 21:36:38 best to warn people about -d tsoome :) 21:36:51 yep:) 21:38:08 once on mdb prompt, just type ::cont 23:34:57 so it initialized all the CPUs, cpu0 to cpu7, after the line "cpu7 initialization complete - online" I get 23:35:25 WARNING: xhci2: abort command timed out: resetting device 23:36:29 panic[cpu1]/thread=fffffe003d0c4c20: XHCI runtime reset required 23:36:45 Warning - stack not written to the dump buffer 23:38:01 fffffe003d0c4b50: xhci:xhci_taskq+33b8498f () 23:38:41 fffffe003d0c4c00: genunix:taskq_thread+2a6 () 23:39:09 fffffe003d0c4c10: unix:thread_start+b () 23:39:16 then panic entering debugger etc. 23:39:38 so is it something to do with XHCI, is that USB2 and USB3 ?