03:22 <lina> eiln: If nobody else figures out what's up with M2 by Wednesday I'll spend that stream trying to fix it, hopefully that's the last one ^^

04:49 <jonmasters> the issue I had earlier was a simple confusion of the two different sets of dtbs

04:50 <jonmasters> kernel (as presented by m1n1) vs the hardware ones

04:51 <jonmasters> that's the good news, as is that I was able to build and boot sven 's older USB4 test patches

04:51 <jonmasters> alas the enclosure I attach is not detected

04:54 <jonmasters> I rescind that

04:54 <jonmasters> It just came up

04:54 <jonmasters> :)

05:21 <eiln> lina: is it still DART/DAPF? I will tune in if you do stream

05:27 <jonmasters> however the PCI devices inside the enclosure are not seen...I see why these patches are where they are :)

05:27 <jonmasters> OTOH learning quite a lot about how you all put this together, which is fun

05:56 <lina> eiln: I'm not sure. I looked through DART/DAPF config and couldn't find anything interesting. My suspicion right now is something missing in the reset/power sequencing.

05:57 <lina> Usually it dies on the second stream, sometimes the first, sometimes it lasts until the third. It never dies during probe, and the problem always happens on the first frame or after a few frames rarely. So I think something is wrong with the PIODMA hardware, like something doesn't get reset/initialized properly and it raises an error.

05:58 <lina> I've never seen any DART faults related to this and the addresses it prints during the PIODMA errors are always valid...

05:58 <lina> The only consistent part is one of the addresses is always within one of the firmware allocations, but that could be the actual problem or just a coincidence that it's always the last thing it touched when the problem happens... Either way I didn't see anything wrong with that allocation...

06:34 <eiln> lina: "[ERROR] PIODMA[0] Irq Error! ErrorCount: 1" in https://gist.github.com/jannau/139b7599dbae683e41b5dc12aa3ad889, right? PIODMA is DART->MMIO

06:57 <eiln> lina: sounds like we're not cleaning up properly? j293ap they call CMD_STOP then CMD_POWER_DOWN. commands obviously don't send after CMD_STOP, so CMD_POWER_DOWN never succeeds. but CMD_POWER_DOWN doesn't succeed, ever, actually (same in facetimehd repo). I used CMD_SUSPEND instead because CMD_STOP actually causes a DART fault and makes ASC unrecoverable, I think they mess with

06:57 <eiln> power

06:57 <eiln> > AppleH13CamIn::ISP_Suspend - retries=20 ASCWRAP_IDLE_STATUS = 0x0

06:57 <eiln> > AppleH13CamIn::ISP_Suspend - ISPCPU not in WFI after CISP_CMD_POWER_DOWN

06:57 <eiln> > AppleH13CamIn::ISP_Suspend - Firmware timeout: 0, type: 3, cmdID: 0xffff, res: 0, isISPCPUNotInWFI: 1 indicate dirty shutdown to DART driver

06:58 <eiln> that happens every run

09:02 <sven> jonmasters: does it show up in boltctl?

16:14 <jonmasters> Sven: Will look

16:15 <jonmasters> Btw I was thinking with M2 nested virt m1n1 is potentially gonna be very interesting - but of course you thought of this a long time ago

19:58 <sven> essentially I want to know if the issue is in the thunderbolt or the pcie controller

19:59 <sven> So far I haven’t seen a device that wouldn’t show up inside the thunderbolt layer so if you have an enclosure with that issue I’m very interested

20:04 <janneg> it looks like even tg pro outputs bogus values for the m2's efficiency cores. thanks to the missing taskset on macos nobody has ever noticed

20:12 <janneg> but taskpolicy -b (forcing everything on the e-core) is enough to show it

20:14 <janneg> so it just displays a non-hotspot p-core temp sensor as e-core temperature

20:19 <janneg> I think I tried all likely T... keys for e-core temp sensors but none spiked significantly under load

20:20 <janneg> hard to believe that there are 6 temp sensors for each p-core but none for e-core

21:04 <janneg> I don't think so: "L Palm Rest Temp: +63.8°C"

21:05 <j`ey> that seems a little hot to the touch

21:06 <janneg> "R Palm Rest Temp: +26.4°C" and I notice no difference

21:06 <janneg> now at +72.6°C

23:07 <chadmed> yeah those two are definitely wrong

23:55 <janneg> chadmed: https://github.com/jannau/linux/tree/macsmc-hwmon has some minor cleanup and shows what I meant with using .dtsi includes for the sensor keys

23:56 <janneg> I don't think we can use keys found elsewhere without sanity checks

23:59 <chadmed> https://github.com/jannau/linux/commit/e437da3c0e707fdfdec05f396fbd56c3551a27f8 ohhhh thats how you do that :)