07:30 <Ke> someone had an issue on rk3399 chromebook, but as I understood they did not get anything on serial

07:33 <samueldr> possibly a different issue

07:34 <samueldr> since AFAICT gru-dumo (scarlet) on 5.9-rc2 doesn't boot at all, no serial output

07:35 <samueldr> mps: was it working fine with 5.8? I had issues with 5.8 on gru-dumo (scarlet) that stop at udevadm settle, which fails after ~2 minutes

07:35 <samueldr> battery driver related, not fixed on 5.9

07:35 <samueldr> the -rc2 issue I have is caused by this change https://lore.kernel.org/patchwork/patch/1290606/

07:35 <samueldr> which I don't really see why it would make it fail

07:36 <samueldr> (I'll be gone for a couple of hours pretty soon)

07:38 <mps> samueldr: 5.8.1 and 5.8.3 works fine

07:39 <samueldr> could be something else then, though I remember seeing that there were further changes related to the issue I had with the battery driver, after 5.8, which is what I was going to actually test before seeing the non-booting issue

07:39 <mps> but this morning I noticed that udev-settle is updated for alpime (distro which I use) and I didn't upgraded it yet

07:40 <mps> I'm preparing new mmc to upgrade distro and test again, don't want to make current working unbootable

07:41 <samueldr> so I guess that this non-booting issue with -rc2 is dumo (or scarlet) specific; will still try a pinebook pro build just in case

07:42 <mps> I have also mediatek elm-oak chromebook and booting 5.9-rc2 works fine but using eballetbo fork of kernel

07:45 <samueldr> right, specific things for the platform I gather https://github.com/eballetbo/linux/commits/topic/chromeos/somewhat-stable-next

07:45 <mps> yes, this one I use for elm-oak

08:37 <mps> also, I reported here and on mmc kernel ML problem with emmc crash after suspend2ram and resume on gru-kevin

08:38 <mps> does anyone run gru-kevin from internal emmc and have problems

17:17 <samueldr> on mainline, gru-dumo (scarlet)'s eMMC is extremely fiddly

17:18 <samueldr> I have to revert the hs400 setting, or else it seems to never at all pick up https://github.com/NixOS/mobile-nixos/blob/master/devices/asus-dumo/kernel/0001-gru-Force-hs200-for-eMMC.patch#L29

17:19 <samueldr> and then unbind and bind the mmc_host driver until it shows up

17:20 <samueldr> since chromeos-4.4 doesn't really work on gru-dumo (scarlet) I can't confirm whether it works better there, but I would hope so considering it's what chromeos runs on

17:20 <samueldr> ... but then again I have mipi panel suspend/resume issues on chromeos-4.4

17:20 <samueldr> (which could be explained by chromeos never actually doing that)

17:52 <mps> on gru-kevin emmc works really fine till resuming, and it doesn't 'crash' just after resume but some time (5-30 minutes), and even that not happens always

17:52 <mps> sometimes it survives few suspend/resume cycles

17:53 <mps> once it worked full week without problem, so I think it depends on stars on sky

17:54 <mps> hmm, some time after resume*

19:58 <samueldr> so, what's the usual protocol with "this patch broke this" and Linux? https://lore.kernel.org/patchwork/patch/1290606/

19:58 <samueldr> last time I tried reporting a bug (on the bugzilla) I was told the bugzilla isn't used by some subsystems

19:58 <samueldr> so this deflated me quite a bunch

20:13 <urjaman> mail the patch authors and an appropriate list, methinks

20:45 <inode> that sounds right according to https://www.kernel.org/doc/html/v5.8/admin-guide/reporting-bugs.html

21:03 <samueldr> yeah, that's what I was going on with, used scripts/get_maintainer.pl to get a list of additional people to CC

21:03 <samueldr> at the very least it's sent https://lkml.org/lkml/2020/8/29/363

21:06 <mps> heh, I will follow this report

21:07 <samueldr> mps: unlikely to be your issue if your gru boots :)

21:07 <samueldr> you're the "reportedly" one gru-kevin that works

21:08 <samueldr> I mean that getting into any kind of userspace, even if it broken, boots further than nothing at all

21:10 <mps> right, but I also wanted to write mail to lkml because maintainer didn't fixed bug which I reported 2-3 months ago

21:12 <mps> I think maintainers are same for my problem, would be interesting to look how will they fix your report

21:31 <samueldr> mps: what's your issue?

21:32 <samueldr> I can take a look-see for fun

21:41 <mps> I wrote above, '19:51 ......... mps| on gru-kevin emmc works really fine till resuming, and it doesn't 'crash' just after resume but some time (5-30 minutes), and even that not happens always'

21:44 <samueldr> I implied to see the thread, but yeah, that's certainly not something I can look I guess

21:45 <samueldr> gru-scarlet doesn't seem to suspend right (or that's a configuration issue)... though that's to be solved once the actual bigger issue of the display not being able to resume/suspend is looked into

21:49 <mps> yes, I have another one bug reported about display freeze (and blanks) besides emmc problem

21:49 <mps> some other minor bugs are not important for me