Calamity,
After doing more testing, I have found something interesting. I am starting to wonder if the lack of vblank interrupts has some other cause than the J-Pac, seeing that the AVGA cab is on J-Pac and from the results of my tests. I basically did some changes and forced EDID's, that doesn't seem to be a problem, so then bypassed the path taken for the lack of DDC, and oddly that doesn't make a difference (just makes every output say it's connected all the time, but still things work fine too when that's done). The key though is that I started booting without any monitor connected and did see the same messages output you see, no EDID check and pretty much the same. It still does vblank interrupts, page flipping, that way. So from what I can tell, that is the most close to a J-Pac because there's nothing connected according to the hardware/kernel and still the interrupts happen here. So there's this message though in your dmesg output:
Jan 6 12:14:24 GroovyArcade kernel: [ 1.570616] radeon 0000:02:00.0: PCI: Disallowing DAC for device
Jan 6 12:14:24 GroovyArcade kernel: [ 1.570678] radeon: No suitable DMA available.
Which is definitely a bit odd, and even though Alex Deucher didn't think that mattered I am starting to think it is the key. That there's something different about Linux supporting your motherboard/processor and the Radeon iommu possibly. That it essentially is refusing to run DMA and any kind of interrupts/transfers to that card, odd, my setup is a 4350 too, but if not the ATI card branding/setup difference it's something else probably.
So we might not have a generic J-Pac issue, it may just be a non-supported hardware combination for advanced OpenGL/DRM vblank from the hardware and interrupts from the video card.
I do have a test version you can try, I don't think it'll help but might at least be interesting and get past any possibility of it being something really that we can fix in the radeon driver code. Otherwise this might be some completely different Linux kernel issue :/.
There's a test LiveCD version uploading in the LiveCD/Incoming/ folder right now, a Mini build so it's smaller, and when it appears in a few hours you can try it when you have time and see what the messages look like from it. I'm still not sure if this is a good change, only if it helps this problem probably, else it's really kinda odd because it forces every arcade monitor to act more like mine with the d9800 and sees a false DDC but gets a NULL EDID (seems most likely my d9800 is just NULL/not there, but DDC is there still just doesn't find an EDID so it's in between J-Pac and a normal EDID monitor).
This will be the test version when it's uploaded : LiveCD32-Mini-NMO-1.282-b299821.iso
Good news is the newer ISO I uploaded today has all the Multitasking + vsync support and on the 32 bit CD now I can use virtua racer with 130% cpu usage (both CPU's) and still get perfect vsync, so it's definitely no longer limited to the single CPU with that option after our patches to Mame for that. I think running in that mode has probably made the waitvsync option feel a lot better, since it's now threading the two processes still, and also looks like it can really utilize both CPU's too.