The kernel panics in 5.5 seem to be related to zram. I had swap set up on zram since day one, still on kernel 5.4, but I wasn't getting any kernel panics back then, only Xorg crashes and difficulties waking up from sleep. Now even if I completely disable compositing I still get kernel panics, and the likelihood of me getting one seem to be increasing with the memory usage. Replacing zram swap with traditional on-disk swap allows me to avoid kernel panics no matter the memory use, but it is much slower than zram and I don't want to wear out eMMC. And I still haven't had time to figure out debugging over UART...
03-09-2020, 05:37 PM
(This post was last modified: 03-09-2020, 05:59 PM by Der Geist der Maschine.
Edit Reason: mtdoops
)
(03-09-2020, 05:25 PM)moonwalkers Wrote: I still haven't had time to figure out debugging over UART...
Perhaps set up kdump?
It did not work on the default Debian. I suspect kdump got confused of 64bit kernel and 32bit userspace.
Smallprint: our maybe setup mtdoops. Finally a use for the flash.
(03-09-2020, 05:37 PM)Der Geist der Maschine Wrote: (03-09-2020, 05:25 PM)moonwalkers Wrote: I still haven't had time to figure out debugging over UART...
Perhaps set up kdump?
It did not work on the default Debian. I suspect kdump got confused of 64bit kernel and 32bit userspace.
Smallprint: our maybe setup mtdoops. Finally a use for the flash.
Thanks for the suggestion, hopefully it will be helpful to other people in the thread. Or to me after I get some basic knowledge - while I'm pretty well versed in C/C++, I've never done any kernel or embedded development, so currently those words sound like some black magic incantations to me :-D
(03-10-2020, 12:37 AM)moonwalkers Wrote: (03-09-2020, 05:37 PM)Der Geist der Maschine Wrote: (03-09-2020, 05:25 PM)moonwalkers Wrote: I still haven't had time to figure out debugging over UART...
Perhaps set up kdump?
It did not work on the default Debian. I suspect kdump got confused of 64bit kernel and 32bit userspace.
Smallprint: our maybe setup mtdoops. Finally a use for the flash.
Thanks for the suggestion, hopefully it will be helpful to other people in the thread. Or to me after I get some basic knowledge - while I'm pretty well versed in C/C++, I've never done any kernel or embedded development, so currently those words sound like some black magic incantations to me :-D
What do you want to achieve with your console cable?
You know process cores and how to debug them post mortem. kdump saves the kernel core of a crashing kernel. You can also debug it post-mortem on your next boot.
I use it all the time (not on the Pinbook Pro, though). Google for it 
(03-10-2020, 02:20 PM)Der Geist der Maschine Wrote: (03-10-2020, 12:37 AM)moonwalkers Wrote: (03-09-2020, 05:37 PM)Der Geist der Maschine Wrote: (03-09-2020, 05:25 PM)moonwalkers Wrote: I still haven't had time to figure out debugging over UART...
Perhaps set up kdump?
It did not work on the default Debian. I suspect kdump got confused of 64bit kernel and 32bit userspace.
Smallprint: our maybe setup mtdoops. Finally a use for the flash.
Thanks for the suggestion, hopefully it will be helpful to other people in the thread. Or to me after I get some basic knowledge - while I'm pretty well versed in C/C++, I've never done any kernel or embedded development, so currently those words sound like some black magic incantations to me :-D
What do you want to achieve with your console cable?
You know process cores and how to debug them post mortem. kdump saves the kernel core of a crashing kernel. You can also debug it post-mortem on your next boot.
I use it all the time (not on the Pinbook Pro, though). Google for it
I will, when I manage to free up some time. Which will probably happen only closer to April :'-(
I've had a new failure in the last day, where the pinebook pro screen goes black and usual things like waiting 30 seconds for the driver to restart, touching the trackpad, keyboard, or pressing the power key all fail to restore interactivity. It's been particularly waking up from "sleep", i.e. opening the lid, but I've also had it happen when launching an application. Has anyone else seen this?
I'm using Debian bullseye, updated every few days, danielt's 5.5.0-5231-g400fa90907d2-1 packaged kernel, and mesa 20.0.x built out of git.
I think this is new since the new kernel package earlier this week, but I'm confused about the versioning. When I went to verify my memory, I found there different dates. The file modification date in /boot and /usr/share/doc/linux-image-5.5.0-1-pinebookpro-arm64/changelog.Debian.gz both say February 13. `uname -a` says March 18, and the package repository says it was last modified March 19, more recently than I'd updated the last time it happened.
I think that Bullseye is less mature than some debootstrap packages I've used. The files it relies on, not the package itself. Having it install Buster may work better than Bullseye.
i'm on the opposite end of the spectrum with debian sid/scud arm64, several packages from git, and rolling my own kernel with kernel.org and hwaccel patches onto tsys' v.5.6 kernel branch. things have been working very well, especially recently with tsys' work on the pbp dts and battery kernel components.
Are you saying I've fallen in the unsupported middle?
Anyway, I was posting more to report the issue in case it was relevant to danielt's kernel package.
03-22-2020, 10:42 AM
(This post was last modified: 03-22-2020, 10:44 AM by xmixahlx.)
i find that is exactly the case with debian. due to unstable>testing migration processes you can often be caught in a broken situation.
i have used sid for 19 years without any serious stability issues personally. professionally always use stable for obvious reasons.
similarly, use sid if you know what you are doing and stable if you do not...
this issue is also solved occasionally with packages from experimental. it is hard to leverage without already being on unstable. see recent mesa as an example.
|
