["mmc0: Timeout waiting for hardware interrupt"]

I've been having issues with my Helios4 becoming unresponsive when it's been up for a while.

 

I decided to do some more thorough investigating and found that it was having problems writing to the sdcard. That led to the following entries in syslog:

 

Dec 20 21:36:43 helios-backup kernel: [318645.034243] mmc0: Timeout waiting for hardware interrupt.
Dec 20 21:36:43 helios-backup kernel: [318645.034254] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
Dec 20 21:36:43 helios-backup kernel: [318645.034258] mmc0: sdhci: Sys addr:  0x00000008 | Version:  0x00000202
Dec 20 21:36:43 helios-backup kernel: [318645.034263] mmc0: sdhci: Blk size:  0x00007200 | Blk cnt:  0x00000001
Dec 20 21:36:43 helios-backup kernel: [318645.034267] mmc0: sdhci: Argument:  0x0084a0d0 | Trn mode: 0x0000002b
Dec 20 21:36:43 helios-backup kernel: [318645.034271] mmc0: sdhci: Present:   0x01e60006 | Host ctl: 0x00000017
Dec 20 21:36:43 helios-backup kernel: [318645.034274] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034278] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000207
Dec 20 21:36:43 helios-backup kernel: [318645.034282] mmc0: sdhci: Timeout:   0x0000000e | Int stat: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034285] mmc0: sdhci: Int enab:  0x03ff000b | Sig enab: 0x03ff000b
Dec 20 21:36:43 helios-backup kernel: [318645.034289] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034292] mmc0: sdhci: Caps:      0x25fcc8b2 | Caps_1:   0x00002f77
Dec 20 21:36:43 helios-backup kernel: [318645.034296] mmc0: sdhci: Cmd:       0x0000193a | Max curr: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034299] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034303] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000900
Dec 20 21:36:43 helios-backup kernel: [318645.034306] mmc0: sdhci: Host ctl2: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034309] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x78275208
Dec 20 21:36:43 helios-backup kernel: [318645.034313] mmc0: sdhci: ============================================
Dec 20 21:36:46 helios-backup kernel: [318648.042018] mmc0: Card stuck being busy! __mmc_poll_for_busy
Dec 20 21:36:48 helios-backup kernel: [318649.277911] mmc0: card never left busy state
Dec 20 21:36:48 helios-backup kernel: [318649.277918] mmc0: tried to HW reset card, got error -110
Dec 20 21:36:48 helios-backup kernel: [318649.277923] mmcblk0: recovery failed!
Dec 20 21:36:48 helios-backup kernel: [318649.277947] blk_update_request: I/O error, dev mmcblk0, sector 8691920 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
Dec 20 21:36:48 helios-backup kernel: [318649.277958] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:348: I/O error 10 writing to inode 382819 starting block 1086491)

 

Is it possible this is due to the power supply starting to go bad? I haven't yet tried using different sdcards, but that would be my next step.

 

Has anyone else seen this?

[Build sys-oled fails on bullseye]

Ah, it works now, thank you. It was failing to build RPI.GPIO, but that seems to be fixed.

[Build sys-oled fails on bullseye]

I was trying get sys-oled running on a new installation (upgrade, really) of bullseye.

 

If go with the original Kobol github version, https://github.com/kobol-io/sys-oled, it fails to build RPI.GPIO and something else.

 

I also found an alternate at https://github.com/rpardini/sys-oled-hc4, that builds, but when I run it, it complains about a thermal call in python:

# sys-oled --display sh1106
Traceback (most recent call last):
  File "/usr/local/bin/sys-oled", line 142, in <module>
    main()
  File "/usr/local/bin/sys-oled", line 132, in main
    display_info(device)
  File "/usr/local/bin/sys-oled", line 105, in display_info
    draw.text((0, 0), cpu_usage(), font=font, fill="white")
  File "/usr/local/bin/sys-oled", line 78, in cpu_usage
    temp = psutil.sensors_temperatures()['cpu_thermal']
KeyError: 'cpu_thermal'

I opened an issue with the Kobol github, but I don't anticipate much in the way of results there. `rpardini` doesn't appear to be able to accept issues.

 

Has anyone had any success with getting this running in bullseye?

 

[mpd segfault on OrangePi One]

Armbianmonitor:

http://ix.io/2HqW

I'm not sure if I should pursue this here or if I should open a ticket through Debian Bugs.

 

A recent update now causes mpd to segfault. mpd comes from the Debain armhf repository.

 

I'm not sure how to determine if this is a hardware issue with my board somehow or if there is an interaction with a new kernel or if it's because the package updated the binary or a library.  To make sure it wasn't something weird in my configuration I moved the conf file out of the way and re-ran mpd with the same result.

 

If it helps, I can post an strace output of the issue.

 

James

[Helios4 Support]

The sdcard in my Helios4 got corrupted on a recent upgrade, and I'm a few versions behind so I decided to get the latest (Armbian 20.08), write it to the card and move stuff over as needed.

 

Unfortunately, I found that due to a combination of factors, that networking is totally bunged up due to a choice that doesn't make a lot of sense for something that is generally supposed to be a server in a static place.

 

I was trying to use NetworkManager to set a static IP, and went through a guide out there to do that since it's not something I do every day. I get to "nmcli con reload" to see if it will take the new settings, but no go. Fine, I'll reboot.

 

I found to my great surprise that the MAC address had changed. In the boot messages on the serial console was:

 

Warning: ethernet@70000 (eth1) using random MAC address - 0e:95:58:4b:71:2b
eth1: ethernet@70000

 

What!!!! 

 

So, for now, I've disabled NetworkManager and decided to go with /etc/network/interfaces. However, this will impact network monitoring. I feel like randomizing the MAC address is inappropriate for this application (though admittedly, not a bad idea for most boards that run armbian). Is there a setting in a file in /boot I can change to prevent randomization of the MAC address?

 

Thank you for your help.

[Helios4 Support]

8 hours ago, aprayoga said:

Hi,
you're right, the driver is not included, you'd need to compile the driver by yourself if you need ASAP.

I don't see any technical reason not to include the driver. After i test, I will enable it on Armbian kernel

Thank you for the info. I'll figure out how to compile it myself for now. I look forward to future updates including it.

[Helios4 Support]

I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.

 

One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.

 

I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?

 

If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?

[BPi Pro linux-jessie-root-next-bananapipro package held]

I was hoping I could find some information as to why linux-jessie-root-next-bananapipro was being held on my BPi Pro system. 

 

The kernel and u-boot packages have been upgraded. I've held back on updating linux-jessie-root-next-bananapipro because I'm concerned it would break something.

 

Is there some log file I should look at or some documentation somewhere? 

[dmesg output on BPi Pro with PMP]

I've got a BPi Pro with a PMP as a sort of backup box. 

 

It appears to be running find so far and I'm not running RAID of any sort on it as I've had issues with that an PMPs on other platforms. 

 

The question I have is dmesg is filling up with entries like this:

 

[66451.217935]  sdb: sdb1
[66752.272509]  sdb: sdb1
[66752.593223]  sdd: sdd1
[67964.907826]  sdc: sdc1
[67974.038562]  sdd: sdd1
[68595.107245]  sdb: sdb1
[69525.179964]  sdb: sdb1
[69835.958729]  sdd: sdd1
[70766.572499]  sdb: sdb1
[71076.828494]  sdb: sdb1
[71377.605195]  sdd: sdd1
[72298.301984]  sdb: sdb1
[73219.937015]  sdd: sdd1
[73637.287585]  sdb: sdb1
[73637.660971]  sdd: sdd1
[73840.037079]  sdb: sdb1
 

For any particular disk, they appear to go away once the partition is mounted, but I'm curious to know what the information is being attempted to be communicated and whether I should be concerned.

 

I'm currently running ARMBIAN Debian GNU/Linux 8 (jessie) 4.9.12-sunxi.

[Determine armbian version]

I'm running an OrangePi One.

 

Having installed Armbian a while ago and gone through all the updates, I was wondering if there is any way to determine what equivalent release my installations are at.

 

I noticed that 5.20 is out and some folks are talking about 5.21. I'm running Jessie.

 

Also, for me to use a more recent version of Debian, I'm guessing I would have to build the image myself? Is that due to shortcomings in the 4.x kernels on the H3 platform? I've done some digging and it seems like many (most) things are working right on the 4.x kernels?

 

Thank you

 

James

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

If you've one or more USB disks lying around please think about connecting it to your Orange Pi one after another and start "sudo armbianmonitor -d". There's no need to mount the disk, it must not even have a partition table or filesystem readable by Linux. It's only about "disk attached to USB port".

 

So, specifically USB -> SATA bridges with a SATA device attached. Not just any USB storage like flash.

 

Also I read "it must not even have a partition table or filesystem readable by Linux." to mean that it must be a blank disk with no partition table whatsoever.

[[WiP / Orange Pi One] Support for the upcoming Orange Pi One?]

I was hoping to test out Armbian, but I keep running into issues. Following the directions on the main page, I write the .raw to my sdcard and insert it into the OrangePi One. I'm using the Armbian_5.03_Orangepione_Debian_jessie_3.4.110.raw version. I got similar results with the 5.01 version.

 

I've got the serial console working, but I don't get any output after the U-Boot:

MKernel image @ 0x48000000 [ 0x000000 - 0x49a658 ]
Using machid 0x1029 from environment

Starting kernel ...

[sun8i_fixup]: From boot, get meminfo:
      Start:  0x40000000
      Size:   512MB
ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1
ion_reserve_common: ion reserve: [0x56000000, 0x60000000]!

Sometimes there output on HDMI, sometimes not. When I get output, there are often many error messages. Sometimes about mmcblk corruption. Really, too many to list here. It would be helpful for me to get that output on the serial port.

 

I feel like I'm missing something obvious.

 

James