home
> blog
| [overview] | [down] / [next] |
Sun Sep 22 17:42:43 2024 GMT: Debugging an early NetBSD kernel panic
Tried to install NetBSD in an AMD64 VM with little success. Although the NetBSD loader worked fine, as soon as it transferred control to the NetBSD kernel, the VM immediately rebooted with no diagnostics appearing on the console that would give a hint of what could be wrong. One of the things I tried was adding a DELAY into the panic function in the kernel - at least the DELAY seemed to have an effect, so the kernel must have paniced, but still no sign of any diagnostics. So either the kernel was using a different console, or the panic was too early and the console wasn't initialised yet.
Looking at the vpanic function, I noticed that it uses a scratchstr to store the panic message, so maybe there is a way to read that string after the reboot? But how do you get access to a physical memory address and which address do you need to look at? Turns out that grub2 has a "dump" command to do exactly that, so just need to figure out the memory address. Ok, scratchstr is a function local static, so doesn't appear in any global symbol table, but there is panicstr which points to that string. And using "nm" on the NetBSD kernel reveals some address "ffffffff8197dfc0". That looks a bit strange as an address, but it seems like the NetBSD loader is using the lower 28 bits as the physical memory address when loading the binary (at least that's what grub does). So all you have to do now is do a "dump 0x197dfc0 8" to get the contents of that pointer and then another dump (again, only using the lower 28 bits) to get the contents of the string - which you then have to decode by converting hex to ASCII.
dump 0x197dfc0 8 e0 df 97 81 ff ff ff ff dump 0x197dfe0 128 6b 65 72 6e 65 6c 20 64 69 61 67 6e 6f 73 74 69 63 20 61 73 73 65 72 74 69 6f 6e 20 22 6c 70 5f 6d 61 78 20 3e 3d 20 63 6f 72 65 5f 6d 61 78 22 20 66 61 69 6c 65 64 3a 20 66 69 6c 65 20 22 2e 2e 2f 2e 2e 2f 2e 2e 2f 2e 2e 2f 61 72 63 68 2f 78 38 36 2f 78 38 36 2f 63 70 75 5f 74 6f 70 6f 6c 6f 67 79 2e 63 22 2c 20 6c 69 6e 65 20 31 36 33 20 0a 00 00 00 00 00 00 00 00 00 00 00 00 00
There you go, and in this case it was: kernel diagnostic assertion "lp_max >= core_max" failed: file "../../../../arch/x86/x86/cpu_topology.c", line 163
Sun Apr 25 15:55:42 2021 GMT: vidmini - limit webcam resolution
Being fed up with the limited configurability of some of the more widely used software used for video conferencig, I have put together a small LD_PRELOAD-able shared library that limits the available resolutions a webcam reports. Have a look at the README or the source code.
Sun Apr 26 18:45:55 2020 GMT: Tizen on Orange Pi PC
Made some significant progress for running Tizen on an Orange Pi PC (and hopefully any other SBC with a similar Mali GPU). Main issue was that alignments in TBM (Tizen Buffer Manager) weren't in sync with what the actual GPU driver expected. With that fixed, rendering seems to work fine now and I was also able to enable Full HD (1920x1080) resolution.
Next step would be to get the Home Screen app auto started and find some way to get a "Home" button (to be able to switch between apps without completely closing them).
Mon Apr 20 19:02:27 2020 GMT: SIGCHLD si_pid Linux kernel bug
While trying to get Tizen working on my Orange Pi PC, I noticed some strange behaviour in the Linux kernel in that SIGCHLD signals sent to the parent process don't always set the "si_pid" field correctly. I tracked this down to a bug in the Linux kernel for multithreaded process termination, see SIGCHLD signal sometimes sent with si_pid==0 (Linux 5.6.5). Luckily, a patch has already been posted less than 24 hours later.
Sat Feb 29 23:41:48 2020 GMT: Rock Pi S Review
Got a $20 voucher code for a review of a Rock Pi S SBC. Although the cost of the board is only $13.90, with shipping at just over $8, it's a bit over $22 in total. When the board arrived, I did actually wonder if shipping could have been made a bit more economical by not putting the tiny board into a huge box (175 mm x 115 mm x 95 mm) which had a plastic case (70 mm x 50 mm x 25 mm) with the board in it.
Anyway, two things to note about the board are that the serial console uses 1.5 Mbps (which is different to the more common 115200 bps used by other boards), and uses a USB Type C connector for power (like the Raspberry Pi 4, but unlike older SBCs).
Downloading the Ubuntu image and writing it to a SanDisk Ultra 16 GB MicroSD card seemed to work fine to get it to boot. One thing I did notice was that the SSH server keys seemed to have been written to the image and not regenerated on first boot. The other thing to be aware of is that the kernel being used is fairly old (4.4.143) with mainline kernel support only starting to appear now.
One thing that appears strange to me is that total memory is only shown as "MemTotal: 432280 kB" - I am not entirely sure what this isn't (much) closer to 512 MB.
Finally, power consumption seems to be quite good. With WiFi turned on, but otherwise completely idle, my USB tester shows the device using only around 0.2 W. Doing a "ping" and it will go up to around 0.36 W. Reading from the MicroSD card also uses around 0.4 W. Keeping all 4 cores of the CPU busy and power consumption goes up to around 0.85 W.
Thu Oct 10 17:48:58 2019 GMT: kmscube Running on Orange Pi PC with Mainline Kernel
Fri Apr 19 19:51:15 2019 GMT: Outdoor Maps in Galaxy Store
Sun Dec 23 10:59:23 2018 GMT: Adding CircleCI builds
Sat Jul 21 09:57:47 2018 GMT: Roundup running on Python 3
Thu Jul 19 06:43:19 2018 GMT: Roundup Updated for wg21.cmeerw.net
Wed May 02 14:00:35 2018 GMT: Perforce Acquires PRQA
Wed Mar 14 17:29:41 2018 GMT: ACME DNS Validation
