packages
packages copied to clipboard
getsolus
ext4_find_entry 1662 (T10555)
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
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.
@16CharactersWork Is this still an issue for you? If not, please close as fixed.
