ChanServ changed the topic of #ubuntu-asahi to: Ubuntu-Asahi development | Github: https://github.com/UbuntuAsahi | Logs: https://oftc.irclog.whitequark.org/ubuntu-asahi
tobhe_ has joined #ubuntu-asahi
tobhe has quit [Ping timeout: 480 seconds]
<john-cabaj[m]> Sorry, just seeing this. Turned mobile notifications to mentions only for the time being. Saw the email - will have to have a look once logs are attached.
funderscore is now known as f_
<tobhe[m]> I'm deleting it from the ppa until we figured out what's wrong. Multiple reports now
<nukelet> huh, curiously only seems to affect m2 devices?
<nukelet> im on the road right now but ill investigate as soon as i get home
<tobhe[m]> not even that, because I have an m2 air and that is not affected
<tobhe[m]> so possibly m2 pro only
<nukelet> that new BSOD thing is... less than helpful in this scenario
<tobhe[m]> indeed
<tobhe[m]> I wonder if it can be disabled with a command line arg
<nukelet> probably, although on second thought, in this scenario i think we would just get a screen freeze
<nukelet> thankfully we can grab the logs using m1n1 at least
<tobhe[m]> I wonder if it could be related to https://github.com/AsahiLinux/linux/issues/310
<tobhe[m]> > disable all aop device nodes (fixes boot on (some) desktop macs)
<nukelet> we rebased on top of asahi-6.12.8-2
<nukelet> honestly my bet is on the other issue you sent: https://github.com/AsahiLinux/linux/issues/310
<tobhe[m]> Is that outdated?
<nukelet> huh, im not sure actually
<nukelet> no yeah it is outdated
<tobhe[m]> ok
<tobhe[m]> the changelog at https://launchpad.net/~ubuntu-asahi/+archive/ubuntu/build2/+packages also lists fixup! arm64: dts: apple: Add AOP and subdevices
<nukelet> actually its worse because the tag in the ubuntu-asahi git repo shouldnt exist at all but thats a problem for later
<tobhe[m]> yeah
<tobhe[m]> I'll ask them to test module_blacklist=sdhci_pci
<nukelet> yeah please do
<nukelet> we can probably add a udev rule to blacklist this automatically if it is indeed the root cause
<nukelet> very weird that we weren't bitten by this before, fedora has been getting reports for a long time (and blacklisted the module in udev 6 months ago)
<tobhe[m]> I think there is a udev fix i planned to backport at some point
<tobhe[m]> so my fault if it is actually that one 🙂 let's hope it is
<tobhe[m]> so it panics in dart
<tobhe[m]> looks like it isn't as easy unfortunately
<john-cabaj[m]> <nukelet> "actually its worse because the..." <- Which tag?
<tobhe[m]> the second seems to be what's actually in the ppa
<john-cabaj[m]> Hmm
<john-cabaj[m]> Maybe I grabbed the wrong Ubuntu-asahi-arm-6.12.0-1002.2 tag, somehow..
<tobhe[m]> the one in the ppa seems to be the correct one though
<john-cabaj[m]> A bit confused. They mentioned 6.10.0-1001 working, but we'd had 6.12.0-1001 released quite some time
<tobhe[m]> that is weird yes
<tobhe[m]> maybe they didn't update for a while
<john-cabaj[m]> I'd be curious if that state was also broken
<john-cabaj[m]> That [GitHub issue](https://github.com/AsahiLinux/linux/issues/310) is referenced in a commit that we already carry, and is otherwise "worked around". But I'm not sure what that implies. Maybe the udev rule that nukelet mentioned.
<tobhe[m]> from all we know right now it looks like something in dart
<tobhe[m]> yes, but we don't ship that yet. It probably isn't that one though
<tobhe[m]> latest screenshot shows a panic in dart
<tobhe[m]> in platform_probe, so very early
<tobhe[m]> which does make it sound like a dtb issue
<john-cabaj[m]> I'll try spinning a new updated kernel locally just to have somethign
<john-cabaj[m]> s/somethign/something/
<tobhe[m]> do we have anyone with a m2 pro here?
<john-cabaj[m]> nukelet ?
<nukelet> nope, mine is an m1 sadly
<john-cabaj[m]> Ok, trying a local build in the meantime. Best I can do for now since I have some errands (carpet cleaning, grocery shopping)
<tobhe[m]> would have been surprising because otherwise we would have found it during testing
<tobhe[m]> I will check the dtb and driver for things that changed
<nukelet> im at home now, looking into this
<john-cabaj[m]> Perhaps we caught a bad interim tag
<tobhe[m]> maybe, but I haven't found an obvious cause yet
<tobhe[m]> new report on a mac mini m2
<john-cabaj[m]> On an upgrade, too
<tobhe[m]> fix t602x SEP MMIO addresses ?
<nukelet> yup
<tobhe[m]> We could build a m1n1 binary with updated dtbs and have them test that
<nukelet> sure, but from #asahi-dev: "I've tagged asahi-6.12.9-1 not much interesting compared to 6.12.8-2. fix for SError on boot for t602x and a small dcp audio fix for some devices (still not enabled)"
<nukelet> i think the m1n1 update is still worth it though
<tobhe[m]> oh
<nukelet> it's just incredibly unfortunate that we caught that bad tag
<tobhe[m]> yeah that sounds related
<tobhe[m]> still don't understand why it didn't affect my m2
<john-cabaj[m]> I'll hopefully have some deb packages to try soon. I'll dump them on my Google Drive with a public link that they could try
<nukelet> yours is an m2 air, no? the t602x is the m2 pro chipset i think
<tobhe[m]> that makes sense
<tobhe[m]> yeah
<nukelet> john-cabaj[m]: are those debs for a newer asahi tag?
<nukelet> if not i can prepare one real quick
<john-cabaj[m]> asahi-6.12.10-2
<tobhe[m]> I guess we can go straight to 10.2
<tobhe[m]> s/./=/
<tobhe[m]> s/./-/
<nukelet> ok awesome
<nukelet> im surprised they applied with no issues on top of plucky lol
<john-cabaj[m]> We had those two upstream correction patches and things have been smooth for a minute
<nukelet> yeah, i think so
<tobhe[m]> I'll try to build a m1n1 stage2 for people to test
<tobhe[m]> because currently they can't even update to a new deb without manual intervention I think
<john-cabaj[m]> Let's all give it a shot once these local debs come through. If all is good, I'll push to a build PPA, one more test, then binary copy to release later today
<tobhe[m]> oh ok, I can wait for those
<tobhe[m]> we will still need to either write a script or provide instructions to copy them into the ESP from macos
<john-cabaj[m]> Kernel debs?
<tobhe[m]> m1n1
<john-cabaj[m]> Ah
<tobhe[m]> + device trees
<tobhe[m]> * with updated device trees
<tobhe[m]> because people can't install updated debs when they can't boot
<tobhe[m]> sophisticated fixing script
<tobhe[m]> only need fixed dtbs now
<john-cabaj[m]> Local kernel posted in private
<john-cabaj[m]> Fedora is also on this tag, so that's helpful
<nukelet> seems to be working fine so far
<nukelet> the local kernel, i mean
<john-cabaj[m]> If things go south, we can build elsewhere
<tobhe[m]> user@m2:~$ uname -a
<tobhe[m]> Linux m2 6.12.0-1003-asahi-arm #3 SMP PREEMPT_DYNAMIC Mon Jan 20 15:44:16 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
<john-cabaj[m]> Lucky day. Launchpad is building it already.
<tobhe[m]> shared my script and asked for test feedback
<nukelet> fingers crossed
<nukelet> wait, john-cabaj[m], did you pull the fixes for that plucky build error that only happened on launchpad?
<tobhe[m]> works 🙂
<nukelet> nice, awesome
<john-cabaj[m]> <nukelet> "wait, john-cabaj, did you pull..." <- Good point, probably not.
<john-cabaj[m]> Will build a 1004 in parallel in build#2
<john-cabaj[m]> Building
<tobhe[m]> updated my script
<tobhe[m]> happy to hear some test feedback on: https://files.tobhe.de/ubuntu/fix-m1n1
<tobhe[m]> if it doesn't break your machine I am happy
<nukelet> oof, the -1004 build failed in build#2 because of yet another toolchain upgrade
<nukelet> tobhe[m]: will it be useful to test it on an m1 machine?
<john-cabaj[m]> Yep yep
<john-cabaj[m]> Reverting
<john-cabaj[m]> Rust in Ubuntu, the ultimate moving target
<nukelet> pre-freeze plucky adventures
<john-cabaj[m]> Buildling back in regular build PPA
<john-cabaj[m]> Failed again. I’ll need to look at this later today - no time right now.
<john-cabaj[m]> Ok. Hopefully this build in my PPA gets across the line.
<john-cabaj[m]> My chroot had versions of Rust that worked a few weeks ago, so it wanted to keep using those.