On 2020-05-27 23:38, John Baldwin wrote:
No. I get that constantly on a desktop that never suspends/resumes.
It only started after upgrading to 12.0.
If you have time, could you investigate why the USB host controllers
Root HUB PCI register flips to -1U ? Which cause these spurious events
..
On 5/27/20 2:05 PM, Hans Petter Selasky wrote:
> On 2020-05-27 15:41, Justin Hibbits wrote:
>> On Wed, 27 May 2020 06:27:16 -0700
>> John Baldwin wrote:
>>
>>> On 5/27/20 2:39 AM, Andriy Gapon wrote:
On 27/05/2020 11:13, Andriy Gapon wrote:
> I added more diagnostics and it seems to suppo
On 2020-05-27 15:41, Justin Hibbits wrote:
On Wed, 27 May 2020 06:27:16 -0700
John Baldwin wrote:
On 5/27/20 2:39 AM, Andriy Gapon wrote:
On 27/05/2020 11:13, Andriy Gapon wrote:
I added more diagnostics and it seems to support the idea that the
problem is related to I/O cycles and bridges.
On Wed, 27 May 2020 06:27:16 -0700
John Baldwin wrote:
> On 5/27/20 2:39 AM, Andriy Gapon wrote:
> > On 27/05/2020 11:13, Andriy Gapon wrote:
> >> I added more diagnostics and it seems to support the idea that the
> >> problem is related to I/O cycles and bridges.
> >>
> >> ACPI timer suddenly
On 27/05/2020 16:27, John Baldwin wrote:
> The "solution" I think is to have resume be multi-pass and to resume all the
> bridges
> first before trying to resume leaf devices (including timers), but that's a
> fair bit
> of work. It might be that we just need to resume timer interrupts later
>
On 5/27/20 2:39 AM, Andriy Gapon wrote:
> On 27/05/2020 11:13, Andriy Gapon wrote:
>> I added more diagnostics and it seems to support the idea that the problem is
>> related to I/O cycles and bridges.
>>
>> ACPI timer suddenly starts returning 0x and that lasts for tens of
>> microseconds
On 27/05/2020 11:13, Andriy Gapon wrote:
> I added more diagnostics and it seems to support the idea that the problem is
> related to I/O cycles and bridges.
>
> ACPI timer suddenly starts returning 0x and that lasts for tens of
> microseconds before the timer goes back to returning normal
On 27/05/2020 01:14, John Baldwin wrote:
> On 5/26/20 11:55 AM, Konstantin Belousov wrote:
>> On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote:
>>> I am not sure if this is just a coincidence but it appears as if a write to
>>> some
>>> PCI configuration register could temporarily inte
On 5/26/20 11:55 AM, Konstantin Belousov wrote:
> On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote:
>> On 25/05/2020 11:37, Andriy Gapon wrote:
>>> Also, there is another issue related to atrtc.
>>> When I have both drivers attached, and also when I have only atrtc attached
>>> (efi.rt.
On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote:
> On 25/05/2020 11:37, Andriy Gapon wrote:
> > Also, there is another issue related to atrtc.
> > When I have both drivers attached, and also when I have only atrtc attached
> > (efi.rt.disabled=1), system clock jumps 10 minutes forward
On 25/05/2020 11:37, Andriy Gapon wrote:
> Also, there is another issue related to atrtc.
> When I have both drivers attached, and also when I have only atrtc attached
> (efi.rt.disabled=1), system clock jumps 10 minutes forward after each suspend
> /
> resume cycle (S0 -> S3 -> S0). That does no
On Mon, 2020-05-25 at 11:37 +0300, Andriy Gapon wrote:
> I see that on my laptop both efirtc and atrtc get attached.
> The latter is via an ACPI attachment:
> efirtc0:
> efirtc0: registered as a time-of-day clock, resolution 1.00s
> atrtc0: port 0x70-0x71 on acpi0
> atrtc0: registered as a ti
I see that on my laptop both efirtc and atrtc get attached.
The latter is via an ACPI attachment:
efirtc0:
efirtc0: registered as a time-of-day clock, resolution 1.00s
atrtc0: port 0x70-0x71 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
I am not sure if this is a
13 matches
Mail list logo
