ERROR: cannot probe watchdog (unsupported)

[Root Mailer]

Hi,

I'm using the Debian Bookworm Package efibootguard (0.13-2+deb12u1) on a Tiger Lake platform (i7-1185G7E). The watchdog is set to 60 seconds in BIOS/UEFI. 

I set the watchdog to 30 seconds via

bg_setenv --watchdog=30

but ebg says

ERROR: cannot probe watchdog (unsupported)

at boot. Any hints what I'm doing wrong here?

Best regards

[Jan Kiszka]

Probably nothing, we may just miss the your platform's device ID in our
supported list - unless there is an option to enable WDAT support in the
firmware of you platform.

If not: Which watchdog is Linux normally using? iTCO? If so, please
share lspci -nn, at least for the "LPC Controller".

Jan

--
Siemens AG, Technology
Linux Expert Center

[Root Mailer]

Hi Jan,

here the "lspci -nn" output, unfortunately only as a picture:

I guess it's the SMBus controller. Apparently there are multiple PCI IDs for Tiger Lake. Currently you support Tiger Lake H [1] and I have Tiger Lake LP [2].

Best regards

[1] https://linux-hardware.org/?view=search&vendorid=8086&deviceid=43a3#list

[2] https://linux-hardware.org/?view=search&vendorid=8086&deviceid=a0a3#list

[Root Mailer]

And yes, Linux uses iTCO.

[Jan Kiszka]

On 02.11.23 11:06, Root Mailer wrote:
> Hi Jan,
>
> here the "lspci -nn" output, unfortunately only as a picture:
>

> Screenshot from 2023-11-02 11-02-22.png
>
> I guess it's the SMBus controller. Apparently there are multiple PCI IDs
> for Tiger Lake. Currently you support Tiger Lake H [1] and I have Tiger
> Lake LP [2].
>

Then, does this work for you?

diff --git a/drivers/watchdog/itco.c b/drivers/watchdog/itco.c
index 037c203..a186075 100644
--- a/drivers/watchdog/itco.c
+++ b/drivers/watchdog/itco.c
@@ -39,7 +39,8 @@ enum iTCO_chipsets {
ITCO_INTEL_LPC_LP,
ITCO_INTEL_WBG,
ITCO_INTEL_EHL,
- ITCO_INTEL_TLH,
+ ITCO_INTEL_TL_H,
+ ITCO_INTEL_TL_LP,
};

enum iTCO_versions {
@@ -157,12 +158,18 @@ static const iTCO_info iTCO_chipset_info[] = {
.pci_id = 0x4b23,
.itco_version = ITCO_V6,
},
- [ITCO_INTEL_TLH] =
+ [ITCO_INTEL_TL_H] =
{
.name = L"Tiger Lake-H",
.pci_id = 0x43a3,
.itco_version = ITCO_V6,
},
+ [ITCO_INTEL_TL_LP] =
+ {
+ .name = L"Tiger Lake-LP",
+ .pci_id = 0xa0a3,
+ .itco_version = ITCO_V6,
+ },
};

static BOOLEAN itco_supported(UINT16 pci_device_id, UINT8 *index)

[Root Mailer]

Thanks, will report next week.

[Root Mailer]

Watchdog is now (allegedly) supported, thanks for that. Unfortunately, it does not work as expected.

We set watchdog timeout to 30 seconds via "bg_setenv --part=0/1 --watchdog=30". Looks good:

We then manipulated the bzImage and the part where bg_gen_unified_kernel checks for a valid bzImage to simulate a non-working kernel here:

https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112

But the system does not reboot, it just hangs after the last line EFI stub: etc. Any ideas what's missing?

[Jan Kiszka]

On 08.11.23 14:51, Root Mailer wrote:
> Watchdog is now (allegedly) supported, thanks for that. Unfortunately,
> it does not work as expected.
>
> We set watchdog timeout to 30 seconds via "bg_setenv --part=0/1
> --watchdog=30". Looks good:
>

> Screenshot from 2023-11-08 10-02-55.png
>
> We then manipulated the bzImage and the part where bg_gen_unified_kernel
> checks for a valid bzImage to simulate a non-working kernel here:
>
> https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112
>
> But the system does not reboot, it just hangs after the last line EFI
> stub: etc. Any ideas what's missing?
>

If you start the watchdog from Linux and let it expire there, will the
machine reboot in that case? If no, then we have a hardware or firmware
issue. If yes, then we could look for missing bits in the Linux code.

[Root Mailer]

Yes in Linux it seems to work. We tested this by following the guide in [1]. When we cat to the /dev/watchdog0 device the system reboots after 30 seconds.

[1] https://www.thomas-krenn.com/de/wiki/Watchdog#Testen_der_Watchdog_Funktion

[Jan Kiszka]

On 09.11.23 15:55, Root Mailer wrote:
> Yes in Linux it seems to work. We tested this by following the guide in
> [1]. When we cat to the /dev/watchdog0 device the system reboots after
> 30 seconds.
>
> [1]
> https://www.thomas-krenn.com/de/wiki/Watchdog#Testen_der_Watchdog_Funktion
>

Then something is wrong with what the EBG driver does, possibly around
clearing the no-reboot flag. Someone near to a hardware would have to
sit down and compare, e.g. if EBG is using the same addresses for that
flag change as Linux does.

Jan

> On Thursday, November 9, 2023 at 2:19:31 PM UTC+1 Jan Kiszka wrote:
>
> On 08.11.23 14:51, Root Mailer wrote:
> > Watchdog is now (allegedly) supported, thanks for that.
> Unfortunately,
> > it does not work as expected.
> >
> > We set watchdog timeout to 30 seconds via "bg_setenv --part=0/1
> > --watchdog=30". Looks good:
> >
> > Screenshot from 2023-11-08 10-02-55.png
> >
> > We then manipulated the bzImage and the part where
> bg_gen_unified_kernel
> > checks for a valid bzImage to simulate a non-working kernel here:
> >
> >

> https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112 <https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112>

> >
> > But the system does not reboot, it just hangs after the last line EFI
> > stub: etc. Any ideas what's missing?
> >
>
> If you start the watchdog from Linux and let it expire there, will the
> machine reboot in that case? If no, then we have a hardware or firmware
> issue. If yes, then we could look for missing bits in the Linux code.
>
> Jan
>
> --
> Siemens AG, Technology
> Linux Expert Center
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/efibootguard-dev/b273b8d6-d84e-4709-8915-860113531e12n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/b273b8d6-d84e-4709-8915-860113531e12n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Root Mailer]

You mean we need a

.pmc_no_reboot_mask = (1 << 2),

here for ITCO_V6:

https://github.com/siemens/efibootguard/blob/master/drivers/watchdog/itco.c#L107

as in the kernel here:

https://elixir.bootlin.com/linux/v6.7-rc1/source/drivers/watchdog/iTCO_wdt.c#L165

[Root Mailer]

Have ITCO_V6 watchdogs already been tested successfully with ebg?

[Jan Kiszka]

On 14.11.23 10:25, Root Mailer wrote:
> Have ITCO_V6 watchdogs already been tested successfully with ebg?
>

On two of our IPCs at least, one Elkhart Lake, one Tiger Lake based.

> On Monday, November 13, 2023 at 11:13:06 PM UTC+1 Root Mailer wrote:
>
> You mean we need a
>
> .pmc_no_reboot_mask = (1 << 2),
>
> here for ITCO_V6:
>

> https://github.com/siemens/efibootguard/blob/master/drivers/watchdog/itco.c#L107 <https://github.com/siemens/efibootguard/blob/master/drivers/watchdog/itco.c#L107>
>

The problem may indeed be that we are hard-coding tco_base here. That's
why I suggested to compare register addresses that both drivers use on
the device.

Jan

> as in the kernel here:
>

> https://elixir.bootlin.com/linux/v6.7-rc1/source/drivers/watchdog/iTCO_wdt.c#L165 <https://elixir.bootlin.com/linux/v6.7-rc1/source/drivers/watchdog/iTCO_wdt.c#L165>

>
> On Friday, November 10, 2023 at 7:57:55 PM UTC+1 Jan Kiszka wrote:
>
> On 09.11.23 15:55, Root Mailer wrote:
> > Yes in Linux it seems to work. We tested this by following the
> guide in
> > [1]. When we cat to the /dev/watchdog0 device the system
> reboots after
> > 30 seconds.
> >
> > [1]
> >

> https://www.thomas-krenn.com/de/wiki/Watchdog#Testen_der_Watchdog_Funktion <https://www.thomas-krenn.com/de/wiki/Watchdog#Testen_der_Watchdog_Funktion>

> >
>
> Then something is wrong with what the EBG driver does, possibly
> around
> clearing the no-reboot flag. Someone near to a hardware would
> have to
> sit down and compare, e.g. if EBG is using the same addresses
> for that
> flag change as Linux does.
>
> Jan
>
> > On Thursday, November 9, 2023 at 2:19:31 PM UTC+1 Jan Kiszka
> wrote:
> >
> > On 08.11.23 14:51, Root Mailer wrote:
> > > Watchdog is now (allegedly) supported, thanks for that.
> > Unfortunately,
> > > it does not work as expected.
> > >
> > > We set watchdog timeout to 30 seconds via "bg_setenv --part=0/1
> > > --watchdog=30". Looks good:
> > >
> > > Screenshot from 2023-11-08 10-02-55.png
> > >
> > > We then manipulated the bzImage and the part where
> > bg_gen_unified_kernel
> > > checks for a valid bzImage to simulate a non-working kernel
> here:
> > >
> > >
> >

> https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112 <https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112> <https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112 <https://github.com/siemens/efibootguard/blob/master/tools/bg_gen_unified_kernel#L112>>

> > >
> > > But the system does not reboot, it just hangs after the last
> line EFI
> > > stub: etc. Any ideas what's missing?
> > >
> >
> > If you start the watchdog from Linux and let it expire there,
> will the
> > machine reboot in that case? If no, then we have a hardware or
> firmware
> > issue. If yes, then we could look for missing bits in the
> Linux code.
> >
> > Jan
> >
> > --
> > Siemens AG, Technology
> > Linux Expert Center
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "EFI Boot Guard" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to efibootguard-d...@googlegroups.com
> > <mailto:efibootguard-d...@googlegroups.com>.
> > To view this discussion on the web visit
> >

> https://groups.google.com/d/msgid/efibootguard-dev/b273b8d6-d84e-4709-8915-860113531e12n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/b273b8d6-d84e-4709-8915-860113531e12n%40googlegroups.com> <https://groups.google.com/d/msgid/efibootguard-dev/b273b8d6-d84e-4709-8915-860113531e12n%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/efibootguard-dev/b273b8d6-d84e-4709-8915-860113531e12n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
> --
> Siemens AG, Technology
> Linux Expert Center
>

> --
> You received this message because you are subscribed to the Google
> Groups "EFI Boot Guard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to efibootguard-d...@googlegroups.com
> <mailto:efibootguard-d...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/efibootguard-dev/b59b4a09-0e4a-4c6b-9318-f7d41a216311n%40googlegroups.com <https://groups.google.com/d/msgid/efibootguard-dev/b59b4a09-0e4a-4c6b-9318-f7d41a216311n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Root Mailer]

Okay if Tiger Lake H has been tested successfully, it's strange that our Tiger Lake LP doesn't, the tco_base is identical for those two:

[    4.276615] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=6, TCOBASE=0x0400)

Will have a look if other registers differ.

[Root Mailer]

As a first step I dumped the registers at the end of the init() function here:

https://github.com/siemens/efibootguard/blob/master/drivers/watchdog/itco.c#L341

Result:

TCO_RLD: 0x64
TCOv1_TMR: 0x0
TCO_DAT_IN: 0x0
TCO_DAT_OUT: 0x0
TCO1_STS: 0x0
TCO2_STS: 0x0
TCO1_CNT: 0x1000
TCO2_CNT: 0x8
TCOv2_TMR: 0x64

As I did not find the register documentation from Intel yet, I can only compare that to the one of the kernel watchdog. Maybe you already have a hint.

[Jan Kiszka]

On 22.11.23 11:09, Root Mailer wrote:
> As a first step I dumped the registers at the end of the init() function
> here:
>
> https://github.com/siemens/efibootguard/blob/master/drivers/watchdog/itco.c#L341
>
> Result:
>
> TCO_RLD: 0x64
> TCOv1_TMR: 0x0
> TCO_DAT_IN: 0x0
> TCO_DAT_OUT: 0x0
> TCO1_STS: 0x0
> TCO2_STS: 0x0
> TCO1_CNT: 0x1000
> TCO2_CNT: 0x8
> TCOv2_TMR: 0x64
>
> As I did not find the register documentation from Intel yet, I can only
> compare that to the one of the kernel watchdog. Maybe you already have a
> hint.

Not yet without digging into all the details. But do you happen to have
the same dump for the Linux driver?

[Root Mailer]

Finally I have the same dump for the Linux driver:

TCO_RLD: 0x4

TCOv1_TMR: 0x0
TCO_DAT_IN: 0x0
TCO_DAT_OUT: 0x0
TCO1_STS: 0x0
TCO2_STS: 0x0

TCO1_CNT: 0x1801
TCO2_CNT: 0x8
TCOv2_TMR: 0x32

So apparently there is something wrong in TCO_RLD and/or TCO1_CNT.

[Root Mailer]

Okay TCO_RLD probably doesn't matter, it's TCO1_CNT_NO_REBOOT and TCO_TMR_HLT_MASK of TCO1_CNT that are not set in ebg but set in Linux driver.

[JEMS EBERHARD HORBEL]

DIRECT SENDER IS HERE LETS DEAL.

JENS EBERHARD



MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING 
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
SLBC PROVIDER
CREDIT CARD TOP UP
SEPA TRANSFER
WIRE TRANSFER
GLOBALPAY INC US

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP FOR A SERIOUS DEAL.

+447405129573