Helios64 - Armbian 23.08 Bookworm issues (solved)

[prahal]

2 hours ago, BipBip1981 said:

Since few days i note a problem with SATA on my Helios64.

 

@BipBip1981

Could you grep for "ata", or check the logs for ata errors and paste them? Or tell if there are no other messages with ata in the logs?

Don't you have any "hard resetting link" messages in the kernel logs?

 

On my side I once had drives that were not detected extracting the drive from the SATA power and data socket a few times (and cleaning them with isopropanol once, might have helped) did it. I believe my socket were oxidized though that is a wild guess. Issue gone either way.

 

[BipBip1981]

Hi,

 

Same with 28.11-trunk build myself and 6.6.56 kernel

Below grep SATA and grep ata:

 

root@helios64:~# dmesg | grep SATA
[    3.137429] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode
[    3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74
[    3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75
[    3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76
[    3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77
[    3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78
[   10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
root@helios64:~# dmesg | grep ata
[    0.000000] Memory: 3787452K/4061184K available (16960K kernel code, 2318K rwdata, 5248K rodata, 4736K init, 604K bss, 142660K reserved, 131072K cma-reserved)
[    0.018184] CPU features: detected: ARM errata 1165522, 1319367, or 1530923
[    0.719520] libata version 3.00 loaded.
[    3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74
[    3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75
[    3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76
[    3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77
[    3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78
[    3.163337] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 82,32 bit host data width,256 deep fifo
[    8.508139] ata1: link is slow to respond, please be patient (ready=-19)
[   10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   10.610022] ata1.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133
[   10.620898] ata1.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   10.624658] ata1.00: Features: NCQ-sndrcv NCQ-prio
[   10.639786] ata1.00: configured for UDMA/133
[   11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   11.117876] ata2.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133
[   11.128615] ata2.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   11.132356] ata2.00: Features: NCQ-sndrcv NCQ-prio
[   11.148021] ata2.00: configured for UDMA/133
[   11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   11.630146] ata3.00: ATA-9: TS256GSSD370S, O1225G, max UDMA/133
[   11.630849] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 32), AA
[   11.632376] ata3.00: Features: Dev-Sleep
[   11.635170] ata3.00: configured for UDMA/133
[   12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.118227] ata4.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133
[   12.128937] ata4.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   12.132823] ata4.00: Features: NCQ-sndrcv NCQ-prio
[   12.148357] ata4.00: configured for UDMA/133
[   12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   12.626073] ata5.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133
[   12.636772] ata5.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   12.640617] ata5.00: Features: NCQ-sndrcv NCQ-prio
[   12.656091] ata5.00: configured for UDMA/133
[   52.828386] EXT4-fs (dm-1): mounted filesystem 58534626-3f89-40db-9b0e-9519a2805962 ro with writeback data mode. Quota mode: none.
[   56.637970] EXT4-fs (mmcblk0p1): mounted filesystem ba516afd-4114-4179-8bcf-3d0f63b058fe r/w with ordered data mode. Quota mode: none.
[   64.262140] EXT4-fs (dm-2): mounted filesystem cc702057-ff5f-4b6f-ad29-4f5d5d96216e r/w with ordered data mode. Quota mode: none.
[   64.341677] systemd[1]: Starting plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data...
[   64.358217] systemd[1]: Finished plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data.
[   66.316142] systemd-journald[1673]: Data hash table of /var/log/journal/21a29cba476e44048a808d9a655190f3/system.journal has a fill level at 88.2 (4015 of 4551 items, 2621440 file size, 652 bytes per hash table item), suggesting rotation.

Edited October 17 by BipBip1981

[BipBip1981]

Hi everybody,

 

For information Prahal dtb patch file is not for me the problem because my  problem is only on ata1 after cold boot, never after reboot command.

I think hardware problem like harddisk, cables or mainboard... i continu to search.

 

Have good day

Edited October 18 by BipBip1981

[prahal]

On 10/17/2024 at 7:20 AM, BipBip1981 said:

[    8.508139] ata1: link is slow to respond, please be patient (ready=-19)
[   10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   10.610022] ata1.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133
[   10.620898] ata1.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[   10.624658] ata1.00: Features: NCQ-sndrcv NCQ-prio
[   10.639786] ata1.00: configured for UDMA/133

 

-19 in ata1: link is slow to respond, please be patient (ready=-19) is ENODEV in https://github.com/torvalds/linux/blob/6efbea77b390604a7be7364583e19cd2d6a1291b/drivers/ata/libata-core.c#L3594

but ready is resetted to 0 else the function would exit before this message https://github.com/torvalds/linux/blob/6efbea77b390604a7be7364583e19cd2d6a1291b/drivers/ata/libata-core.c#L3577

 

As I told, I had bad contact on my sata ports, try removing and inserting the HDD in the sata socket a few times. That might remove things on the contacts. On my side I also clean the sata sockets with isopropanol when I bought some (I use 99,5% isopropanol but I don't know if less concentrated is OK).

You might paste the complete log around the ata1 lines in the kernel log.

If the issue is always with the same sata port, you could try swapping the HDD to see if the issue follows the HDD or if this is the link or port.

But indeed I guess the issue is hardware.

 

[BipBip1981]

Hi,

 

I swap ata1 and ata5, problem stay on ata1, i look cable and socket on ata1

 

Keep in touch

[BipBip1981]

Hi, few days ago, i disconnect and reconnect all connectors on ATA1 line, it's seem to become Okok 😉 

Edited October 23 by BipBip1981

[prahal]

On 10/22/2024 at 6:22 PM, BipBip1981 said:

Hi, few days ago, i disconnect and reconnect all connectors on ATA1 line, it's seem to become Okok 😉 

 

 

Awesome. And thanks a lot for the feedback.

Could you explain which side you disconnect/reconnected? The HDD side only? Or on the motherboard too?

I believe HDD side is enough, just want a clue if that could be wrong.

 

I believe the connector were not clean, or a bit oxidized out of fabric (maybe connectors were stored in an area with an aggressive climate... I am no expert, but I clue that with the parts being serviced during Covid mess, some unusual process happened). It is not like the hardware is bad, only "dirty".

Here I had bad lost connectivity to an HDD, extracting and inserting it a few times back seemed to have cleaned the connectors (I also put isopropanol on them, but I don't remind if I brushed them at that time).

 

[BipBip1981]

Hi,

For feedback, i disconnect from SATA connector by unrack/rack harddisk and i disconnect and reconnect plug on mainboard side.

Have a good day.

[drs]

Hey everyone,

 

I just updated my helios64, from bullseye to bookworm and the armbian packages from 23.02.2 to 24.11.1

 

After rebooting I couldn't reach my helios64 anymore via network, i.e. dropbear within initramfs. So I figured that nic device names may have changed (and so the IP= setting within initramfs.conf wouldn't work anymore)  and connected via serial console with picocom.

 

But unfortunately the serial console output just ends every reboot with these lines (full serial console output as attachment):

[    7.169342] r8152 2-1.4:1.0 enx646266d0034d: renamed from eth0
[    7.236959] device-mapper: uevent: version 1.0.3
[    7.237900] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com
[    7.254918] NET: Registered PF_ALG protocol family
[    7.323029] zram: Added device: zram0
[    7.646108] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[    7.834575] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    7.835330] sd 1:0:0:0: Attached scsi generic sg1 type 0
[    7.836020] sd 2:0:0:0: Attached scsi generic sg2 type 0
[    7.836914] sd 3:0:0:0: Attached scsi generic sg3 type 0
[    7.837806] sd 4:0:0:0: Attached scsi generic sg4 type 0
[    7.969567] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work] Not connected. Disabling cdn
[    8.043475] async_tx: api initialized (async)

 

Does anyone have any idea why the serial console output just ends and any idea what to do?

 

bookworm_serial_console.txt

[prahal]

On 12/16/2024 at 12:05 AM, drs said:

After rebooting I couldn't reach my helios64 anymore via network, i.e. dropbear within initramfs. So I figured that nic device names may have changed (and so the IP= setting within initramfs.conf wouldn't work anymore)  and connected via serial console with picocom.

 

But unfortunately the serial console output just ends every reboot with these lines (full serial console output as attachment):

I don't know why you don't get a shell on the serial console.

But we can get the network issue worked around.

There are two ethernet interfaces: end0 the 1Gbls and the second in your cawe enx646266d0034d the 2.5Gbps ethernet one.

The enx646266d0034d is MAC hw address 64:62:66:d0:03:4d (I've the mac addr is in the interface name).  The end0 should be the same minus one is  64:62:66:d0:03:4c.

 

 

What are the status of the LEDs on the front panel (blinking/solid)?

Edited Wednesday at 10:15 PM by prahal
request details