Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #84407

Bug#1076372: linux-image-6.11.5+debian+tj: Diagnostic steps

Cross-posted to 2 groups.

Show all headers | View raw

Package: linux-image-6.11.5+debian+tj
Followup-For: Bug #1076372
X-Debbugs-Cc: tj.iam.tj@proton.me

Following up from the kernel team discussion this evening that I only
caught the tail-end of I've reviewed this report and have the following
suggestions and observations.

It would be good to see complete-from-boot kernel logs for good/bad
results linked to which M2 slot each device is in.
That mobo (AsRock X600M-STX) has 3 M.2, 2 for SSDs (+1 for WiFi),
M2_1 Gen5x4 on front of PCB, and M2_2 Gen4x4 on rear.
AsRock also publish a qualifying storage device list and the Lexar
LNM790 appears to be on it

https://www.asrock.com/Nettop/AMD/DeskMini%20X600%20Series/index.asp#Storage

(and presumably implicitly requires most recent UEFI - there have
been several very recent updates).

https://www.asrock.com/Nettop/AMD/DeskMini%20X600%20Series/index.asp#BIOS

Also of use would be to know if the corruption occurs for locally
generated data - report states data is received from network so with
current knowledge the issue could be on the network side.
Also - with my forensics hat on - being shown the data expected vs
corrupted might give clues as to what type of cause it is. For example,
I've dealt with situations where a single register bit would flip
occasionally and the data stream would be scrambled until it flipped
once again and the data is unscrambled, or it could be bits/words being
lost entirely so when stored remaining data is at a different offset
to the original, but is still there.

Back to linux.debian.kernel | Previous | Next | Find similar | Unroll thread

Thread

Bug#1076372: linux-image-6.11.5+debian+tj: Diagnostic steps Tj <tj.iam.tj@proton.me> - 2024-10-30 22:50 +0100

csiph-web