! In D54745#1259084, @adrian wrote:
my POWER8 box does, but that may not be good enough?

In D54745#1258964, @tpearson_raptorengineering.com wrote:

When testing, does anyone else have access to a SATA controller that does DMA? I'm sporadically seeing the Blackbird's AHCI controller lock up but I don't know if this is a PE freeze, bad DMA, or something completely unrelated (flaky cabling?):

ahcich1: is ffffffff cs ffffffff ss ffffffff rs ffffffff tfd ffffffff serr ffffffff cmd ffffffff
(ada0:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 40 e8 35 8b 40 24 00 00 00 00 00
(ada0:ahcich1:0:0:0): CAM status: Command timeout
ahcich1: AHCI reset...
(ada0:ahcich1:0:0:0): Retrying command, 3 more tries remain
ahcich1: stopping AHCI engine failed
ahcich1: SATA connect timeout time=100000us status=ffffffff
ahcich1: AHCI reset: device not found
pass0 at ahcich1 bus 0 scbus1 target 0 lun 0
pass0: <Hitachi HDS722020ALA330 JKAOA3MA> s/n JK11A8B9H82U0F detached
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0: <Hitachi HDS722020ALA330 JKAOA3MA> s/n JK11A8B9H82U0F detached
g_vfs_done(): ada0p2 converting all errors to ENXIO
g_vfs_done():ada0p2[WRITE(offset=212411777024, length=32768)]error = 6 suppressing further ENXIO
panic: UFS: root fs would be forcibly unmounted

@adrian Could you give this patch set a thorough test as well? It is not dependent on D54745, I mainly want some additional testing without this on top of D54745 and a merge before going to the next phase of IOMMU enablement. D54745 has some issues with DMA and the AHCI controller that I don't currently understand and will need further investigation.

When testing, does anyone else have access to a SATA controller that does DMA? I'm sporadically seeing the Blackbird's AHCI controller lock up but I don't know if this is a PE freeze, bad DMA, or something completely unrelated (flaky cabling?):

Do It!

(I still haven't forgotten about this diff; I'm going to test it in VMs and on power8 hardware this week.)

This is sort of WIP - there's some TODOs in here. I'd like some feedback on the locking changes and whether I missed something. Thanks!

ok so I had a chat with jessica, and after some more digging to try and understand what's going on here, I see both views:

In D54246#1254644, @kib wrote:

In D54246#1254643, @adrian wrote:

ok, but on insistence from jrtc27 i added some debug logging here and it's never actually invoking syncicache in my tests.

This does not mean much. It only shows that the current binaries do not have this issue. But old binaries might have, then removing the hack breaks them.

In D54246#1254643, @adrian wrote:

ok, but on insistence from jrtc27 i added some debug logging here and it's never actually invoking syncicache in my tests.

ok, but on insistence from jrtc27 i added some debug logging here and it's never actually invoking syncicache in my tests.

cleanup

In D54246#1254603, @adrian wrote:

This works for me on freebsd-16 on power8, I'm doing test buildworld -j32 on it right now!

This works for me on freebsd-16 on power8, I'm doing test buildworld -j32 on it right now!

remove extra mttb()

don't duplicate the section, thanks ppl

In D54745#1253492, @adrian wrote:

ok, now that i have power8 hardware up and running, what should i be on the lookout for?
Just the same devinfo/dmesg resource assignment, devices found, etc?

ok, now that i have power8 hardware up and running, what should i be on the lookout for?
Just the same devinfo/dmesg resource assignment, devices found, etc?

I'm in the process of documenting / getting powernv8 and powernv9 qemu guests up and running.
(And I now have a power8 booting freebsd powernv so I can test it on real hardware as well.)

Adding the wider powerpc umbrella, so others can take a look as well.

the "extint-gpio1" check returned NULL

The type NULL checks are good. I think the whole of the changes for pmu_send() are a bit overkill. Could you test with just the one line I pointed out, and the rest reverted?

In D54639#1248394, @imp wrote:

You could combine the two lines too by

OFFSET=$((0x$(hd...) ))