New AC86U - Bad PEB, a problem?

[Dfects]

I've just been playing with my new AC86U, everything seems to be working okay but noticed in the logs it reports a bad physical erase block:

May  5 06:05:05 kernel: ubi0: good PEBs: 724, bad PEBs: 1, corrupted PEBs: 0

Earlier log entries on reboot have been fine.

Is this something to worry about?

 

[OzarkEdge]

I don't know! But I checked my 86U syslog... no bad PEBs here but I noticed this: PEBs reserved for bad PEB handling: 4.

So, maybe they expect a few bad PEBs... if so, maybe you are down to 3 in reserve.

OE

 

[Dfects]

I think there are two different chips or partitions... one has 64 peb's with 4 reserved for errors (ubi1) and the one I listed (ubi0) has 725 normally with 15 in reserve... mine being on 724/14 now.

 

[OzarkEdge]

I think there are two different chips or partitions... one has 64 peb's with 4 reserved for errors (ubi1) and the one I listed (ubi0) has 725 normally with 15 in reserve... mine being on 724/14 now.

I have no ubi0 entries here. h/w 1.5

OE

 

[Grisu]

I think there are two different chips or partitions... one has 64 peb's with 4 reserved for errors (ubi1) and the one I listed (ubi0) has 725 normally with 15 in reserve... mine being on 724/14 now.

only for reference my values:
Oct 7 23:24:27 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct 7 23:24:27 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Oct 7 23:24:27 kernel: ubi1: max/mean erase counter: 3/2, WL threshold: 4096, image sequence number: 1960956644
Oct 7 23:24:27 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4

Could not find ubi0 too.

 

[Dfects]

Interesting. Not sure if it only logs it on reboot. Searching the logs for "bad pebs:" I get:

May  5 06:05:05 kernel: ubi0: good PEBs: 724, bad PEBs: 1, corrupted PEBs: 0
May  5 06:05:05 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
May  5 06:05:05 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
May  5 06:05:11 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct  8 13:36:38 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct  8 13:36:41 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct  8 13:36:54 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0

These are all after clearing the log and rebooting.

 

[CrashXRu]

dmesg | grep -e "flash" -e "nand"

check bad block

 

[Grisu]

Interesting. Not sure if it only logs it on reboot. Searching the logs for "bad pebs:" I get:

May  5 06:05:05 kernel: ubi0: good PEBs: 724, bad PEBs: 1, corrupted PEBs: 0
May  5 06:05:05 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
May  5 06:05:05 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
May  5 06:05:11 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct  8 13:36:38 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct  8 13:36:41 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Oct  8 13:36:54 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0

These are all after clearing the log and rebooting.

seems to exist only on reboot, timestamp May 5th after I loaded Merlin 384_7.

May 5 07:05:06 kernel: ubi0: volume 0 ("rootfs_ubifs") re-sized from 566 to 706 LEBs
May 5 07:05:06 kernel: ubi0: attached mtd0 (name "rootfs", size 90 MiB)
May 5 07:05:06 kernel: ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
May 5 07:05:06 kernel: ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
May 5 07:05:06 kernel: ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
May 5 07:05:06 kernel: ubi0: good PEBs: 725, bad PEBs: 0, corrupted PEBs: 0
May 5 07:05:06 kernel: ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
May 5 07:05:06 kernel: ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
May 5 07:05:06 kernel: ubi0: available PEBs: 0, total reserved PEBs: 725, PEBs reserved for bad PEB handling: 15
May 5 07:05:06 kernel: ubi0: background thread "ubi_bgt0d" started, PID 60

 

[Grisu]

dmesg | grep -e "flash" -e "nand"

check bad block

get this red line with "dmesg" only:
[ERROR pktrunner] runnerUcast_inet6addr_event,202: Could not rdpa_ucast_ipv6_host_address_table_find

 

[Dfects]

I'll try that later too... pretty sure that flash chip has a bad block though on my router. From my understanding, bad blocks can happen during the manufacturing process and isn't a sign that the chip itself is going to fail sooner? Guessing most manufacturers have tolerances for this kind of thing.

If anyone can chime in and tell me if my understanding is correct or if I should be requesting a replacement i'd appreciate it

 

[Grisu]

same as a pixel failure on LCD-screens, long time there has been allowed to be some without return.

Thats why they calculated some spare, no need or reason for a return.

I only dont know the difference or what exactly meant with bad and corrupted (maybe caused by my bad English).