On Wed, 15 Nov 2017 21:25:25 +0100, Alban Browaeys wrote:
> This fix is a partial one: it only fixes the issue once> we unload then reload i2c-i801 .> This as when we load a second time orig_hstcfg is set to the value the> first module load leftover.> Thus I will investigate the initial orig_hstcfg at boot to further the> fix.> I bet this only a few missing bits like HST_EN.
Volker, I think you had a fix for that one? But I can't find it in the
list archive :-(

I am on one of those Intel Haswell with the ACPI OpRegion conflict, the
acpi handler was added to cope with.
Could it be the embedded controller code mess with the smbus ?
When I print the OpRegion fields via acpi-call I get different values
after suspend/resume from S3 than at runtime at various points.
I already checked that the acpi SBUS methods are not called.
To do so I define a global name set to zero and set it to 1 in
SBUS.STRT (called by all SBUS method to verify the ready state).
Could it be the EC access the region directly ?
The acpi handler from i2c-i801 does not trigger. Is it in effect when
suspending or resuming ?
The reproducer seems hard to get right, I am still investigating.
It involves resume from suspend (S3) and a yet to define state.
Most of the time after an acpi reset (magic sysrq 'b').
And / or early load of i2x-i801, rmi_smbus and psmouse.
To call the acpi methods I echo to /proc/acpi/call from the acpi-call
module.
I tried https://github.com/pali/i2c-acpi-sbus .
It fails early as acpi sbus methods check the inuse host status flag.
It is always on thus they bail out. i2c-i801 does not test inuse
(0x40).
Best regards
Alban
Le lundi 20 novembre 2017 à 10:15 +0100, Jean Delvare a écrit :
> On Wed, 15 Nov 2017 21:25:25 +0100, Alban Browaeys wrote:> > This fix is a partial one: it only fixes the issue once> > we unload then reload i2c-i801 .> > This as when we load a second time orig_hstcfg is set to the value> > the> > first module load leftover.> > Thus I will investigate the initial orig_hstcfg at boot to further> > the> > fix.> > I bet this only a few missing bits like HST_EN.> > Volker, I think you had a fix for that one? But I can't find it in> the> list archive :-(>

On Tue, 21 Nov 2017 09:47:41 +0100, Volker Rümelin wrote:
> > Volker, I think you had a fix for that one? But I can't find it in the> > list archive :-(> Yes, on 13 Jun 2017 I sent a patch to the linux-i2c mailing list. But> the mailing list server told me: Your address is not liked source for> email. At this point I gave up.
I see, that's why it's in my mailbox but missing from the archive.
> If you are still interested I can try to resend the patch with my> google email account.
I'll review it, so it will become visible :-)
Thanks,

> > > Volker, I think you had a fix for that one? But I can't find it in the> > > list archive :-(> > Yes, on 13 Jun 2017 I sent a patch to the linux-i2c mailing list. But> > the mailing list server told me: Your address is not liked source for> > email. At this point I gave up.> > I see, that's why it's in my mailbox but missing from the archive.> > > If you are still interested I can try to resend the patch with my> > google email account.> > I'll review it, so it will become visible :-)
So, Volker's patch showed up on the ML meanwhile, nice :)
I don't get if we need this patch as well or if this gets covered with
Volker's patch as well?

Thanks for Volker's patch.
I applied it and it does not help on this Intel Haswell box (Lenovo
Thinkpad Yoga S1). My initial patch did not helped either.
I was confused as the bug reproduce easely only if the i2c-i801,
rmi_smbus and psmouse are loaded once then resume from suspend.
Afterwards (even unload module) I sometimes get around the bug.
Could ACPI/EC OpRegion accesses happen without the kernel handler
triggering (while suspending and / or resuming) ?
Thanks
Alban
Le lundi 20 novembre 2017 à 15:18 +0100, Alban Browaeys a écrit :
> I am on one of those Intel Haswell with the ACPI OpRegion conflict,> the> acpi handler was added to cope with.> > Could it be the embedded controller code mess with the smbus ?> When I print the OpRegion fields via acpi-call I get different values> after suspend/resume from S3 than at runtime at various points.> > I already checked that the acpi SBUS methods are not called.> To do so I define a global name set to zero and set it to 1 in> SBUS.STRT (called by all SBUS method to verify the ready state).> > Could it be the EC access the region directly ?> The acpi handler from i2c-i801 does not trigger. Is it in effect when> suspending or resuming ?> > The reproducer seems hard to get right, I am still investigating.> It involves resume from suspend (S3) and a yet to define state.> Most of the time after an acpi reset (magic sysrq 'b').> And / or early load of i2x-i801, rmi_smbus and psmouse.> > To call the acpi methods I echo to /proc/acpi/call from the acpi-call> module. > > I tried https://github.com/pali/i2c-acpi-sbus .> It fails early as acpi sbus methods check the inuse host status flag.> It is always on thus they bail out. i2c-i801 does not test inuse> (0x40).> > > Best regards> Alban> > > Le lundi 20 novembre 2017 à 10:15 +0100, Jean Delvare a écrit :> > On Wed, 15 Nov 2017 21:25:25 +0100, Alban Browaeys wrote:> > > This fix is a partial one: it only fixes the issue once> > > we unload then reload i2c-i801 .> > > This as when we load a second time orig_hstcfg is set to the> > > value> > > the> > > first module load leftover.> > > Thus I will investigate the initial orig_hstcfg at boot to> > > further> > > the> > > fix.> > > I bet this only a few missing bits like HST_EN.> > > > Volker, I think you had a fix for that one? But I can't find it in> > the> > list archive :-(

Le jeudi 07 décembre 2017 à 11:57 +0100, Wolfram Sang a écrit :
> > > > Volker, I think you had a fix for that one? But I can't find it> > > > in the> > > > list archive :-(> > > > > > Yes, on 13 Jun 2017 I sent a patch to the linux-i2c mailing list.> > > But> > > the mailing list server told me: Your address is not liked source> > > for> > > email. At this point I gave up.> > > > I see, that's why it's in my mailbox but missing from the archive.> > > > > If you are still interested I can try to resend the patch with my> > > google email account.> > > > I'll review it, so it will become visible :-)> > So, Volker's patch showed up on the ML meanwhile, nice :)> > I don't get if we need this patch as well or if this gets covered> with> Volker's patch as well?
Mine is a rough duplicate of Volker.
But it turns out none of those take care of the ENXIO issue. I thought
otherwise at first but this bug is not easely reproducible except on
cold boot.
I am at loss as to how to fix my ENXIO issue.
Thanks,
Alban