ext4_find_entry 1662
Open, LowPublic
Actions

Assigned To

None

Authored By

	16CharactersWork
	Jun 13 2023, 2:05 PM

Description

Some time ago, my computer kept crashing in several states. Only things from ram would load, and then it moves on to displaying an ext4_find_entry 1662 message. I've checked for bad sectors and bad blocks on my drive, and every time the computer passes those test. I've ran a smart tools test, and had my computer pass the short and long version of those test. Performed fsck -a from a live distro (system rescue) to see if that would fix the issue. Check my ram with memorytools + and got a passed message as well. Looked at the Lenovo diagnostics and checked everything with an extensive search as well, and everything once again passed.

Asked the matrix and forums solus community about possible solutions, and they have suggested I post my problem to this area. At the moment, (thanks to Tracey C) the stack overflow message about this becomes relevant where another user faces this issue, but I am not sure if this applies to my drive. The real bug.

Picture 1 (This is how it looks when I think it loads from ram. Nothing new may be opened, and anything from ram will load fine.)
{F10854221}

Picture 2 & 3 (Usually it will restart and just go straight to this message, or it goes through to picture 1 and then end up at this screen)
{F10854224} {F10854226}

Picture 4 (My ram passing)
{F10854232}

Log Files
https://bpa.st/LPX7Y

Computer Specs
https://bpa.st/P3J2E

Hard Drive
ATA INTEL SSDSCKKF25

Event Timeline

16CharactersWork created this task.Jun 13 2023, 2:05 PM

Herald added a project: Lacks Project. · View Herald TranscriptJun 13 2023, 2:05 PM

TClark77 edited projects, added Bug; removed Lacks Project.Jun 13 2023, 2:22 PM

16CharactersWork added a project: Hardware.Jun 13 2023, 2:22 PM

Thanks for the report! Your log files only seems to include /var/log/Xorg.0.log, can you upload the output of dmesg?

Have you tried booting the system with the nvme_core.default_ps_max_latency_us=0 kernel parameter to disable APST?

dmesg
https://bpa.st/GM5B2

Have you tried booting the system with the nvme_core.default_ps_max_latency_us=0 kernel parameter to disable APST?

Nope, will try to do so, and see if it does anything different.

I might be misreading it, but your dmesg output doesn't seem to actually show the issue?

Also: it looks like your SSD is SATA, not NVMe, so I think the linked StackOverflow comment might not apply (but try the cmdline option just to be sure). Might still be a similar issue though: can you give the output of grep . /sys/class/scsi_host/host*/link_power_management_policy?

01:43:44 sol@sjit:~ 
      ▶  $ grep . /sys/class/scsi_host/host*/link_power_management_policy
/sys/class/scsi_host/host0/link_power_management_policy:med_power_with_dipm
/sys/class/scsi_host/host1/link_power_management_policy:med_power_with_dipm

Yeah, that's a SATA-600 SSD.

I don't suppose you have checked whether there's a newer firmware version available for the disk?

I once had a disk that flat out _refused_ to write to a particular sector. It was not until I manually zeroed it out that the drive firmware got its shit together and stopped flaking out. After that, there were no issues and no record of wear-levelling remapping of sectors being enabled.

EDIT: And then there's the old "physically remove the disk from the laptop, clean both sides of the SATA interface, re-insert it" schtick. If you're running into controller/signal-related hardware errors, there's not much you can do from the software side really.

So if you can extract any important data you have on the disk and attempt the above, that might be worth a shot?

Well at the moment it is not so bad where it becomes unusable, but weirdly every once in a while it starts doing this.

In T10555#201776, @16CharactersWork wrote:

Well at the moment it is not so bad where it becomes unusable, but weirdly every once in a while it starts doing this.

Triaging as "Low" priority per comment above.

ext4_find_entry 1662Open, LowPublicActions

Description

Event Timeline

ext4_find_entry 1662
Open, LowPublic
Actions