Debian on Dell Kace M300
Posted by JDS420
|
Re: Debian on Dell Kace M300 March 21, 2022 02:57PM |
Admin Registered: 14 years ago Posts: 19,288 |
Rebasing to 2022.04 version solved this CRC error. I'll upload new u-boot version and modify the installation instruction.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
2022.04 U-Boot Kirkwood - Dell Kace M300 March 22, 2022 05:57PM |
Admin Registered: 14 years ago Posts: 19,288 |
Attched is the new u-boot. This uboot image and its default env image can be flashed to SPI mtds.
uboot.2022.04-tld-1.m300.bodhi.tar
sha256sum
0aaa790377c6433396867dd26798f52e43541f2977d46537e0ce1a0df04b2cc8
md5sum
7986ddeac251018219e3d65851abbbb4
There are 3 files in this tarball.
1. Unprotect the SPI flash
Note that this is needed to be done only once from stock u-boot.
Boot with serial console, interrupt u-boot count down and unprotect the SPI flash.
And then go ahead boot into Debian
2. Flash new u-boot
Log into Debian, download the attached u-boot image tarball. Extract the files. And flash both images.
3. Prepare the rootfs to boot with new u-boot.
Skip this step if you have booted with the separate DTB before (with previous u-boot version for M300).
As we have been booting with stock u-boot, the DTB is appended to uImage. So it should be restored to the original uImage before we will boot with separate DTB.
Or just recreate uImage
4. Adjust u-boot envs
After flashing the default envs image in Step 2, the following envs must be set. Replace the ethaddr, ipaddr, and serverip values to the appropriate ones for your box.
Save the current envs.
5. And then reboot (or go to the next optional step to create a uEnv.txt).
6. (Optional) Prepare the uEnv.xt.
The envs listed below are typically useful, but not necessary. Nice to have so it will boot faster if your rootfs is on SATA drive, and you don't use RAID.
cat /boot/uEnv.txt
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 11/15/2024 11:41PM by bodhi.
uboot.2022.04-tld-1.m300.bodhi.tar
sha256sum
0aaa790377c6433396867dd26798f52e43541f2977d46537e0ce1a0df04b2cc8
md5sum
7986ddeac251018219e3d65851abbbb4
There are 3 files in this tarball.
uboot.2022.04-tld-1.m300.mtd0.kwb uboot.2022.04-tld-1.m300.environment.4K.img uboot.2022.04-tld-1.m300.environment (this is the default envs in text format)
1. Unprotect the SPI flash
Note that this is needed to be done only once from stock u-boot.
Boot with serial console, interrupt u-boot count down and unprotect the SPI flash.
protect off allExpected output
Un-Protect Flash Bank # 1 ................................................................................................................................ done
And then go ahead boot into Debian
boot
2. Flash new u-boot
Log into Debian, download the attached u-boot image tarball. Extract the files. And flash both images.
flash_unlock /dev/mtd0 flashcp -v uboot.2022.04-tld-1.m300.mtd0.kwb /dev/mtd0Expected output
Erasing blocks: 96/96 (100%) Writing data: 384k/384k (100%) Verifying data: 384k/384k (100%)
flash_unlock /dev/mtd1 flashcp -v uboot.2022.04-tld-1.m300.environment.4K.img /dev/mtd1Expected output
Erasing blocks: 1/1 (100%) Writing data: 4k/4k (100%) Verifying data: 4k/4k (100%)
3. Prepare the rootfs to boot with new u-boot.
Skip this step if you have booted with the separate DTB before (with previous u-boot version for M300).
As we have been booting with stock u-boot, the DTB is appended to uImage. So it should be restored to the original uImage before we will boot with separate DTB.
cd /boot cp -a uImage uImage.m300.dtb cp -a uImage.orig uImage
Or just recreate uImage
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.16.5-kirkwood-tld-1 -d vmlinuz-5.16.5-kirkwood-tld-1 uImage
4. Adjust u-boot envs
After flashing the default envs image in Step 2, the following envs must be set. Replace the ethaddr, ipaddr, and serverip values to the appropriate ones for your box.
fw_setenv ethaddr 18:03:73:xx:xx:xx fw_setenv ipaddr 192.168.0.249 fw_setenv serverip 192.168.0.220
Save the current envs.
fw_printenv > /boot/uboot.2022.04-tld-1.env.list.txt
5. And then reboot (or go to the next optional step to create a uEnv.txt).
sync sync sync shutdown -r now
6. (Optional) Prepare the uEnv.xt.
The envs listed below are typically useful, but not necessary. Nice to have so it will boot faster if your rootfs is on SATA drive, and you don't use RAID.
cat /boot/uEnv.txt
custom_params=raid=noautodetect bootdev=sata devices=sata usb
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 11/15/2024 11:41PM by bodhi.
|
Re: Debian on Dell Kace M300 March 22, 2022 11:24PM |
Registered: 9 years ago Posts: 52 |
bodhi Wrote:
-------------------------------------------------------
> Attched is the new u-boot. This uboot image and
> its default env image can be flashed to SPI mtds.
>
> uboot.2022.04-tld-1.m300.bodhi.tar
>
> sha256sum
> 0aaa790377c6433396867dd26798f52e43541f2977d46537e0ce1a0df04b2cc8
> md5sum
> 7986ddeac251018219e3d65851abbbb4
>
> There are 3 files in this tarball.
Yep, this worked fine. updated it blindly without serial console, no problems to report other than needing to re-follow the section in the install post about changing /etc/fw_env.config to mirror what the M300 needs to edit the uboot envs.
==> for reference for anyone else, libubootenv-tool isn't included in the latest rootfs and needs to be acquired from apt. I got in my 240GB SSD yesterday and reloaded it with a fresh copy of the current rootfs so that's something just to note.
on that, I was right, the Sandisk Ultra II (and probably others in that line) are pretty much the same footprint as the original internal SSD. if anyone reading this in the future wants to go that route, see if the SSD you want to use has been de-cased and looks at least similar to the SSD that is in this device stock.
Note all these commands were executed after waiting about 10 minutes after booting to minimize chances of other operations conflicting results.
with hdparm:
with dd:
Throughput
Latency
Overall extremely fast for a kirkwood.
Attached are some pics of the installed SSD in the M300 with the stack of the cut-up thermal pad from inside the casing of such just to give the marvell chipset it uses some semblance of thermal transfer to the board. while the chipset does not get hot under standard use, Sandisk felt it was needed enough to add one, so I'm just following through with their recommendations (and also getting rid of the ball of thermal material that was keeping the stock SSD's controller cool.)
Also take note that while the SSD is the correct size, only one screw can be fitted on the left hand side. the rightmost hole on the SSD is offset and the wrong size to accept that size screw. This can likely be remedied with a fatter head on that size thread screw (or a tiny plastic washer!) but in actuality only one screw being inserted is more than enough to keep it in place.
footnote: while doing all this I did install a fresh CR2032 to keep time... but since ntp takes forever to sync to a time server by itself... it might be a good idea to also include a copy of ntpdate with the next rootfs base. in /etc/rc.local all that would be needed for any of the other non-battery-backed kirkwood devices, somewhere underneath the code for regenerating the ssh keys:
and that takes care of making sure that as soon as the user logs in over ssh or serial, the date and time are correct at every boot... and in this case, removes any time offset immediately upon boot. from there, ntp takes over.
I've been using those three lines on the Pogo v4 for eons and it cuts down a lot of time trying to use the date command to set the time compared to a few seconds more of waiting at boot time.
Cheers.
-------------------------------------------------------
> Attched is the new u-boot. This uboot image and
> its default env image can be flashed to SPI mtds.
>
> uboot.2022.04-tld-1.m300.bodhi.tar
>
> sha256sum
> 0aaa790377c6433396867dd26798f52e43541f2977d46537e0ce1a0df04b2cc8
> md5sum
> 7986ddeac251018219e3d65851abbbb4
>
> There are 3 files in this tarball.
Yep, this worked fine. updated it blindly without serial console, no problems to report other than needing to re-follow the section in the install post about changing /etc/fw_env.config to mirror what the M300 needs to edit the uboot envs.
==> for reference for anyone else, libubootenv-tool isn't included in the latest rootfs and needs to be acquired from apt. I got in my 240GB SSD yesterday and reloaded it with a fresh copy of the current rootfs so that's something just to note.
on that, I was right, the Sandisk Ultra II (and probably others in that line) are pretty much the same footprint as the original internal SSD. if anyone reading this in the future wants to go that route, see if the SSD you want to use has been de-cased and looks at least similar to the SSD that is in this device stock.
Note all these commands were executed after waiting about 10 minutes after booting to minimize chances of other operations conflicting results.
with hdparm:
root@yamada:~# hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 690 MB in 2.00 seconds = 344.42 MB/sec Timing buffered disk reads: 512 MB in 3.00 seconds = 170.40 MB/sec
with dd:
Throughput
root@yamada:~# dd if=/dev/zero of=/tmp/test1.img bs=512M count=1 oflag=dsync 1+0 records in 1+0 records out 536870912 bytes (537 MB, 512 MiB) copied, 4.04497 s, 133 MB/s
Latency
root@yamada:~# dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync 1000+0 records in 1000+0 records out 512000 bytes (512 kB, 500 KiB) copied, 0.0122276 s, 41.9 MB/s
Overall extremely fast for a kirkwood.
Attached are some pics of the installed SSD in the M300 with the stack of the cut-up thermal pad from inside the casing of such just to give the marvell chipset it uses some semblance of thermal transfer to the board. while the chipset does not get hot under standard use, Sandisk felt it was needed enough to add one, so I'm just following through with their recommendations (and also getting rid of the ball of thermal material that was keeping the stock SSD's controller cool.)
Also take note that while the SSD is the correct size, only one screw can be fitted on the left hand side. the rightmost hole on the SSD is offset and the wrong size to accept that size screw. This can likely be remedied with a fatter head on that size thread screw (or a tiny plastic washer!) but in actuality only one screw being inserted is more than enough to keep it in place.
footnote: while doing all this I did install a fresh CR2032 to keep time... but since ntp takes forever to sync to a time server by itself... it might be a good idea to also include a copy of ntpdate with the next rootfs base. in /etc/rc.local all that would be needed for any of the other non-battery-backed kirkwood devices, somewhere underneath the code for regenerating the ssh keys:
service ntp stop ntpdate time.nist.gov service ntp start
and that takes care of making sure that as soon as the user logs in over ssh or serial, the date and time are correct at every boot... and in this case, removes any time offset immediately upon boot. from there, ntp takes over.
I've been using those three lines on the Pogo v4 for eons and it cuts down a lot of time trying to use the date command to set the time compared to a few seconds more of waiting at boot time.
Cheers.
|
Re: Debian on Dell Kace M300 March 23, 2022 01:24AM |
Admin Registered: 14 years ago Posts: 19,288 |
Thanks for the report sudos!
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 March 26, 2022 04:33PM |
Registered: 10 years ago Posts: 226 |
I also blindly flashed the new u-boot since I'm trying to clean things up and put this thing into production with a USB boot drive and my "eSATA" data drive (I ran a SATA cable out the slot between the top and the base of the M300). Everything looks good! (As usual. :-)
I haven't played with the netconsole stuff yet. Is it still too early?
I haven't played with the netconsole stuff yet. Is it still too early?
|
Re: Debian on Dell Kace M300 March 26, 2022 05:05PM |
Admin Registered: 14 years ago Posts: 19,288 |
> I haven't played with the netconsole stuff yet.
> Is it still too early?
It is not ready. Don't try, because it might cause problem booting after that.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> Is it still too early?
It is not ready. Don't try, because it might cause problem booting after that.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 March 26, 2022 05:49PM |
Registered: 9 years ago Posts: 52 |
A couple fun things happened over the past few days after the uboot upgrade.
One was a kernel panic and the other was a situation where I rebooted the Kace and it didn't activate the eth interface properly and just sat there lights-out with the system LED solid white.
I dropped syslog-ng on from the start so I've got logs of the panic but not much else:
it seems it was a panic regarding kswapd0.
for reference, the swap partition is a safe yet bigger-than-necessary 3.5GB, was going to be only 3GB but I misplaced 500MB when I was setting up the partitions originally.
what was happening prior to the panic was, commands were working but suddenly program execution started causing segfaults instead of running. I saw the issue and tried to send a sudo reboot and got back a segfault there too, swapped to a window with root access and ran reboot by itself and the window locked up. after I power cycled it I ran some RAM checks with memtester for about 8 hours overnight and it didn't find any problems, so that definitely wasn't the issue.
the NIC activation issue happened after a much later reboot after the fact and I don't recall what I was rebooting for at the time. I've looked through all the logs and dmesg backups etc. and nothing looks out of the ordinary... so either it didn't properly boot into Linux in the first place and locked up on reboot or the log was never written during the many hours it was on until I went and power cycled it. it hasn't happened again so it may be that it was a one-time fluke.
I'm going to keep watching to see if any more weird problems turn up. it might be that the panic has nothing to do with the uboot flash and the 5.16.5 kernel has some other issues other than USB3 being broken under the hood and a downgrade to 5.15.5 might be warranted in this case... but it's too early to tell yet. I haven't had this sort of panic happen on the Pogo v4 or the E02 running the current kernel so I don't know if this is a guaranteed fault/regression or if this is also a one-time fluke same as above, but I don't know how to recreate the steps to get to the panic in this case.
Edited 1 time(s). Last edit at 03/26/2022 05:53PM by sudos.
One was a kernel panic and the other was a situation where I rebooted the Kace and it didn't activate the eth interface properly and just sat there lights-out with the system LED solid white.
I dropped syslog-ng on from the start so I've got logs of the panic but not much else:
Mar 24 22:01:09 yamada kernel: ------------[ cut here ]------------ Mar 24 22:01:09 yamada kernel: WARNING: CPU: 0 PID: 34 at fs/dcache.c:443 dentry_lru_isolate+0x68/0x15c Mar 24 22:01:09 yamada kernel: Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative sg marvell_cesa orion_wdt kirkwood_thermal uio_pdrv_genirq uio Mar 24 22:01:09 yamada kernel: CPU: 0 PID: 34 Comm: kswapd0 Not tainted 5.16.5-kirkwood-tld-1 #1.0 bb123a1a8bc192eaa137d740646f2cde096d6733 Mar 24 22:01:09 yamada kernel: Hardware name: Marvell Kirkwood (Flattened Device Tree) Mar 24 22:01:09 yamada kernel: [<8010e33c>] (unwind_backtrace) from [<8010a964>] (show_stack+0x10/0x14) Mar 24 22:01:09 yamada kernel: [<8010a964>] (show_stack) from [<8011dce4>] (__warn+0xbc/0xe8) Mar 24 22:01:09 yamada kernel: [<8011dce4>] (__warn) from [<80b4a03c>] (warn_slowpath_fmt+0x78/0xb0) Mar 24 22:01:09 yamada kernel: [<80b4a03c>] (warn_slowpath_fmt) from [<802a7fcc>] (dentry_lru_isolate+0x68/0x15c) Mar 24 22:01:09 yamada kernel: [<802a7fcc>] (dentry_lru_isolate) from [<80259c4c>] (__list_lru_walk_one.constprop.0+0x58/0xc4) Mar 24 22:01:09 yamada kernel: [<80259c4c>] (__list_lru_walk_one.constprop.0) from [<80259ce4>] (list_lru_walk_one+0x2c/0x68) Mar 24 22:01:09 yamada kernel: [<80259ce4>] (list_lru_walk_one) from [<802aa4e0>] (prune_dcache_sb+0x44/0x80) Mar 24 22:01:09 yamada kernel: [<802aa4e0>] (prune_dcache_sb) from [<80295684>] (super_cache_scan+0xe0/0x148) Mar 24 22:01:09 yamada kernel: [<80295684>] (super_cache_scan) from [<80241cc4>] (shrink_slab.part.0.constprop.0+0x254/0x398) Mar 24 22:01:09 yamada kernel: [<80241cc4>] (shrink_slab.part.0.constprop.0) from [<80244c7c>] (shrink_node+0x644/0x88c) Mar 24 22:01:09 yamada kernel: [<80244c7c>] (shrink_node) from [<802456a4>] (kswapd+0x4b8/0x748) Mar 24 22:01:09 yamada kernel: [<802456a4>] (kswapd) from [<8013c340>] (kthread+0x154/0x164) Mar 24 22:01:09 yamada kernel: [<8013c340>] (kthread) from [<80100128>] (ret_from_fork+0x14/0x2c) Mar 24 22:01:09 yamada kernel: Exception stack(0x818b3fb0 to 0x818b3ff8) Mar 24 22:01:09 yamada kernel: 3fa0: 00000000 00000000 00000000 00000000 Mar 24 22:01:09 yamada kernel: 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 24 22:01:09 yamada kernel: 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Mar 24 22:01:09 yamada kernel: ---[ end trace 6b98251daf282d31 ]--- Mar 24 22:01:09 yamada kernel: 8<--- cut here --- Mar 24 22:01:09 yamada kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000003 Mar 24 22:01:09 yamada kernel: [00000003] *pgd=00000000 Mar 24 22:01:09 yamada kernel: Internal error: Oops: 801 [#1] PREEMPT ARM Mar 24 22:01:09 yamada kernel: Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative sg marvell_cesa orion_wdt kirkwood_thermal uio_pdrv_genirq uio Mar 24 22:01:09 yamada kernel: CPU: 0 PID: 34 Comm: kswapd0 Tainted: G W 5.16.5-kirkwood-tld-1 #1.0 bb123a1a8bc192eaa137d740646f2cde096d6733 Mar 24 22:01:09 yamada kernel: Hardware name: Marvell Kirkwood (Flattened Device Tree) Mar 24 22:01:09 yamada kernel: PC is at ___d_drop+0x44/0x58 Mar 24 22:01:09 yamada kernel: LR is at read_seqlock_excl.constprop.0+0xc/0x10 Mar 24 22:01:09 yamada kernel: pc : [<802a8d60>] lr : [<802a8878>] psr: 20000013 Mar 24 22:01:10 yamada kernel: sp : 818b3d68 ip : 8353003c fp : 0000a6c0 Mar 24 22:01:10 yamada kernel: r10: 84065c00 r9 : 84065e70 r8 : 00000000 Mar 24 22:01:10 yamada kernel: r7 : 818b2000 r6 : 85ab84b8 r5 : ef16dab8 r4 : 85ab8450 Mar 24 22:01:10 yamada kernel: r3 : 1dc546f6 r2 : 00000003 r1 : 00000000 r0 : ef16dab8 Mar 24 22:01:10 yamada kernel: Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Mar 24 22:01:10 yamada kernel: Control: 0005397f Table: 0b120000 DAC: 00000053 Mar 24 22:01:10 yamada kernel: Register r0 information: non-slab/vmalloc memory Mar 24 22:01:10 yamada kernel: Register r1 information: NULL pointer Mar 24 22:01:10 yamada kernel: Register r2 information: non-paged memory Mar 24 22:01:10 yamada kernel: Register r3 information: non-paged memory Mar 24 22:01:10 yamada kernel: Register r4 information: slab dentry start 85ab8440 pointer offset 16 size 40 Mar 24 22:01:10 yamada kernel: Register r5 information: non-slab/vmalloc memory Mar 24 22:01:10 yamada kernel: Register r6 information: slab dentry start 85ab8440 pointer offset 120 size 40 Mar 24 22:01:10 yamada kernel: Register r7 information: non-slab/vmalloc memory Mar 24 22:01:10 yamada kernel: Register r8 information: NULL pointer Mar 24 22:01:10 yamada kernel: Register r9 information: slab kmalloc-1k start 84065c00 pointer offset 624 size 1024 Mar 24 22:01:10 yamada kernel: Register r10 information: slab kmalloc-1k start 84065c00 pointer offset 0 size 1024 Mar 24 22:01:10 yamada kernel: Register r11 information: non-paged memory Mar 24 22:01:10 yamada kernel: Register r12 information: non-slab/vmalloc memory Mar 24 22:01:10 yamada kernel: Process kswapd0 (pid: 34, stack limit = 0xee9d3cad) Mar 24 22:01:10 yamada kernel: Stack: (0x818b3d68 to 0x818b4000) Mar 24 22:01:10 yamada kernel: 3d60: 85ab8450 85ab846c 85ab84b8 802a8d8c 85ab8450 802a906c Mar 24 22:01:10 yamada kernel: 3d80: 818b3db4 85ab8450 85ab84b8 802aa150 818b3db4 000002de 000002de 00000000 Mar 24 22:01:10 yamada kernel: 3da0: 00000000 802aa4ec 818b3db4 818b3e40 00000001 85ab89f8 859049f8 81304228 Mar 24 22:01:10 yamada kernel: 3dc0: 00000400 818b3e38 00024c2e 80295684 84065e70 00000400 802955a4 00000469 Mar 24 22:01:10 yamada kernel: 3de0: 84065e70 00000000 818b2000 818b3e00 00000400 00000000 00000000 80241cc4 Mar 24 22:01:10 yamada kernel: 3e00: 818b3e8c 00000000 83f30780 80659648 00000001 818b3e14 00043ace 00000009 Mar 24 22:01:10 yamada kernel: 3e20: 0000024c 00000000 00000400 0004985a 00000cc0 00000000 00000cc0 00000000 Mar 24 22:01:10 yamada kernel: 3e40: 00000000 00000400 00000000 81304228 00000005 818b3f0c 8145c5a4 00000cc0 Mar 24 22:01:10 yamada kernel: 3e60: 8145ca98 00000000 818b3f50 00000009 00000004 80244c7c 00000000 000000d0 Mar 24 22:01:10 yamada kernel: 3e80: 000008b4 000039c4 81a8cfe0 00000000 00000000 00000001 81000000 818b3e9c Mar 24 22:01:10 yamada kernel: 3ea0: 818b3e9c 00000000 00000000 00000000 00000000 000008b4 00000003 00000000 Mar 24 22:01:10 yamada kernel: 3ec0: 000000ef 00000127 000008b4 81304228 00000000 8145c5a4 818b2000 00000001 Mar 24 22:01:10 yamada kernel: 3ee0: 00000000 00000000 8145c77c 81a8cfe0 00000000 802456a4 8145c5a4 00000001 Mar 24 22:01:10 yamada kernel: 3f00: 00000000 000000d0 8190e000 000008b4 00000000 00000000 00000aae 00000893 Mar 24 22:01:10 yamada kernel: 3f20: 09000072 00000001 00000cc0 000000f2 000001c0 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: 3f40: 00000000 00000000 000000ef 000000f2 00000000 00000000 00000000 81304228 Mar 24 22:01:10 yamada kernel: 3f60: 8190fe90 81ae2980 818b2000 81ac6bc0 802451ec 8145c5a4 8190fe90 00000000 Mar 24 22:01:10 yamada kernel: 3f80: 81ae299c 8013c340 00000000 81ac6bc0 8013c1ec 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: 3fa0: 00000000 00000000 00000000 80100128 00000000 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: [<802a8d60>] (___d_drop) from [<802a8d8c>] (__d_drop+0x18/0x30) Mar 24 22:01:10 yamada kernel: [<802a8d8c>] (__d_drop) from [<802a906c>] (__dentry_kill+0x5c/0x1d4) Mar 24 22:01:10 yamada kernel: [<802a906c>] (__dentry_kill) from [<802aa150>] (shrink_dentry_list+0xd4/0xd8) Mar 24 22:01:10 yamada kernel: [<802aa150>] (shrink_dentry_list) from [<802aa4ec>] (prune_dcache_sb+0x50/0x80) Mar 24 22:01:10 yamada kernel: [<802aa4ec>] (prune_dcache_sb) from [<80295684>] (super_cache_scan+0xe0/0x148) Mar 24 22:01:10 yamada kernel: [<80295684>] (super_cache_scan) from [<80241cc4>] (shrink_slab.part.0.constprop.0+0x254/0x398) Mar 24 22:01:10 yamada kernel: [<80241cc4>] (shrink_slab.part.0.constprop.0) from [<80244c7c>] (shrink_node+0x644/0x88c) Mar 24 22:01:10 yamada kernel: [<80244c7c>] (shrink_node) from [<802456a4>] (kswapd+0x4b8/0x748) Mar 24 22:01:10 yamada kernel: [<802456a4>] (kswapd) from [<8013c340>] (kthread+0x154/0x164) Mar 24 22:01:10 yamada kernel: [<8013c340>] (kthread) from [<80100128>] (ret_from_fork+0x14/0x2c) Mar 24 22:01:10 yamada kernel: Exception stack(0x818b3fb0 to 0x818b3ff8) Mar 24 22:01:10 yamada kernel: 3fa0: 00000000 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Mar 24 22:01:10 yamada kernel: 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Mar 24 22:01:10 yamada kernel: Code: e5943008 e594200c e1a00005 e3530000 (e5823000) Mar 24 22:01:10 yamada kernel: ---[ end trace 6b98251daf282d32 ]--- Mar 24 22:01:10 yamada kernel: note: kswapd0[34] exited with preempt_count 3
it seems it was a panic regarding kswapd0.
for reference, the swap partition is a safe yet bigger-than-necessary 3.5GB, was going to be only 3GB but I misplaced 500MB when I was setting up the partitions originally.
what was happening prior to the panic was, commands were working but suddenly program execution started causing segfaults instead of running. I saw the issue and tried to send a sudo reboot and got back a segfault there too, swapped to a window with root access and ran reboot by itself and the window locked up. after I power cycled it I ran some RAM checks with memtester for about 8 hours overnight and it didn't find any problems, so that definitely wasn't the issue.
the NIC activation issue happened after a much later reboot after the fact and I don't recall what I was rebooting for at the time. I've looked through all the logs and dmesg backups etc. and nothing looks out of the ordinary... so either it didn't properly boot into Linux in the first place and locked up on reboot or the log was never written during the many hours it was on until I went and power cycled it. it hasn't happened again so it may be that it was a one-time fluke.
I'm going to keep watching to see if any more weird problems turn up. it might be that the panic has nothing to do with the uboot flash and the 5.16.5 kernel has some other issues other than USB3 being broken under the hood and a downgrade to 5.15.5 might be warranted in this case... but it's too early to tell yet. I haven't had this sort of panic happen on the Pogo v4 or the E02 running the current kernel so I don't know if this is a guaranteed fault/regression or if this is also a one-time fluke same as above, but I don't know how to recreate the steps to get to the panic in this case.
Edited 1 time(s). Last edit at 03/26/2022 05:53PM by sudos.
|
Re: Debian on Dell Kace M300 March 26, 2022 07:32PM |
Admin Registered: 14 years ago Posts: 19,288 |
Quote
I'm going to keep watching to see if any more weird problems turn up. it might be that the panic has nothing to do with the uboot flash and the 5.16.5 kernel has some other issues other than USB3 being broken under the hood and a downgrade to 5.15.5 might be warranted in this case... but it's too early to tell yet. I haven't had this sort of panic happen on the Pogo v4 or the E02 running the current kernel so I don't know if this is a guaranteed fault/regression or if this is also a one-time fluke same as above, but I don't know how to recreate the steps to get to the panic in this case.
Without looking at this closely, my hunch is the swap space. Looks suspicious.
Agreed that kernel 5.16.5 is indeed in doubt.
This box is not doing much. I just let it run to see if any error when it is mostly idle. It has been rebooted and running for a week with kernel 5.13.6.
192.168.0.232 Dell KACE M300 Linux version 5.13.6-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1.0 PREEMPT Sat Jul 31 22:10:39 PDT 2021 Debian 10.9 --- System Stats: /dev/sda: TS16GSSD25H-M: no sensor SMART check: PASSED Sat Mar 26 17:24:56 PDT 2022 up 1 week, 1 day, 17 hours, 22 minutesfree -h
total used free shared buff/cache available Mem: 1.7Gi 33Mi 1.5Gi 1.0Mi 169Mi 1.7Gi Swap: 511Mi 0B 511Mi
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 March 27, 2022 05:18AM |
Registered: 9 years ago Posts: 52 |
yeah I just downgraded to 5.15.5 on the kace for now, Pogo v4 and E02 will continue on with 5.16.5.
looking into it a bit further and it seems like kswapd panics are usually caused by the ram not pushing to swap fast enough or too fast... which shouldn't be the case here because of the overkill SSD. I had a shower thought earlier as to if this speculatively could be a byproduct of the SoC using DDR3 instead of DDR2, such as like with the QNAP devices with the same 88F6282 core and something being wonky with the 5.16 kernel in that regard not playing nice.
of course I don't have the equipment to test, but it's an interesting thought nonetheless.
looking into it a bit further and it seems like kswapd panics are usually caused by the ram not pushing to swap fast enough or too fast... which shouldn't be the case here because of the overkill SSD. I had a shower thought earlier as to if this speculatively could be a byproduct of the SoC using DDR3 instead of DDR2, such as like with the QNAP devices with the same 88F6282 core and something being wonky with the 5.16 kernel in that regard not playing nice.
of course I don't have the equipment to test, but it's an interesting thought nonetheless.
|
Re: Debian on Dell Kace M300 March 27, 2022 08:57PM |
Registered: 10 years ago Posts: 226 |
As another data point, I've been running 5.16.5 (and Bullseye) for a while now and I'm pushing my M300 pretty hard with a media server, a FTP server for my motion activated cameras, Windows shares, and a pretty big Java (yuck!) process that runs everyday and I haven't seen any problems. The one difference that may be notable is that I'm booting off a USB flash drive and using the SATA port for a 8TB externally powered drive that contains the swap file.
|
Re: Debian on Dell Kace M300 March 28, 2022 08:25PM |
Admin Registered: 14 years ago Posts: 19,288 |
> The one
> difference that may be notable is that I'm booting
> off a USB flash drive and using the SATA port for
> a 8TB externally powered drive that contains the
> swap file.
I think this is is very good configuration. It's the most flexible way. You can use the internal power of SATA with SSD inside the case, too. SATA power is stable for SSD. But by using external power for HDD, you eliminated any unknowns.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> difference that may be notable is that I'm booting
> off a USB flash drive and using the SATA port for
> a 8TB externally powered drive that contains the
> swap file.
I think this is is very good configuration. It's the most flexible way. You can use the internal power of SATA with SSD inside the case, too. SATA power is stable for SSD. But by using external power for HDD, you eliminated any unknowns.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 March 28, 2022 08:37PM |
Admin Registered: 14 years ago Posts: 19,288 |
So I've upgraded my rootfs to Debian bullseye. It was a massive change from buster.
No swapping occured during the upgrade.
free -h
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
192.168.0.232 Dell KACE M300 Linux version 5.13.6-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1.0 PREEMPT Sat Jul 31 22:10:39 PDT 2021 Debian 11.3 --- System Stats: /dev/sda: TS16GSSD25H-M: no sensor SMART check: PASSED Mon 28 Mar 2022 06:18:53 PM PDT up 1 week, 3 days, 18 hours, 16 minutes
No swapping occured during the upgrade.
free -h
total used free shared buff/cache available Mem: 1.7Gi 38Mi 89Mi 2.0Mi 1.6Gi 1.6Gi Swap: 511Mi 0.0Ki 511Mi
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 March 29, 2022 12:56AM |
Registered: 10 years ago Posts: 226 |
bodhi Wrote:
-------------------------------------------------------
> So I've upgraded my rootfs to Debian bullseye. It
> was a massive change from buster.
Tell me about it! It took me a week to get everything working.
One thing notable about the internal SATA connector is that it doesn't supply 12V, so an external supply was necessary for me.
-------------------------------------------------------
> So I've upgraded my rootfs to Debian bullseye. It
> was a massive change from buster.
Tell me about it! It took me a week to get everything working.
One thing notable about the internal SATA connector is that it doesn't supply 12V, so an external supply was necessary for me.
|
Re: Debian on Dell Kace M300 April 02, 2022 06:15AM |
Registered: 9 years ago Posts: 52 |
renojim Wrote:
-------------------------------------------------------
> As another data point, I've been running 5.16.5
> (and Bullseye) for a while now and I'm pushing my
> M300 pretty hard with ....
> ...and a pretty big Java (yuck!) process that runs
> everyday and I haven't seen any problems.
Can I ask how you're running Java? I haven't been able to get the packages from the debian apt repos to work. as far as I end up getting is the packages being installed (by installing default-jdk) and then java mysteriously throwing an error and terminating the process.
In the end I grabbed the Azul tarball for openjdk 11 which thankfully is compiled and available for armel, and while that works, it's less than ideal, as I was hoping to grab a copy of openjdk 17 which seems is not available.
Any insight you might have helps me greatly towards doing some higher-functioning testing of the platform on which I haven't been able to get any sort of java instance working properly since Jessie.
bodhi Wrote:
-------------------------------------------------------
> So I've upgraded my rootfs to Debian bullseye. It
> was a massive change from buster.
when I did the change-over to Bullseye on my lone amd64 linux box, it wasn't really anything special from the CLI side of things at least from what I was doing previously... openjdk-17 being available in the repo was nice, no more adoptopenjdk weird $path variable needed for my minecraft server instance, nothing bad happened to my nginx/php instances, all in all a quiet upgrade without issues.
-------------------------------------------------------
> As another data point, I've been running 5.16.5
> (and Bullseye) for a while now and I'm pushing my
> M300 pretty hard with ....
> ...and a pretty big Java (yuck!) process that runs
> everyday and I haven't seen any problems.
Can I ask how you're running Java? I haven't been able to get the packages from the debian apt repos to work. as far as I end up getting is the packages being installed (by installing default-jdk) and then java mysteriously throwing an error and terminating the process.
Setting up default-jre (2:1.11-72) ...
Setting up default-jdk-headless (2:1.11-72) ...
Setting up openjdk-11-jdk:armel (11.0.14+9-1~deb11u1) ...
update-alternatives: using /usr/lib/jvm/java-11-openjdk-armel/bin/jconsole to provide /usr/bin/jconsole (jconsole) in auto mode
Setting up ca-certificates-java (20190909) ...
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_zero.cpp:267), pid=5778, tid=5779
# fatal error: caught unhandled signal 11
#
# JRE version: (11.0.14+9) (build )
# Java VM: OpenJDK Zero VM (11.0.14+9-post-Debian-1deb11u1, interpreted mode, serial gc, linux-arm)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# //hs_err_pid5778.log
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
/var/lib/dpkg/info/ca-certificates-java.postinst: line 88: 5777 Done echo -e "-diginotar_root_ca\n-diginotar_root_ca_pem"
5778 Aborted | java -Xmx64m -jar $JAR -storepass "$storepass"
dpkg: error processing package ca-certificates-java (--configure):
installed ca-certificates-java package post-installation script subprocess returned error exit status 134
Setting up default-jdk (2:1.11-72) ...
Processing triggers for man-db (2.10.1-1~bpo11+1) ...
Processing triggers for ca-certificates (20210119) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_zero.cpp:267), pid=6467, tid=6468
# fatal error: caught unhandled signal 11
#
# JRE version: (11.0.14+9) (build )
# Java VM: OpenJDK Zero VM (11.0.14+9-post-Debian-1deb11u1, interpreted mode, serial gc, linux-arm)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /etc/ssl/certs/hs_err_pid6467.log
#
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted
E: /etc/ca-certificates/update.d/jks-keystore exited with code 1.
done.
Processing triggers for mailcap (3.69) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for libc-bin (2.31-13+deb11u3) ...
Errors were encountered while processing:
ca-certificates-java
E: Sub-process /usr/bin/dpkg returned an error code (1)
In the end I grabbed the Azul tarball for openjdk 11 which thankfully is compiled and available for armel, and while that works, it's less than ideal, as I was hoping to grab a copy of openjdk 17 which seems is not available.
Any insight you might have helps me greatly towards doing some higher-functioning testing of the platform on which I haven't been able to get any sort of java instance working properly since Jessie.
bodhi Wrote:
-------------------------------------------------------
> So I've upgraded my rootfs to Debian bullseye. It
> was a massive change from buster.
when I did the change-over to Bullseye on my lone amd64 linux box, it wasn't really anything special from the CLI side of things at least from what I was doing previously... openjdk-17 being available in the repo was nice, no more adoptopenjdk weird $path variable needed for my minecraft server instance, nothing bad happened to my nginx/php instances, all in all a quiet upgrade without issues.
|
Re: Debian on Dell Kace M300 April 02, 2022 03:47PM |
Admin Registered: 14 years ago Posts: 19,288 |
> So I've upgraded my rootfs to Debian bullseye. It
> was a massive change from buster.
I meant, it was a decent real life stress test to the internal SSD.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> was a massive change from buster.
I meant, it was a decent real life stress test to the internal SSD.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 April 02, 2022 07:13PM |
Registered: 10 years ago Posts: 226 |
sudos,
I probably can't help much with Java. I ran into the same problem as you and I wasted way too much time trying to get past it with no solution. What I finally ended up doing (if I recall correctly) was installing openjdk-8-jre from https://packages.debian.org/sid/armel/java/openjdk-8-jre . It's good enough for my purposes as I'd never use Java if I didn't have to for one particular purpose.
I had installed it before I "upgraded" to Bullseye and thankfully it wasn't removed unlike Python 2.7 and SMBv1 - I don't care how many security vulnerabilities they have! It took me a week to get everything working how I wanted it and I almost gave up on Bullseye forever.
I probably can't help much with Java. I ran into the same problem as you and I wasted way too much time trying to get past it with no solution. What I finally ended up doing (if I recall correctly) was installing openjdk-8-jre from https://packages.debian.org/sid/armel/java/openjdk-8-jre . It's good enough for my purposes as I'd never use Java if I didn't have to for one particular purpose.
I had installed it before I "upgraded" to Bullseye and thankfully it wasn't removed unlike Python 2.7 and SMBv1 - I don't care how many security vulnerabilities they have! It took me a week to get everything working how I wanted it and I almost gave up on Bullseye forever.
|
Re: Debian on Dell Kace M300 April 04, 2022 09:46AM |
Registered: 9 years ago Posts: 52 |
renojim Wrote:
-------------------------------------------------------
> What I finally ended up doing (if I recall correctly)
> was installing openjdk-8-jre from
> https://packages.debian.org/sid/armel/java/openjdk-8-jre
> . It's good enough for my purposes as I'd never
> use Java if I didn't have to for one particular
> purpose.
Looking at this and knowing there's still an openjdk8 package available in sid made me muster the courage to upgrade to testing on the Kace. Haven't run testing since the Squeeze=>Wheezy days.
So far so good, looks like openssh updated and auto regenerated ssh keys due to some old encryption standards being phased out, probably to make sure everyone has compliant keys regardless of previously used standards.
Sometime tomorrow I'll see if it's worth trying sid on it. I have one friend that has been running Sid for the last decade in production, and he's been a big help. So far that openjdk package won't work with bullseye nor testing for lack of dependency requirements this far into the version cycle, so this is necessary.
-------------------------------------------------------
> What I finally ended up doing (if I recall correctly)
> was installing openjdk-8-jre from
> https://packages.debian.org/sid/armel/java/openjdk-8-jre
> . It's good enough for my purposes as I'd never
> use Java if I didn't have to for one particular
> purpose.
Looking at this and knowing there's still an openjdk8 package available in sid made me muster the courage to upgrade to testing on the Kace. Haven't run testing since the Squeeze=>Wheezy days.
So far so good, looks like openssh updated and auto regenerated ssh keys due to some old encryption standards being phased out, probably to make sure everyone has compliant keys regardless of previously used standards.
Sometime tomorrow I'll see if it's worth trying sid on it. I have one friend that has been running Sid for the last decade in production, and he's been a big help. So far that openjdk package won't work with bullseye nor testing for lack of dependency requirements this far into the version cycle, so this is necessary.
|
Re: Debian on Dell Kace M300 April 04, 2022 07:56PM |
Admin Registered: 14 years ago Posts: 19,288 |
My recommendation.
If you use SATA as rootfs, it should be a better SSD or external HDD. The stock internal SSD is not of good quality.
I see error on some sectors sometime during boot. It does not affect the system operation (it is just a glorified USB type of flash with SATA interface), but I predict eventually it will crap out.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
If you use SATA as rootfs, it should be a better SSD or external HDD. The stock internal SSD is not of good quality.
I see error on some sectors sometime during boot. It does not affect the system operation (it is just a glorified USB type of flash with SATA interface), but I predict eventually it will crap out.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 April 05, 2022 06:59AM |
Registered: 9 years ago Posts: 52 |
bodhi Wrote:
-------------------------------------------------------
> My recommendation.
>
> If you use SATA as rootfs, it should be a better
> SSD or external HDD. The stock internal SSD is not
> of good quality.
>
> I see error on some sectors sometime during boot.
> It does not affect the system operation (it is
> just a glorified USB type of flash with SATA
> interface), but I predict eventually it will crap
> out.
not to mention it's an SSD from the era of 2010-2011, so anything newer will outperform it, that's why I went straight to that Sandisk 240GB SSD but any size will do.
the controller runs way too hot and who knows how the flash is being handled. it would be wise to do what I did and make a thermal pad stack to keep the controller chip cool by sinking the excess heat to the motherboard (completely safe albeit inefficient) and see if that helps things along with any experienced errors... more than likely it's just the controller overheating.
stock SSD also has no DRAM cache as previously said. Any newer name-brand SSD with any amount of cache RAM onboard will increase transfer speeds by a factor of about 3 times and be much more reliable.
I re-cased the 16GB stock into the old shell of the sandisk SSD with some thermal pad material and that seems to have been enough to keep it happy, I have that set aside as a rescue disk for the kace and pogo v4.
-------------------------------------------------------
> My recommendation.
>
> If you use SATA as rootfs, it should be a better
> SSD or external HDD. The stock internal SSD is not
> of good quality.
>
> I see error on some sectors sometime during boot.
> It does not affect the system operation (it is
> just a glorified USB type of flash with SATA
> interface), but I predict eventually it will crap
> out.
not to mention it's an SSD from the era of 2010-2011, so anything newer will outperform it, that's why I went straight to that Sandisk 240GB SSD but any size will do.
the controller runs way too hot and who knows how the flash is being handled. it would be wise to do what I did and make a thermal pad stack to keep the controller chip cool by sinking the excess heat to the motherboard (completely safe albeit inefficient) and see if that helps things along with any experienced errors... more than likely it's just the controller overheating.
stock SSD also has no DRAM cache as previously said. Any newer name-brand SSD with any amount of cache RAM onboard will increase transfer speeds by a factor of about 3 times and be much more reliable.
I re-cased the 16GB stock into the old shell of the sandisk SSD with some thermal pad material and that seems to have been enough to keep it happy, I have that set aside as a rescue disk for the kace and pogo v4.
|
Re: Debian on Dell Kace M300 May 03, 2022 03:50PM |
Registered: 9 years ago Posts: 52 |
Just chiming in to say 5.17.4 works properly on the Kace.
and to reply to this of course.
renojim Wrote:
-------------------------------------------------------
> What I finally ended up doing (if I recall correctly)
> was installing openjdk-8-jre from
> https://packages.debian.org/sid/armel/java/openjdk-8-jre
> . It's good enough for my purposes as I'd never
> use Java if I didn't have to for one particular
> purpose.
I did get Azul 11 to do what I needed in the end. Also found out there's a build artifact from the ev3dev people of openjdk 17 that properly works, but compiled for the TI ARM926EJ-S chip in the Lego Mindstorms EV3. same sort of architechture so it functions as intended! however, for what I needed to do for proof of concept work, 11 is fine.
and to reply to this of course.
renojim Wrote:
-------------------------------------------------------
> What I finally ended up doing (if I recall correctly)
> was installing openjdk-8-jre from
> https://packages.debian.org/sid/armel/java/openjdk-8-jre
> . It's good enough for my purposes as I'd never
> use Java if I didn't have to for one particular
> purpose.
I did get Azul 11 to do what I needed in the end. Also found out there's a build artifact from the ev3dev people of openjdk 17 that properly works, but compiled for the TI ARM926EJ-S chip in the Lego Mindstorms EV3. same sort of architechture so it functions as intended! however, for what I needed to do for proof of concept work, 11 is fine.
|
Re: Debian on Dell Kace M300 May 04, 2022 04:33AM |
Registered: 9 years ago Posts: 52 |
After sending the last post I found a copper shim in my parts bin, I don't recall exactly where I got it from... but it was the right thickness to place between the SoC and the steel chassis being used as a heatsink. I believe it came from ebay nearly a decade ago to replace a thermal pad in a laptop that died before it could get the shim installed.
for future reference, I believe the shim was 1mm thick, but I could be wrong.
I removed the old thermal pad (now safe in a ziploc just in case!) and roughed up the raised area with scotchbrite and cleaned with rubbing alcohol. afterwards, I placed some Ceramique 2 down (but you're welcome to use whatever your preferred paste is, I just happen to have way too much of this stuff...) and placed the shim on top, pressing it down with a bit of force using my thumb to get the excess paste to squeeze out the sides. Then I applied a dab of compound to the raised area of the Armada SoC and placed that down. No scuffing required on that side, it's flat enough! Screwing it in is all you need for that, no pressure required, the board will do that for you. it's not enough to get the board to bend, thankfully, but it's still just the right amount of pressure for good thermal contact as can be seen below.
Differences between idle and a 30-minute load test:
(tests done in an ambient room temp of 19-20C)
Stock idle: 41-44C
Stock Load: 58-62C
Shim Idle: 32-36C
Shim Load: 43-45C
EDIT: after a sustained load for more than a day, and taking temps every so often, I haven't seen the temperature go over 44C, so I think that's where it's going to stay. That essentially means it's now running full tilt at the STOCK IDLE temperature.
the results speak for themselves. the copper shim adds just enough thermal mass to matter. While still an inefficient transfer material sandwiched between two layers of compound, it's still more efficient than the decade-old thermal pad the device came with. Initial numbers above prove extremely enticing to leave this completely reversible, non-destructive modification in place.
Steel is not a good thermal transferring material. If not done properly, steel is an excellent insulator compared to other metals like aluminum or copper. What we're using the copper for here is as a first step, to absorb the heat from the SoC and better spread it over a wider surface area on the raised contact area of the steel structure inside, much better than the thermal pad can in the same area. By transferring it more efficiently, you're radiating it more efficiently through convection cooling. and by keeping the SoC cooler, you're extending its lifetime!
Note that if you attempt this, your choice of compound might matter to how long later you may need to clean it off and re-paste it. the reason I went with Ceramique 2, aside from cheap pricing, is it is non-conductive, and I know it to last practically forever even once it cures. You shouldn't need to use anything more than this stuff or a like-compound, as the wattage put out by the SoC doesn't require any fancy enthusiast-grade compounds. If you have a tube of MX-3, MX-4 or MX-5 around and want to use that instead as that's what you're comfortable with, go ahead! I'm not stopping you.
Attached is images of the shim compared to the thermal pad and the scuffed up contact surface. it was a modification I did within the timeframe of half an hour and I'm extremely happy I did. Summer is coming up and while my M300 is silently running away in my basement where it is cool, I'd rather not take the risk while I'm having so much fun with it, and I'm planning on leaving it there unattended for long stretches of time as I already have.
Hopefully this little infopost finds someone else well as the Armada chips are pretty much the only SoCs in the kirkwood family I can find to have a working thermal sensor that can be probed. The others might have it but I've never seen a device yet aside from this example where it has been made visible and working. that, or I'm just looking in the wrong spots!
Cheers.
Edited 2 time(s). Last edit at 07/04/2022 10:38AM by sudos.
for future reference, I believe the shim was 1mm thick, but I could be wrong.
I removed the old thermal pad (now safe in a ziploc just in case!) and roughed up the raised area with scotchbrite and cleaned with rubbing alcohol. afterwards, I placed some Ceramique 2 down (but you're welcome to use whatever your preferred paste is, I just happen to have way too much of this stuff...) and placed the shim on top, pressing it down with a bit of force using my thumb to get the excess paste to squeeze out the sides. Then I applied a dab of compound to the raised area of the Armada SoC and placed that down. No scuffing required on that side, it's flat enough! Screwing it in is all you need for that, no pressure required, the board will do that for you. it's not enough to get the board to bend, thankfully, but it's still just the right amount of pressure for good thermal contact as can be seen below.
Differences between idle and a 30-minute load test:
(tests done in an ambient room temp of 19-20C)
Stock idle: 41-44C
Stock Load: 58-62C
Shim Idle: 32-36C
Shim Load: 43-45C
EDIT: after a sustained load for more than a day, and taking temps every so often, I haven't seen the temperature go over 44C, so I think that's where it's going to stay. That essentially means it's now running full tilt at the STOCK IDLE temperature.
the results speak for themselves. the copper shim adds just enough thermal mass to matter. While still an inefficient transfer material sandwiched between two layers of compound, it's still more efficient than the decade-old thermal pad the device came with. Initial numbers above prove extremely enticing to leave this completely reversible, non-destructive modification in place.
Steel is not a good thermal transferring material. If not done properly, steel is an excellent insulator compared to other metals like aluminum or copper. What we're using the copper for here is as a first step, to absorb the heat from the SoC and better spread it over a wider surface area on the raised contact area of the steel structure inside, much better than the thermal pad can in the same area. By transferring it more efficiently, you're radiating it more efficiently through convection cooling. and by keeping the SoC cooler, you're extending its lifetime!
Note that if you attempt this, your choice of compound might matter to how long later you may need to clean it off and re-paste it. the reason I went with Ceramique 2, aside from cheap pricing, is it is non-conductive, and I know it to last practically forever even once it cures. You shouldn't need to use anything more than this stuff or a like-compound, as the wattage put out by the SoC doesn't require any fancy enthusiast-grade compounds. If you have a tube of MX-3, MX-4 or MX-5 around and want to use that instead as that's what you're comfortable with, go ahead! I'm not stopping you.
Attached is images of the shim compared to the thermal pad and the scuffed up contact surface. it was a modification I did within the timeframe of half an hour and I'm extremely happy I did. Summer is coming up and while my M300 is silently running away in my basement where it is cool, I'd rather not take the risk while I'm having so much fun with it, and I'm planning on leaving it there unattended for long stretches of time as I already have.
Hopefully this little infopost finds someone else well as the Armada chips are pretty much the only SoCs in the kirkwood family I can find to have a working thermal sensor that can be probed. The others might have it but I've never seen a device yet aside from this example where it has been made visible and working. that, or I'm just looking in the wrong spots!
Cheers.
Edited 2 time(s). Last edit at 07/04/2022 10:38AM by sudos.
|
Re: Debian on Dell Kace M300 May 04, 2022 06:58PM |
Admin Registered: 14 years ago Posts: 19,288 |
sudos,
Very nice mod!
> Hopefully this little infopost finds someone else
> well as the Armada chips are pretty much the only
> SoCs in the kirkwood family I can find to have a
> working thermal sensor that can be probed. The
> others might have it but I've never seen a device
> yet aside from this example where it has been made
> visible and working.
The Kirkwood plug-form factor boxes (Dockstar, Sheevaplug.... ) don't have thermal sensor. But the NAS form-factor boxes do have them, such as the Zyxel series NS310/320/310s/320s/325. Among them, some can be controlled with lmsensors (310, 320), some only with i2c (310S, 320s, 325). I can't recall if the Netgear Stora has thermal sensor or not.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Very nice mod!
> Hopefully this little infopost finds someone else
> well as the Armada chips are pretty much the only
> SoCs in the kirkwood family I can find to have a
> working thermal sensor that can be probed. The
> others might have it but I've never seen a device
> yet aside from this example where it has been made
> visible and working.
The Kirkwood plug-form factor boxes (Dockstar, Sheevaplug.... ) don't have thermal sensor. But the NAS form-factor boxes do have them, such as the Zyxel series NS310/320/310s/320s/325. Among them, some can be controlled with lmsensors (310, 320), some only with i2c (310S, 320s, 325). I can't recall if the Netgear Stora has thermal sensor or not.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 May 04, 2022 08:45PM |
Registered: 10 years ago Posts: 467 |
|
Re: Debian on Dell Kace M300 May 13, 2022 09:20AM |
Registered: 9 years ago Posts: 52 |
bodhi Wrote:
-------------------------------------------------------
> The Kirkwood plug-form factor boxes (Dockstar,
> Sheevaplug.... ) don't have thermal sensor.
Yep, that's correct, and another justification to make sure those SoCs stay cool enough to keep happy. I know in the E02 the kirkwood is bare, as it is in the Pogo v4 as well. in the E02 just add a heatsink that fits, and in the v4, you need to get crafty to figure a way to take up the air gap between the SoC and the steel weight on the bottom of the casing. That provides ample thermal mass to keep the 800MHz part cool enough to not fall over on itself.
I've looked at some of the NAS appliances as well and not that many of them have any real heatsinking for their SoCs either. Not a major concern as most of them have a fan, but I'm sure those get toasty too, and there's no fins to help radiate that heat anywhere... some just have a metal plate on top and call it a day.
"the thermals with this solution fall well within the manufacturer spec!" right, but at the cost of possible heat-related longevity concerns, the lingering heat drying up any electrolytics in the area surrounding it, and all that jazz.
the Kace is no different, there's that single big electrolytic on the side of the board with the DC-DC converter and stuff to drop 19v to all the other voltages needed. If that cap dries up and goes short from lingering heat, it could wreak irreparable damage on anything before or after it. I have plans to swap that cap out for a low-ESR power supply-rated polymer of the same value despite it being a reputable brand.
-------------------------------------------------------
> The Kirkwood plug-form factor boxes (Dockstar,
> Sheevaplug.... ) don't have thermal sensor.
Yep, that's correct, and another justification to make sure those SoCs stay cool enough to keep happy. I know in the E02 the kirkwood is bare, as it is in the Pogo v4 as well. in the E02 just add a heatsink that fits, and in the v4, you need to get crafty to figure a way to take up the air gap between the SoC and the steel weight on the bottom of the casing. That provides ample thermal mass to keep the 800MHz part cool enough to not fall over on itself.
I've looked at some of the NAS appliances as well and not that many of them have any real heatsinking for their SoCs either. Not a major concern as most of them have a fan, but I'm sure those get toasty too, and there's no fins to help radiate that heat anywhere... some just have a metal plate on top and call it a day.
"the thermals with this solution fall well within the manufacturer spec!" right, but at the cost of possible heat-related longevity concerns, the lingering heat drying up any electrolytics in the area surrounding it, and all that jazz.
the Kace is no different, there's that single big electrolytic on the side of the board with the DC-DC converter and stuff to drop 19v to all the other voltages needed. If that cap dries up and goes short from lingering heat, it could wreak irreparable damage on anything before or after it. I have plans to swap that cap out for a low-ESR power supply-rated polymer of the same value despite it being a reputable brand.
|
Re: Debian on Dell Kace M300 May 13, 2022 03:03PM |
Admin Registered: 14 years ago Posts: 19,288 |
> I know in the E02 the kirkwood is bare, as
> it is in the Pogo v4 as well. in the E02 just add
> a heatsink that fits, and in the v4, you need to
> get crafty to figure a way to take up the air gap
> between the SoC and the steel weight on the bottom
> of the casing. That provides ample thermal mass to
> keep the 800MHz part cool enough to not
> fall over on itself.
Really simple just drill holes on the plastic case, and place them sideway. Sometime low tech solution is better.
For ones that have upper SATA slot like GoFlex Home/Net and Pogo V4, I raise them higher with cloth feets (you can buy anywhere like HomeDepot or Walmart). The Dockstar should have drilled holes on the case and placed sideway, it is a lot hotter than other Kirkwood plugs. The E02 ventillation is fine as it is.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> it is in the Pogo v4 as well. in the E02 just add
> a heatsink that fits, and in the v4, you need to
> get crafty to figure a way to take up the air gap
> between the SoC and the steel weight on the bottom
> of the casing. That provides ample thermal mass to
> keep the 800MHz part cool enough to not
> fall over on itself.
Really simple just drill holes on the plastic case, and place them sideway. Sometime low tech solution is better.
For ones that have upper SATA slot like GoFlex Home/Net and Pogo V4, I raise them higher with cloth feets (you can buy anywhere like HomeDepot or Walmart). The Dockstar should have drilled holes on the case and placed sideway, it is a lot hotter than other Kirkwood plugs. The E02 ventillation is fine as it is.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 May 26, 2022 05:01PM |
Registered: 9 years ago Posts: 52 |
Bodhi, I'm about to drop a blog post regarding the M300 up onto wordpress, and I'm noticing the install guide linked in the OP post is outdated. Would you be willing to update the guide post so it's up to date for mentioning the current rootfs and current 2022-04 u-boot build further up this page?
it also seems I sold a few of my friends on buying one to mess around with, so having that resource a bit more current would definitely be helpful if you're alright with doing that.
it also seems I sold a few of my friends on buying one to mess around with, so having that resource a bit more current would definitely be helpful if you're alright with doing that.
|
Re: Debian on Dell Kace M300 May 26, 2022 05:42PM |
Admin Registered: 14 years ago Posts: 19,288 |
sudos,
> Would you be willing to update the guide post so
> it's up to date for mentioning the current rootfs
> and current 2022-04 u-boot build further up this
> page?
Sure, I'll consolidate the instruction. I am getting a bit busy with day jobs, it will be a few days or a week from now.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> Would you be willing to update the guide post so
> it's up to date for mentioning the current rootfs
> and current 2022-04 u-boot build further up this
> page?
Sure, I'll consolidate the instruction. I am getting a bit busy with day jobs, it will be a few days or a week from now.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: Debian on Dell Kace M300 May 31, 2022 10:38PM |
Admin Registered: 14 years ago Posts: 19,288 |
I've started to write a new installation procedure for this box. The simplest way is to install from inside stock OS.
But now I realized that I never log into stock OS when the box is in a pristine condition. I skipped that and boot straight into my rootfs on USB. And later I just mounted the stock rootfs and changed the root password in its shadow file.
So I don't know the stock root or admin credential :) Anybody knows?
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 05/31/2022 10:39PM by bodhi.
But now I realized that I never log into stock OS when the box is in a pristine condition. I skipped that and boot straight into my rootfs on USB. And later I just mounted the stock rootfs and changed the root password in its shadow file.
So I don't know the stock root or admin credential :) Anybody knows?
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 05/31/2022 10:39PM by bodhi.
|
Re: Debian on Dell Kace M300 May 31, 2022 11:09PM |
Registered: 8 years ago Posts: 375 |
I guess we can skip this ....I don't think anyone will use that box with the original 16GB "sd". So he / she will need to remove the old drive and he / she needs to open the case anyway.. When he / she opens the case, then booting with uart or changing shadowed password can be easy.
Edited 1 time(s). Last edit at 05/31/2022 11:10PM by daviddyer.
Edited 1 time(s). Last edit at 05/31/2022 11:10PM by daviddyer.
|
Re: Debian on Dell Kace M300 May 31, 2022 11:49PM |
Registered: 9 years ago Posts: 52 |
bodhi Wrote:
-------------------------------------------------------
> I've started to write a new installation procedure
> for this box. The simplest way is to install from
> inside stock OS.
I've had issues with partition alignment and weird issues of making the rootfs from within the stock debian install... but updating uboot, yes, 100% stable and proper way to go, the new rootfs should be prepared off-device however.
> But now I realized that I never log into stock OS
> when the box is in a pristine condition. I skipped
> that and boot straight into my rootfs on USB. And
> later I just mounted the stock rootfs and changed
> the root password in its shadow file.
>
> So I don't know the stock root or admin credential
> :) Anybody knows?
not a single soul knows, it was hard coded onto a USB key that is lost to the ages.
something to note for the guide, it seems that the /etc/fw_env.config listed in an older guide seems to not allow for uboot envs to be manipulated or flashed from the modern rootfs with a modern uboot base. it takes commands blindly and acts like you never tried to load it. Happens on three M300s I have access to now both with the 5.13.6 kernel and 5.17.4 kernel.
reason I say this is one of my friends took his m300 and updated the uboot but did not successfully write the proper uboot envs by doing something completely wrong, and the SSD seems to have failed at some point afterwards during all of the diagnostics, so the stock rootfs is lost. he can setenv enough of the new uboot envs to get it to stick, but it doesn't seem to do anything when he does saveenv.
the definition for /dev/mtd1 in /etc/fw_env.config is listed as follows:
if there's any way to resolve this, it'd save me a lot of headaches as I only have remote ssh access to this box. but as the issue happens with working and stable M300s as well, there's likely an issue there that needs looked into.
Edited 1 time(s). Last edit at 05/31/2022 11:51PM by sudos.
-------------------------------------------------------
> I've started to write a new installation procedure
> for this box. The simplest way is to install from
> inside stock OS.
I've had issues with partition alignment and weird issues of making the rootfs from within the stock debian install... but updating uboot, yes, 100% stable and proper way to go, the new rootfs should be prepared off-device however.
> But now I realized that I never log into stock OS
> when the box is in a pristine condition. I skipped
> that and boot straight into my rootfs on USB. And
> later I just mounted the stock rootfs and changed
> the root password in its shadow file.
>
> So I don't know the stock root or admin credential
> :) Anybody knows?
not a single soul knows, it was hard coded onto a USB key that is lost to the ages.
something to note for the guide, it seems that the /etc/fw_env.config listed in an older guide seems to not allow for uboot envs to be manipulated or flashed from the modern rootfs with a modern uboot base. it takes commands blindly and acts like you never tried to load it. Happens on three M300s I have access to now both with the 5.13.6 kernel and 5.17.4 kernel.
reason I say this is one of my friends took his m300 and updated the uboot but did not successfully write the proper uboot envs by doing something completely wrong, and the SSD seems to have failed at some point afterwards during all of the diagnostics, so the stock rootfs is lost. he can setenv enough of the new uboot envs to get it to stick, but it doesn't seem to do anything when he does saveenv.
the definition for /dev/mtd1 in /etc/fw_env.config is listed as follows:
/dev/mtd1 0x0 00001000 0x00001000as defined in the old guide. but yet the pogo E02 config I have lists /dev/mtd0 as the defined MTD device.
if there's any way to resolve this, it'd save me a lot of headaches as I only have remote ssh access to this box. but as the issue happens with working and stable M300s as well, there's likely an issue there that needs looked into.
Edited 1 time(s). Last edit at 05/31/2022 11:51PM by sudos.
