09:19 < _jannau_> Glanzmann: git rebase --onto 5.17-rc3 6f59bc24287
09:23 < j`ey> if you add -p it can also preserve the merges
-01:31 < jmr2> Has anyone tried LVM so far? Not sure if I'm doing something dumb or if it's really unhappy with 16K pages. http://paste.debian.net/plainh/016c394b
-jmr2@debian:/tmp$ dd if=/dev/zero of=loopfile bs=32M count=1
-1+0 records in
-1+0 records out
-33554432 bytes (34 MB, 32 MiB) copied, 0.0328437 s, 1.0 GB/s
-jmr2@debian:/tmp$ sudo losetup /dev/loop0 loopfile
-jmr2@debian:/tmp$ sudo pvcreate /dev/loop0
- Using metadata size 960 KiB for non-standard page size 16384.
- Using metadata size 960 KiB for non-standard page size 16384.
- Physical volume "/dev/loop0" successfully created.
-jmr2@debian:/tmp$ sudo pvremove /dev/loop0
- Using metadata size 960 KiB for non-standard page size 16384.
- Labels on physical volume "/dev/loop0" successfully wiped.
-jmr2@debian:/tmp$ sudo pvcreate /dev/loop0
- Using metadata size 960 KiB for non-standard page size 16384.
- Using metadata size 960 KiB for non-standard page size 16384.
- Physical volume "/dev/loop0" successfully created.
-jmr2@debian:/tmp$ sudo pvs
-jmr2@debian:/tmp$ sudo pvdisplay
-jmr2@debian:/tmp$ sudo pvck -t /dev/loop0
- TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
- CHECK: pv_header.disk_locn[2].offset expected 4096 # for first mda
- Found label on /dev/loop0, sector 1, type=LVM2 001
- Found text metadata area: offset=16384, size=1032192
- Command failed with status code 5.
-jmr2@debian:/tmp$
+19:13 < j`ey> but there's also CONFIG_OF_DMA_DEFAULT_COHERENT, which makes of_dma_is_coherent always return true
+21:02 < jannau> mps: you need https://lore.kernel.org/u-boot/20220208210215.8612-1-j@jannau.net/ for extlinux
+
+ARCH: 23:29 < ah-[m]> yep, exactly. I had to grub-mkconfig -o /boot/grub/grub.cfg, and move my Image.gz to /boot, otherwise it was just what was on the wiki page
+
+https://lore.kernel.org/linux-arm-kernel/20211011165707.138157-1-marcan@marcan.st/
+19:02 < jannau> I think based on this branch https://github.com/AsahiLinux/linux/tree/cpufreq/v1
+
+23:41 < kov> Glanzmann, hmm interesting, I'll try upgrading libinput firs then, see if that fixes it
+23:42 < kov> it's weird because I remember the trackpad working a while ago
+23:45 -!- mtjzh (~mtjzh@2a02:8388:1742:9b80:658f:93d3:ec68:d60e) has joined #asahi
+23:46 < kov> yep, just upgrading to testing's libinput makes it work heh thanks Glanzmann!
+
+Chromium 16KB patch: https://tg.st/u/Set-kernal-page-size-to-16K-on-loongson-MIPS-archtec.patch
+10:10 < jannau> see the commit message for 64k on ppc64 https://chromium.googlesource.com/chromium/src.git/+/445c099c6486b8e5ff8dafaefcd812a7ea4bdfff%5E%21/
+15:26 < tpw_rules> Glanzmann: https://pastebin.com/NzJEQJDW - https://tg.st/u/NzJEQJDW
+15:26 < tpw_rules> last i checked the built chromium only worked with the flags --in-process-gpu --no-sandbox --no-zygote but that may have been a kernel config problem
+Upstream BUG: https://bugs.webkit.org/show_bug.cgi?id=236564
+
+22:39 < jannau> `dtc -I fs -O dts -o - /proc/device-tree` will output the device-tree as seen by linux
+
+19:11 < Glanzmann> axboe: Could you explain how to mark a device as write-through? Does that mean if I issue a sync in Linux that no flush will happen. Because this would be helpful for the m1 notebook owners to improve performance.
+19:11 < axboe> I just do: `echo "write through" > /sys/block/nvme0n1/queue/write_cache"` for now...
+19:11 < axboe> Glanzmann: ^^
+19:12 < axboe> Glanzmann: and yes, that's what it means
+19:12 < Glanzmann> axboe: Thanks.
+19:12 < axboe> Glanzmann: it'll bump your test case from 56 iops to 14k or something like that :)
+19:12 < axboe> alternatively, some sort of time based hack might make sense
+19:13 < axboe> "only issue flush if X seconds has passed since last issue"
+19:13 < axboe> kinda nasty, but safer
projects / m1-debian / blobdiff