I've spent more than two months(!) trying to find out what causes Linux Kernel OOPs that seem to be triggered by big writes to mounted ext4 filesystems. My quest began while trying to boot from SPI and run Armbian with rootfs on eMMC. I tried two different eMMC modules and all the Rockpro64 Linux images that I could find. I burnt a lot of midnight oil trawling the Internet for solutions, but found none...
Most of the Linuix images that I've tried work fine booting from SPI using the latest u-boot running Linux (Armbian, Debian, Ayufan) with rootfs on SD, but crash badly when either installing them to eMMC from SD or running them from eMMC and e.g. installing a big package like OMV.
Watching "htop" during installation of a 'large' package, I can see that the OOPs seem to occur when the filesystem buffers hit a high-water mark and this could be mitigated by mounting ext4 filesystems in 'sync' mode. I've done a lot of testing and now I have a stable OMV6 running under an Armbian image I compiled myself from source, and ext4 filesystems mounted in 'sync' mode: I only have occasional OOPs during heavy i/o to an ext4 filesystem mounted on an "md" raid consisting of two 1TB SATA disks connected to a 2-port Adaptec PCI-e controller.
Using 'sync' mode degrades performance, and could wear out SSD's, so it's only useful as a temporary work-around. The real problem is how to prevent the ext4 FS buffers from overflowing available memory. I suspect, but have no proof, that this is caused by the Linux 'optimistic' memory allocator oversubscribing memory and getting caught-out by the actual usage overflowing available physically memory.
I don't have a deep enough knowledge of the Linux kernel to investigate the problem, but maybe someone else reading this message does, but what I do know, is that the problem is NOT a device driver issue, because direct device access (e.g. using "dd") does not trigger an OOPs. This is not a hardware fault on my particular Rockpro64 board or eMMC module because FreeBSD installs and runs fine on SD or eMMC on the same system.
I'd be interested to read other people's experiences of using the Rockpro64 with OMV6 under Armbian.
When I connected my Pinecil to my laptop (windows 10) I get a usb device error message saying the device has malfunctioned tried theis with 3 different laptops with the supplied usb c to usb c cable and 2 std usb a to usb c cables. All the cable function ok when I connect my external USB c NVMe drive enclousure.
Hi
I have just installed a 128Gb eMMC in my PBP, and now I would like to install both Manjaro and Debian (with 32 bit userspace) onto the same eMMC with a boot menu.
I think that I already know how to write a boot menu in uboot.
What I don't understand is how kernels will work.
More specifically both Debian and Manjaro use an "Image" file for the kernel.
I presume that the "Image" file is under package management control, and so I can't have two "Image" files in the same boot partition which are controlled by two different package managers.
Also, I do know from messing with other ARM64 systems that it is possible to have a Debian userland with no kernel package installed at all, so not in control of the Debian package manager.
Could I use the Manjaro kernel, under control of the Manjaro package manager to also boot Debian 32 bit userland?
If so then that would be a good solution.
Thanks.
From my experience when the PinePhone keyboard case is turned on, it will provide power to the phone but the phone's USB-C port will be disabled until the keyboard is powered off (I don't know if that's what happens to everyone else but it happens to mine LOL).
My question is: If I plug the USB-C dock into the PinePhone's USB-C port and I provide power to the USB-C dock with its USB-C port, do I have to worry about accidentally turning on the keyboard and blowing up the phone?
I know using both the PinePhone's USB-C port and the keyboard case to provide power is a huge no-no. I said that the PinePhone's USB-C port is disabled when the keyboard is powered on but maybe it's only data that's disabled and not power, so if I I'm powering the USB-C dock, and I turn the keyboard on by mistake it might not be good. Obviously I've never tested it.
Quote:Can I plug something to the phone's Type-C port? No! When the keyboard is connected to the phone, it powers the phone by internally supplying 5V to the VBUS of the phone's Type-C port. So if you connect another USB power supply to the phone's Type-C port, it's like connecting two chargers to the phone by cutting and splicing their cables. (Likely not a good thing, or something you'd consider doing if it was presented to you that way.) If you connect some USB peripheral there that only consumes power from the port (like mouse, unpowered dock, etc.), it may work (in theory), but only if you make *absolutely sure* the phone will not enable its power output to the USB device! No distros ensure that at the moment. When you plug USB periperal it's the same as plugging in two chargers into the same port, without additional software support that doesn't exist, yet.
I am very confused how I'm supposed to use the keyboard case in unison with the USB-C dock in general.
So I have not been able to use the microphone for calls on any distro of Linux on my dev edition PPP, so I installed the android test image to try to see if it work there. It did not work in the android test image either. Is this normal?
I ask because I have read various people saying calls worked for them on reddit or on this forum. Mic is not working at all for me, just trying to figure out if I need to replace my PPP or if this is just the current state of the device.
From the sxmo dialer, calling 111 (Japan's test dial) does nothing for a while, then I get "missed call 111" and a "QMI Protocol Error: IncompatibleState".
From the `dev/ttyUSB2` terminal, `ATD111` just says "NO SERVICE".
phone: Pinephone OG 2gb.
image: PMOS SXMO installer one on SD card.
carrier: Y!mobile (Softbank under the hood)
ModemManager log: https://pastebin.com/vKgk2YCr
(pastebin set to 2 week exipiry. I stripped the timestamps and excessive `<<<<<<` to make it fit into 512kb but I just realized this forum takes 32MB attatchments. wow.)
(I really hope I'm not exposing my phone number in a non-human-readable way. I removed the ones that I found.)
Seems like the paste was removed by pastebin. And the forum attach does not take 470ish kb txt files.
Is there a section of the log that would be useful to share?
Skimming through it, I see there are three "verbose call end reasons":
Code:
<info> [modem0/bearer1] verbose call end reason (2,210): [internal] pdn-ipv6-call-disallowed
<info> [modem0/bearer1] verbose call end reason (3,1028): [cm] emm-detached
<info> [modem0/bearer1] verbose call end reason (3,2001): [cm] no-service
the no-service one happens 3-4 times for each bearer 1,2,3.
