Maintenanace Mode entry is come up randomly

Hello,
Our custom board and TX2 NX module are entered maintenance mode randomly.
These are bootlog on “normal boot” and “maintenance mode entry boot”.
20220414_normal_booting_console_log.txt (21.6 KB)
20220414_maintenance_mode_issue.txt (36.7 KB)
(*there is no real monitor and Xserver is removed. EDID error can skip.)

I think if the file system has damaged, system should be entered to maintenance mode at everytime.
But it happens randomly.
I can found only one different thing about zram.
Anyother filesystems are fine and mounted.
I’m not sure zram issue is result or cause.
20220414_normal_fdisk.txt (8.1 KB)
20220414_maintenance_fdisk_mount_info.txt (9.1 KB)

And now, this log looks like issue point.
Is this log mandatory ?

[    3.202728] using random self ethernet address
[    3.207247] using random host ethernet address
[    3.424258] using random self ethernet address
[    3.432664] using random host ethernet address

Hi,

Just want to clarify, your issue is that your see “Press Enter for maintenance”, but your board still be able to work?

Could you remove “quiet” in extlinux.conf and dump the log again?

Crone service and our daemon (rc.local) doesn’t start.
But these are started by command on the terminal in maintenance mode.

If directly moving the same module to devkit, would this issue be reproduced?

Have you tried to reflash the board already?

I would check it.

Dear @WayneWWW

These are bootlog on normal boot with custom board and devkit.
20220415_bootlog_remove_quiet.txt (21.6 KB)
20220415_devkit_bootlog_remove_quiet.txt (21.4 KB)

We are testing 4 set of our custom board, those have same issue.
And I will upload boot log without ‘quiet’, when maintenance mode has come.

Hi,

You didn’t reply my question. I mean “directly move module from devkit to custom board”. Did you do that test?

Sorry, my comment was unkind.
On the last comment, dev kit means issued module and dev kit baord.
Both of boot logs are issued module, just carrier boards were different.
Surely, they are using same bsp without flashing.

And this is maintenance mode entry boot dmesg on the custom board.
20220419_maintenance_mode_dmesg_without_quite.txt (52.0 KB)

And this normal boot dmesg on the custom board.
20220415_dmesg_remove_quiet.txt (54.4 KB)

Hi,

Sorry that I still don’t understand your comment. Let me make it easier to understand

  1. Is this issue only happened to your carrier board or even NV devkit can hit this issue?

  2. I see even in your “maintenance mode entry boot dmesg on the custom board”, you can still boot into the console and operate, and I don’t see any maintenance mode in your log. Are you sure this is the correct log?

First, when i asked it, it just happened on custom board randomly.
So, I shared it.
dmesg : Issued Module + Custom Board + normal boot entry + with quite
dmesg : Issued Module + Custom Board + maintenance mode entry + with quite

Now, we are trying to test to removed ‘quite’ from command line for your asking.
last comment I shared as follows.
dmesg : Issued Module + Custom Board + maintenance mode entry + without quite
dmesg : Issued Module + Custom Board + normal boot + entry + without quite

It tooks some time to happen maintenance mode on the custom board.
So, We need another sometime for Dev Kit board.

  1. But the log you just shared didn’t have any “maintenance mode” log inside. Are you sure this is correct log?

  2. Can you firstly clarify whether this is related to custom board before you use the term “issued module”? There is no evidence to tell whether this is module or carrier board issue.

  1. But the log you just shared didn’t have any “maintenance mode” log inside. Are you sure this is correct log?

It just include dmesg.
When i saw it, there is no timestamp on maintenance mode line on boot log.
May be, it doesn’t show on the dmesg.
You can see the difference what I commented about zram.

  1. Can you firstly clarify whether this is related to custom board before you use the term “issued module”? There is no evidence to tell whether this is module or carrier board issue.
    I think this is expression problem.
    I don’t speak english not so well.
    I don’t mean that module has problem.
    I follow your expression.
    It just happend on the custom board.
    The module just directly moved to dev kit board.

Could you give me any comment about this line?

[    3.202728] using random self ethernet address
[    3.207247] using random host ethernet address
[    3.424258] using random self ethernet address
[    3.432664] using random host ethernet address

I’m wondering it is important or not.

No, that is not important.

1 Like

We don’t have much case about this error.

I just checked, only one customer telling us he has this error “Press Enter for maintenance” on his custom board and it seems has some connection with PCIe-SATA bridge on their board. Do you have such devices on your board too?

I just notice that it seems you didn’t know what is the purpose of removing quiet…

If you want to share useful info after removing quiet, then share the uart log…

Also, what is the method you used to “remove quiet”? I read you log again and notice you didn’t disable quiet at all.

Actually, I guided the engineer who the charge of it and he did.
I said remove quite on the extlinux.conf.

And could you check it?
this is the boot log.
20220419_maintenance_진입후_partlabel.txt (27.6 KB)

Yes, you are right.
There is no difference ‘with quite’ version and ‘without quite’ version.
I’m sorry, I’ll check it and right version will update.