linux-kernel - Re: Bug: After a 'warm' reboot the disk is missing (not detected by the bios) on a HP t640

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <AS1PR05MB939337F702FDD79AFDF18F56B69EA@AS1PR05MB9393.eurprd05.prod.outlook.com>
Date: Thu, 28 Dec 2023 12:39:45 +0000
From: Ben Mesman | Spark Narrowcasting <ben@...rknarrowcasting.nl>
To: Sean Christopherson <seanjc@...gle.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: Bug: After a 'warm' reboot the disk is missing (not detected by
 the bios) on a HP t640

> Please don't send private mails.  Kudos for using get_maintainer.pl, but a demerit
> for not Cc'ing the mailing lists :-)
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Definitely saving that in my URLs-cache. Might need it again in a few years :-)
(last time I needed it was about 10 years ago)

> > I recently started upgrading some of my remote managed thin-clients from a
> > 5.15.x kernel to a 6.1.x kernel. When rebooting with the new(er) kernel, the
> > HP t640 clients failed. The problem is that after the warm reboot, the BIOS
> > is unable to locate the internal storage (so it can't boot a valid OS).
> >
> > With some digging around I found that adding "reboot=p" will solve the
> > problem, but because the systems are remote managed, I am unable to add this
> > boot-parameter in any straightforward way.
[snip]
> I'm not familiar with this code (I'm not actually a maintainer/reviewer for this
> code, by default get_maintainer.pl Cc's people that have recently modified the
> file in question), but this looks like a hack to workaround a bug elsewhere.
> 
> All of these quirks are obviously workarounds for some kind of bug, but AFAICT
> the quirks are to workaround hardware or firmware bugs, not kernel bugs.  Since
> 5.15.x kernels worked, odds are good a bug was introduced between 5.15 and 6.1,
> i.e. that this is fudging around a kernel bug that can and should be fixed.
> 
> Are you able to bisect the kernel between 6.1 and 5.15 to try and pinpoint an
> exact commit that introduced the problem?

That took a few days, but resulted in the following:

4be33cf187036744b4ed84824e7157cfc09c6f4c is the first bad commit
commit 4be33cf187036744b4ed84824e7157cfc09c6f4c
Author: Fred Ai <fred.ai@...hubtech.com>
Date:   Mon Dec 20 20:09:40 2021 -0800

    mmc: sdhci-pci-o2micro: Improve card input timing at SDR104/HS200 mode
    
    Card input timing is margin, need to adjust the hold timing of card input.
    
    Signed-off-by: Fred Ai <fred.ai@...hubtech.com>
    Link: https://lore.kernel.org/r/20211221040940.484-1-fred.ai@bayhubtech.com
    Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>

 drivers/mmc/host/sdhci-pci-o2micro.c | 57 ++++++++++++++++++++++++++++++------
 1 file changed, 48 insertions(+), 9 deletions(-)

I'm not sure how this code impacts this device, but it does contain a "HS200 MMC card":
$ dmesg | grep mmc
[    1.044708] mmc0: emmc 1.8v flag is set, force 1.8v signaling voltage
[    1.044937] mmc0: SDHCI controller on PCI [0000:01:00.0] using ADMA
[    2.120632] mmc0: new HS200 MMC card at address 0001
[    2.122912] mmcblk0: mmc0:0001 hA8aP> 14.7 GiB 
[    2.124810]  mmcblk0: p1 p2 p3

I can provide more info on the hardware, which is also available in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056056

-- 
Kind regards,
Ben Mesman
ben@...rknarrowcasting.nl