Last time I had a problem with this in an M300 some months ago, it was a flaky SSD. My suggestion would be to look into your SSD health with smartmontools and verify it's still good. I'm also assuming the SSD has been replaced, as the stock 16GB Transcend SSD is *very* unstable being 13 years old at this point and the Silicon Motion controller chip on it runs excessively hot... it isby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > We are also facing another EOL issue with a > possible removal of armel architecture in Debian > 13. Basically, if that happens we can continue > upgrading Kirkwood kernel, but all Kirkwood boxes > are stuck in Debian 12 :( Hopefully another distro > will still support armel. Don't mean to reviby sudos - Debian
Tedious_1 Wrote: ------------------------------------------------------- > Since I am new to both the forum and also to these > devices, I have no experience in what the normal > transfer speeds for these kirkwood/pogo boxes > should have. Aside from the quite old postings in > the Performance Tuning and Benchmarks posts, no > one has really mentioned what speeds they areby sudos - Debian
As was already talked about in another thread just a little while ago, most of the network transfer stuff with a kirkwood is going to be quite slow these days because of the encryption algorithms in place for most file transfer protocols, samba and NFS included. None of them are supported by the kirkwood's hardware encryption acceleration onboard so far as I understand, and even at that, notby sudos - Debian
y'know I just had a thought, coming back here to see how this is doing... do you have non-free-firmware added to your apt sources and firmware-realtek installed? Last I remember, the kernel-provided gigabit drivers weren't the best and the firmware was needed. This wasn't really mentioned anywhere that it was installed so I'm just checking beforehand. I saw the failed firby sudos - Debian
I'm slightly interested in this as the Kace M300 has DDR3-1333 chips on the board (4x Micron D9LLF chips) and the clock speed on the RAM side is by default set to 1066. if there's any similarities between the Armada 310 and 370 in that way it might be possible to also increase the RAM speed on the 310's memory bus for a small bump in performance. It's my understanding these weby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > @sudos, > > I agreed with most of what you said. Except for: > > > such, transfers requiring encryption (such as > > SSH/SFTP) are going to eat at the CPU usage, > > moreso if the speed is slow. > > I've already come to > > terms that the most I'll ever get out fiby sudos - Debian
More food for thought: the Marvell kirkwood has no floating point unit. anything that requires floating point is going to make it suffer. As such, transfers requiring encryption (such as SSH/SFTP) are going to eat at the CPU usage, moreso if the speed is slow. I've already come to terms that the most I'll ever get out file transfer-wise is going to be 7-8MB/s maximum on any kirkwood devby sudos - Debian
Jader: if it helps any, I also did a write-up on a basic installation of stuff here: https://sudos.wordpress.com/2022/05/27/dell-kace-m300-or-fancy-paperweight-runs-modern-linux/ Ideally the instructions here in this thread should be followed to a T, and while I've posted the image here for reference, there's also an image on the write-up of which pin is which for the serial header.by sudos - Debian
bodhi Wrote: ------------------------------------------------------- > dhargens, > > > > - kirkwood_thermal: this module only works > with > > the M300 > > > > I missed this pointer - how do I load/enable > this > > module on my M300? > > It should already be running. Check it: > > lsmod > > if not running then >by sudos - Debian
bodhi Wrote: ------------------------------------------------------- > - kirkwood_thermal: this module only works with > the M300, afaict. Other boxes Kirkwood 88F6282 SoC > seems not working properly, perhaps because they > have their own method for thermal. So it might > also be a good thing not to confuse the users with > 2 different thermal monitoring methods. And thby sudos - Debian
CyberPK Wrote: ------------------------------------------------------- > Yes, I've read the warnings. > I think it should be investigated because until > now there were no report of data > corruption/deadlocks on encrypted drives using > Marvel CESA engine, so I think that the problem is > more theorical then real. Also, if the problem is > not fixed, should be mby sudos - Debian
Had to do a fresh install on my third M300 due to some weirdness caused by systemd/sysvinit stuff moving between init systems and back, but I decided to use the new bookworm rootfs from November. Noticed a few things with the bookworm rootfs: - There's a number of packages apt reports as "are installed and are no longer required" which seems to take up about 50MB of space. Thby sudos - Debian
Yep, that's the package I was referring to, and seems to be the brianchild of Simon Tatham, aka Chiark, aka the person that made the PuTTY family of clients... Without it, certain things just will not start. If anything my suggestion would be to include it in the upcoming bookworm rootfs by default. On the subject of PuTTY, it'd also be a good idea to include sshguard as a default pby sudos - Debian
Wanted to give a PSA to anyone looking to try the Cockpit web management package from main or backports on your Kace, it forcibly changes your init system to systemd upon install. On the Kace this isn't an issue because there's plenty of RAM, and no extra RAM seems to be used much, but on other systems with 128MB or 256MB of RAM this may pose a small issue later on. I didn't need tby sudos - Debian
Probably a good idea to mention that Buster-LTS and later Bullseye-LTS are a thing only because of NASA and JPL utilizing that branch at their facilities and on the International Space Station. For this reason the LTS branch came into being, specifically for the far-latter, for software stability in orbit. This is the main reason why the LTS branch exists, and why armel is specifically now deprecby sudos - Debian
mrc333777 Wrote: ------------------------------------------------------- > bodhi Wrote: > ------------------------------------------------------- > > @mrc333777, > > > > > > > if your > > > interested i can do the other 2 again, which > > were > > > really fast and give you the results from > each > > and > >by sudos - Debian
bodhi Wrote: ------------------------------------------------------- > > > Is this SSD formatted Ext3 or Ext4? > > > > Both are formatted Ext4. Next time it comes up > and > > fails, i'll try to get a console running to > > capture the issue for clarity's sake. > > I hope you did a "finalize" ( (no lazy_init) when > youby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > Is this SSD formatted Ext3 or Ext4? Both are formatted Ext4. Next time it comes up and fails, i'll try to get a console running to capture the issue for clarity's sake.by sudos - Debian
Something to report... Even with adjusted envs to take care of the larger-than-11MB initramfs with 5.18.6, whenever I'm doing an update that requires the rewrite of uInitrd as outlined in the kernel thread, the M300 always wants to just not-boot afterwards. This also happened previously on older kernels as well, but only past 5.15. I'm not sure what the deal is, I don't have eitby sudos - Debian
Huh, was almost sure something somewhere said 2GHz.by sudos - Debian
bodhi Wrote: ------------------------------------------------------- > This USI Topkick has been done and should be on > the support list. > > There it is: > > QuoteLinux Kernel 5.17.x Kirkwood package and > rootfs for GoFlex Home/Net, Pogoplug > E02/Mobile/V4, iConnect, Dockstar, Sheevaplug, > NSA320, NSA320S, NSA325, NSA310S, NSA310, > Topkick, Netgearby sudos - Debian
daviddyer Wrote: ------------------------------------------------------- > Looks like kirkwood @ 2Ghz with DDR2 memory DDR3. 2x H5TQ2G83DFR-H9C chips. definitely DDR3. Hynix datasheet suggests in the naming matrix that this is a normal power consumption 256Mbitx8 with "commercial temperature range" and -H9* denotes DDR3-1333 9-9-9. Probably running that RAM at 1066 for what itby sudos - Debian
Searching around on eBay I came across a $12 very peculiar item mis-categorized in the industrial PLC section... and doing some digging in the forum search, doesn't seem like anyone has talked about this device before, so here we go: It seems to be made by Universal Scientific Industrial Co., as in the same USI that is the OEM of the Kace M300 that Dell contracted from them with no expensby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > There are a couple diferent ways. If flashing is > not possible in Debian, you can kwboot the stock > u-boot image, and that stock u-boot will be able > to unlock the SPI flash. I'm pretty certain that > is possible. Note that once you unprotect the > flash using stock u-boot, it stays unprotectedby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > you could have just flashed stock > u-boot back, start fresh, and solve this problem > in an easier way. I think I've mentioned this > before in my previous post. > > Most of the time, the KISS principle is the best > method. Hardware protection mode means the flash as a whole, all 100% oby sudos - Debian
We ended up fixing the problem... but it's a lot more in-depth than I was expecting to go. the SPI flash chip was so write-protected even the section that holds the normally read/write area with the write protect bits was write protected. I'm posting the write-up here so to be able to reference in case someone else has this problem down the line. Even with the installation guide rewritby sudos - Debian
...except on both of my kace boxes, I never sent the saveenv command, and yet I can't edit either of them. I know for a true absolute fact I didn't run saveenv at all as both of my envs on both local boxes were set from Linux only as per the instructions. I never did anything at the uboot prompt aside from "protect off all" and "boot" at the stock prompt. every otherby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > Yes. I know what's going on there. It's all > because the SPI flash was protected initially > (Dell engineers are too clever by half). > > Will get back to this thread and explain in more > details. > > In a nutshell, to start fresh we can always flash > stock u-boot back and frby sudos - Debian
bodhi Wrote: ------------------------------------------------------- > After log in, flash the default envs image > following the instruction in new u-boot > installation. > > > 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 datby sudos - Debian