Home Forums Hardware discussions No network interfaces after OS crash

This topic contains 6 replies, has 4 voices, and was last updated by  zeroping 10 months, 1 week ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #1758


    My Espressobin is constantly rebooting. I guess is overheating although I also added a small radiator and there is no CPU activity when is overheating. Also the CPU frequency during this time is oscilating between 200 and 500Mhz.
    After reboot the connection with the network switch chipset is gone, I don’t have anymore the interfaces wan, lan0 and lan1. In order for the interfaces to be listed again I have to poweroff the board, wait a minute and then power it on again.
    This happens with multiple bootloaders:
    – the original one
    – U-Boot 2017.03-armada-17.10
    – and an uboot provided by armbian: https://dl.armbian.com/espressobin/u-boot/flash-image-1g-1cs-1000_800_boot_sd_and_usb.bin

    Also I tried multiple operating systems:
    – Openwrt 17.10
    – Openwrt 18.06.rc1
    – Armbian Stretch
    – Armbian Xenial
    – Ubuntu 16.04.3 LTS

    So it doesn’t matter the bootloader or the OS, the board is crashing constantly and after the crash the are no more network interfaces.

    Any ideas?
    But I don’t want to add a bigger radiator and a fan, because I read that this CPU should run at 1000Mhz without a fan.



    Have you tried with lower speeds? Perhaps you need to start with more conservative u-boot like 800/800 or even 600/600? It will cost you less time then testing all existing userspace (OpenWRT, Ubuntu, …) which relies on stock u-boot and cannot represent any real change in this problem.

    I am running my Espresso without a fan or a heatsink. It was preset on 800Mhz and it works O.K. … updated to latest u-boot and with a modern kernel. Also, forget about stock kernel 4.4.y … it is in a bad shape.



    Yes, I also tried the armbian bootloaders for 800/800 and 600/600:

    A friend has an Espressobin with 2 DDR chipsets, and his version doesn’t seem to have this problem.
    I have the version with one 1G DDR chipset.



    I just started having this issue when I moved my Espressobin a bit. The CPU on mine also seems awfully hot, and I’m guessing my new location for it has slightly less cooling. I’m also running Armbian stretch, with one of their bootloaders for 1000/800, as that’s what my original bootloader was set up for. I also have a single-chip 1 GB board.

    Based on the guess that it might be heat, I added a quick-and-dirty heatsink (a small metal plate and some thermal paste – still better than nothing), and while it seems to be running cooler, it’s still locking up under basically no load. I’ve also tried a different power supply with no luck.

    Maybe our boards are from a bad batch or something?

    Did you find a solution? I think my next course of action is to try a 600/600 MHz bootloader and see if it still happens.



    Which kernel are you running? Another possibility to gain stability is to go with a 800/800 u-boot. Wort trying.



    I was getting constant lockups on 4.4.8, and I installed a fan: https://noctua.at/en/nf-a4x10-flx and now I have an uptime of: 176d 3h 5m 47s.

    These definitely need cooling, unless the 4.4.y kernels are really borked with temps as armbian is saying. I’ve never tried to upgrade, as soon as I flashed a proper u-boot with the switch disabled until full boot, I haven’t touched the board.



    I’ve tried running 800/800, and still got lockups. I tried 600/600, and couldn’t boot the kernel, so I went back to 800/800.

    I’ve also tried putting a heatsink on the three main IC’s on the underside of the board (the processor, switch, and RAM, I think), and still had no luck. I also tried a couple of options for power.

    It really locks up consistently when it’s in an enclosure, so I’m inclined to agree that it seems like it’s thermal or power, even if my heatsink didn’t make a difference. It’s a pity there doesn’t seem to be a built-in temperature sensor in the processor itself.

    I’ll keep grabbing at straws – I’m wondering if it could be some other, smaller component getting to hot (like a regulator), and dropping power for a moment, causing the reset.

    Is there some other kernel (and device tree) I should try, that is known to be stable?

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Signup to our newsletter

Technical specification tables can not be displayed on mobile. Please view on desktop