Given AX6000 and AX88U Pro are virtually identical, do they accept the same firmware?

[RMerlin]

From Syslog:
May 5 01:05:16 kernel: ubi0 warning: ubi_calculate_reserved: number of bad PEBs (441) is above the expected limit (40), not reserving any PEBs for bad PEB handling, will use available PEBs (if any)

Good find. That does seem awfully high indeed, and I would suspect failing flash. My GT-AXE16000 has no bad PEB (and it uses the same NAND size as the GT-AX6000).

May  5 01:05:24 kernel: ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
May  5 01:05:24 kernel: ubi0: good PEBs: 2016, bad PEBs: 0, corrupted PEBs: 0
May  5 01:05:24 kernel: ubi0: available PEBs: 293, total reserved PEBs: 1723, PEBs reserved for bad PEB handling: 40

I would RMA the router.

Only weird thing, there's not really an error stating that the upgrade failed. Only this warning.

You won't see it because the system log gets stopped before the new firmware gets written. The only way to get any debug output during the process is through a serial console.

 

[Hypothosis]

You broke it?
And you're returning it?
Not be making many friends around here then.

not quite, I bought it refurbished, so someone might have messed with it, or just got frustrated because stuff didn't work. it auto updated to a more recent stock version. then failed to upgrade further, in fact, nothing I did had any effect. the only dangerous operation i tried was hnd-write (after reading rmerlins comment that it does *some* checks)

so no, I'm returning a defective router that was sent to me with 25% of all NAND bad. I claim moral high ground ;-)

 

[Hypothosis]

Good find. That does seem awfully high indeed, and I would suspect failing flash. My GT-AXE16000 has no bad PEB (and it uses the same NAND size as the GT-AX6000).

May  5 01:05:24 kernel: ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
May  5 01:05:24 kernel: ubi0: good PEBs: 2016, bad PEBs: 0, corrupted PEBs: 0
May  5 01:05:24 kernel: ubi0: available PEBs: 293, total reserved PEBs: 1723, PEBs reserved for bad PEB handling: 40

I would RMA the router.


You won't see it because the system log gets stopped before the new firmware gets written. The only way to get any debug output during the process is through a serial console.

ok thx for confirming 25% of all NAND does sound quite high.

the fact that the flashing process doesn't resize partitions within certain limits automatically despite plenty of space being available (remaining 200M should fit everything (2x65M for images + some operational data)), is telling me that normally you don't want more than 1-3 bad blocks. I don't think i want to research how to resize the partitions in an squashfs with pkgtb

 

[Hypothosis]

On a GT-AX6000

ok so how do I get this wonderful output? custom script?

I used nanddump and every dump said 0 bb. your output seems to do that and then some.
I dind't dare to use nandtest, as i don't know whether it will brick, even with the "-k" option
some people downloaded mtd_check and compiled it...

what's the easiest tool here to use?

 

[Hypothosis]

so for documentation purposes i ran some nanddumps...
mtd0 and 2 have each 441 bad blocks - that must be a production issue?
then mtd4,5,6 have no bad blocks, but say mtd_is_bad - so those are fresh bad blocks i guess?
as mtd4 and 5 don't have any eraseblocks, they're pretty much broken.

I deleted irrelevant info from the commands:

nanddump -f nanddup /dev/mtd0
Number of bad blocks: 441
Block size 131072, page size 2048, OOB size 108

nanddump -f nanddup /dev/mtd2
Number of bad blocks: 441
Block size 131072, page size 2048, OOB size 108

nanddump -f nanddup /dev/mtd4
libmtd: error!: bad eraseblock number 0, mtd4 has 0 eraseblocks
nanddump: error!: libmtd: mtd_is_bad

nanddump -f nanddup /dev/mtd5
libmtd: error!: bad eraseblock number 0, mtd5 has 0 eraseblocks

nanddump -f nanddup /dev/mtd6
libmtd: error!: bad eraseblock number 83, mtd6 has 83 eraseblocks

i still don't understand why the problem doesn't fix itself, isn't UBI supposed to implement wear levelling and bad blocks handling, or is the rate/amount of failure just too high?

 

[Hypothosis]

For the still curious:

I'm running some cycles of
nanddump -f file /dev/mtdXX etc
nandtest -k -m -p 4 /dev/mtdXX

not sure i'm making it worse, or just exposing how bad it is. I think the latter.

nanddump -f dump /dev/mtd0
ECC failed: 178
ECC corrected: 12
Number of bad blocks: 441
Number of bbt blocks: 0

Number of bad blocks didn't change after 6 passes, but ECC was 0 before. Now seems to go up continuously. I think it was just the default test counter being 0? I'm assuming it's testing the bad ones and those are the majority of the failing ones, as the number of bad blocks has not increased.

also just checked my AX and AXE, 0 bad blocks according to nanddump.

So thanks all, this soldier is down :-/

 

[Tech9]

This is not good. This router is relatively new model. Hopefully isolated case. It's popular around.

 

[RMerlin]

i still don't understand why the problem doesn't fix itself, isn't UBI supposed to implement wear levelling and bad blocks handling, or is the rate/amount of failure just too high?

The NAND driver handles bad block mapping, however there isn't that many spare blocks available for remapping.