[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads



On 3/8/22 04:09, Diederik de Haas wrote:
> Hi Damien,
> 
> On Sunday, 6 March 2022 23:26:03 CET Diederik de Haas wrote:
>> Upstream commit 68dbbe7d5b4fde736d104cbbc9a2fce875562012 [1]
>> seems potentially relevant (included in 5.16-rc1), but given ...
>>
>> On Saturday, 5 March 2022 17:59:50 CET Petra R.-P. wrote:
>>> The "Read log 0x00 page 0x00 failed" line has disappeared,
>>
>> ... I don't know if building a new kernel with that commit reverted
>> would be enough.
>>
>> From the above mentioned commit message it very much seems the logic
>> wrt slow drives was changed, but how exactly is 'above my pay grade'.
>> The new timeout (15s) seems to work for SATA 6.0 Gbps links, but it appears
>> the T41 uses PATA which I think is (quite a bit?) slower then that.
> 
> In https://bugs.debian.org/1006149 we have 2 users where the 5.16 kernel fails 
> to boot, while the 5.15 kernel succeeded.
> In the bug report there are a number of dmesg outputs posted which contain 
> time gaps of ~ 20, 100 and even 160 seconds; i.e. more then 15 seconds.
> The commit message mentions 'SATA link up 6.0 Gbps', but these users hava PATA 
> links for their HDD. IIUC that means a max speed of ~600MB/s vs ~133MB/s.
> 
> As the author of the above mentioned commit, could you tell us whether it 
> *could* be that your commit is causing the boot failures? Or is it completely 
> irrelevant for this problem?

The commit in question only increases the timeout for read log commands.
So I do not think it is the root cause of the problem.

In the bug report, I did not see a dmesg output for a failed boot. But I
guess it is because the user cannot capture it.

Could you have a look at this bug report for Fedora:

https://bugzilla.kernel.org/show_bug.cgi?id=215519

This Debian case does sound similar. The problem is fixed with commit:

fda17afc6166 ("ata: libata-core: Fix ata_dev_config_cpr()")

which is included in kernel 5.16.9. Could the users try that kernel
version to see if that fixes the issue ?

-- 
Damien Le Moal
Western Digital Research


Reply to: