Hi Jason,
On Fri, 6 Apr 2018 08:35:13 -0400, Jason Andryuk wrote:
> On Wed, Apr 4, 2018 at 11:03 AM, Jean Delvare <jdelvare@xxxxxxx> wrote:
> > If it does, then one thing you could test is to boot with
> > i2c_i801.disable_features=0x20, then rmmod i2c-i801 and load it again
> > but without disable_features=0x20. If it still hangs then at least you
> > would have a running system to diagnose the problem. If we knew where
> > it hangs when maybe we could come up with a fix or at least workaround.
>
> I went through this scenario, and it still hangs on subsequent boot.
> The boot hang is actually in the boot loader code.
>
> The problem scenario with an un-patched kernel and no options:
> 1) Power on system
> 2) Linux boots and enables SMBus Host Notify
> 3) Power off while plugged in
> 4) Boot system
> 5a) Hang in Legacy Grub graphical mode
> or
> 5b) Hang in PXE boot code
>
> Linux runs fine, it's something with enabling Host Notify that puts
> the G3 850 firmware into a weird state. On a subsequent boot, that
> weird state throws off certain boot scenarios.
>
> Weird state breaks:
> Legacy Grub graphical mode
> Intel Boot Agent PXE boot
>
> Unaffected by weird state:
> EFI Grub
> Legacy Grub text mode
>
> Unplugging the laptop seems to clear the weird state. Rebooting is
> not affected by the weird state. Going into the BIOS/EFI setup seems
> to clear the weird state.
>
> Blacklisting Host Notify prevents the G3 850 from getting into the
> weird state, so future plugged in booting just works. So it's not an
> i2c bug - it's a firmware bug triggered by Host Notify.
Yes, sorry, had I remembered the problem description, it should have
been clear to me that my suggested test served no purpose. Sorry for
wasting your time.
There's still one thing I do not understand. The driver is supposed to
restore the device configuration to what it was at probe time. Namely,
we disable Host Notify interrupts at removal time if they were disabled
originally:
static void i801_enable_host_notify(struct i2c_adapter *adapter)
{
(...)
priv->original_slvcmd = inb_p(SMBSLVCMD(priv));
(...)
}
static void i801_disable_host_notify(struct i801_priv *priv)
{
(...)
outb_p(priv->original_slvcmd, SMBSLVCMD(priv));
}
But still, your experiments clearly show that something must be
different after the device was probed and removed. I would be really
curious to know what.
One thing you could do is compare all the register values before and
after loading and unloading the i2c-i801 driver, with and without
disable_features=0x20. For that purpose, you would have to build
i2c-i801 as a module, and blacklist this module so it does not get
auto-loaded. You can find the base I/O address of the registers with:
# lspci -v -s 00:1f.3
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04)
Subsystem: Dell Device 05a4
Flags: medium devsel, IRQ 18
Memory at f7f35000 (64-bit, non-prefetchable) [size=256]
I/O ports at f000 [size=32] <-- HERE
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
Then the register values can be dumped with:
# isadump -f 0xf000 32
isadump is part of lm-sensors. Adjust the address for your own system.
Then modprobe i2c-i801, rmmod i2c-i801, and dump again. If there is any
difference then that would possibly point us to what the firmware does
not like on next boot.
--
Jean Delvare
SUSE L3 Support
