Welcome! Log In Create A New Profile

Advanced

Debian on Dell Kace M300

Posted by JDS420 
Re: Debian on Dell Kace M300
March 21, 2022 02:57PM
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
Re: Debian on Dell Kace M300
March 22, 2022 05:57PM
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.

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 all
Expected 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/mtd0
Expected 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/mtd1
Expected 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
Attachments:
open | download - uboot.2022.04-tld-1.m300.bodhi.tar (400 KB)
Re: Debian on Dell Kace M300
March 22, 2022 11:24PM
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:
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.
Attachments:
open | download - empty port.jpg (798.1 KB)
open | download - SSD with thermal pad stack.jpg (683 KB)
open | download - SSD installed.jpg (744.3 KB)
Re: Debian on Dell Kace M300
March 23, 2022 01:24AM
Thanks for the report sudos!

-bodhi
===========================
Forum Wiki
bodhi's corner
Re: Debian on Dell Kace M300
March 26, 2022 04:33PM
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?
Re: Debian on Dell Kace M300
March 26, 2022 05:05PM
> 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
Re: Debian on Dell Kace M300
March 26, 2022 05:49PM
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:

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
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 minutes
free -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
Re: Debian on Dell Kace M300
March 27, 2022 05:18AM
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.
Re: Debian on Dell Kace M300
March 27, 2022 08:57PM
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
> 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
Re: Debian on Dell Kace M300
March 28, 2022 08:37PM
So I've upgraded my rootfs to Debian bullseye. It was a massive change from buster.

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
Re: Debian on Dell Kace M300
March 29, 2022 12:56AM
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.
Re: Debian on Dell Kace M300
April 02, 2022 06:15AM
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.

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
> 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
Re: Debian on Dell Kace M300
April 02, 2022 07:13PM
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.
Re: Debian on Dell Kace M300
April 04, 2022 09:46AM
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.
Re: Debian on Dell Kace M300
April 04, 2022 07:56PM
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
Re: Debian on Dell Kace M300
April 05, 2022 06:59AM
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.
Re: Debian on Dell Kace M300
May 03, 2022 03:50PM
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.
Re: Debian on Dell Kace M300
May 04, 2022 04:33AM
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 0.5mm 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 1 time(s). Last edit at 05/06/2022 01:56AM by sudos.
Attachments:
open | download - copper shim next to thermal pad.jpg (57.3 KB)
open | download - roughed up with scotchbrite.jpg (114.1 KB)
Re: Debian on Dell Kace M300
May 04, 2022 06:58PM
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
Re: Debian on Dell Kace M300
May 04, 2022 08:45PM
bodhi Wrote:

> I can't recall if the Netgear Stora has thermal
> sensor or not.

Netgear Stora has a LM75 Temperature Sensor and Thermal Watchdog and a PWM Fan Controller.

Ray
Re: Debian on Dell Kace M300
May 13, 2022 09:20AM
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.
Re: Debian on Dell Kace M300
May 13, 2022 03:03PM
> 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
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: