On Wed, Nov 25, 2015 at 06:01:20AM +0100, Juergen Gross wrote:
> On 24/11/15 23:46, Luis R. Rodriguez wrote:
> > On Mon, Nov 23, 2015 at 03:19:16PM +0100, Juergen Gross wrote:
> >> On 23/11/15 15:11, vas...@iit.demokritos.gr wrote:
> >>> Ok I will send the .config when I get back home. I have all k
On 24/11/15 23:46, Luis R. Rodriguez wrote:
> On Mon, Nov 23, 2015 at 03:19:16PM +0100, Juergen Gross wrote:
>> On 23/11/15 15:11, vas...@iit.demokritos.gr wrote:
>>> Ok I will send the .config when I get back home. I have all kernels I
>>> build in .deb archive. The problem is that the debian kern
On Mon, Nov 23, 2015 at 03:19:16PM +0100, Juergen Gross wrote:
> On 23/11/15 15:11, vas...@iit.demokritos.gr wrote:
> > Ok I will send the .config when I get back home. I have all kernels I
> > build in .deb archive. The problem is that the debian kernel build
> > procedure does not hold somewhere
On Tue, Nov 24, 2015 at 01:01:31AM +0200, Vassilis Virvilis wrote:
> On 11/23/2015 08:56 PM, Luis R. Rodriguez wrote:
> >Its not clear from the log who called this MTRR call for WC that failed, I
> >hope we didn't attempt a WC wright on a WB region. Who owns
> >e000-efff ?
>
On Tue, Nov 24, 2015 at 11:36:54AM +0200, vas...@iit.demokritos.gr wrote:
> > Let's try to speed up reproducing this.
> >
> > I have a hunch perhaps this might be related to some BIOS controlled
> > MTRRs and a mismatch which then enables the kernel to think that a type
> > of MTRR write might be O
> Let's try to speed up reproducing this.
>
> I have a hunch perhaps this might be related to some BIOS controlled
> MTRRs and a mismatch which then enables the kernel to think that a type
> of MTRR write might be OK, but in fact its not. Due to the work load
> description of this perhaps this coul
On 11/23/2015 08:56 PM, Luis R. Rodriguez wrote:
Its not clear from the log who called this MTRR call for WC that failed, I
hope we didn't attempt a WC wright on a WB region. Who owns
e000-efff ?
How can I answer that? Is there any utility to run? peek inside /proc?
Her
On Sat, Nov 21, 2015 at 01:49:06PM +0200, Vassilis Virvilis wrote:
> On 11/20/2015 02:23 PM, Juergen Gross wrote:
> >On 20/11/15 11:04, vas...@iit.demokritos.gr wrote:
> >>>I've just found a potential issue: In case MTRR is disabled by the BIOS
> >>>the PAT register of the boot processor won't be r
On Thu, Nov 19, 2015 at 06:39:28AM +0100, Juergen Gross wrote:
> On 18/11/15 22:43, Vassilis Virvilis wrote:
> > Hi,
> >
> > I have been hit by a hibernate/resume bug. Other people may have too:
> > The following links are consistent with my observations
> >
> > https://bugs.launchpad.net/ubuntu/
On 23/11/15 15:11, vas...@iit.demokritos.gr wrote:
> Ok I will send the .config when I get back home. I have all kernels I
> build in .deb archive. The problem is that the debian kernel build
> procedure does not hold somewhere in the deb file the git commit hash.
>
> Fow which kernel would you ca
On 11/20/2015 02:23 PM, Juergen Gross wrote:
>
> As the BIOS obviously isn't disabling MTRR I don't think we have
> to go that route any longer.
ok.
>>
>> In the weekend I will return to 3.18-rc2 and I will try to verify my
>> bisection is correct. Double guessing your self is a terrible thing..
On 21/11/15 12:49, Vassilis Virvilis wrote:
> On 11/20/2015 02:23 PM, Juergen Gross wrote:
>> On 20/11/15 11:04, vas...@iit.demokritos.gr wrote:
I've just found a potential issue: In case MTRR is disabled by the BIOS
the PAT register of the boot processor won't be restored after resume.
>
On 11/20/2015 02:23 PM, Juergen Gross wrote:
On 20/11/15 11:04, vas...@iit.demokritos.gr wrote:
I've just found a potential issue: In case MTRR is disabled by the BIOS
the PAT register of the boot processor won't be restored after resume.
Can you check whether pr_info("MTRR: Disabled\n") has be
On 20/11/15 11:04, vas...@iit.demokritos.gr wrote:
>> I've just found a potential issue: In case MTRR is disabled by the BIOS
>> the PAT register of the boot processor won't be restored after resume.
>>
>> Can you check whether pr_info("MTRR: Disabled\n") has been executed in
>> early boot? If yes,
> I've just found a potential issue: In case MTRR is disabled by the BIOS
> the PAT register of the boot processor won't be restored after resume.
>
> Can you check whether pr_info("MTRR: Disabled\n") has been executed in
> early boot? If yes, this might be a BIOS option.
>
I don't have access rig
On 20/11/15 06:25, Vassilis Virvilis wrote:
> On 11/19/2015 10:35 PM, Vassilis Virvilis wrote:
>>
>> I compiled and I am running 4.3 right now.
>>
>
> It failed this morning. Last night I did 3 hibernate / resume cycles. In
> the last one I I also turned off the PSU (this seems to push it over the
On 11/19/2015 10:35 PM, Vassilis Virvilis wrote:
I compiled and I am running 4.3 right now.
It failed this morning. Last night I did 3 hibernate / resume cycles. In the
last one I I also turned off the PSU (this seems to push it over the edge - but
it may be random behavior) and it worked.
On 11/19/2015 11:10 AM, Juergen Gross wrote:
So Do you want me to test 4.3 or 4.4-pre/rc*/latest linus tree. I assume
4.3 for now.
I think 4.3 is okay.
I will do it later tonight. It will take 2 days at least to report back
I compiled and I am running 4.3 right now.
If it fails I will try
On 19/11/15 08:50, vas...@iit.demokritos.gr wrote:
> Hi,
>
> Thanks for the quick answer
>
>>
>> Could you please try the most recent 4.3 kernel? There has been some
>> work related to this topic after 4.2 (large page pat handling done by
>> Toshi Kani and mtrr/pat handling by Luis Rodriguez).
>
Hi,
Thanks for the quick answer
>
> Could you please try the most recent 4.3 kernel? There has been some
> work related to this topic after 4.2 (large page pat handling done by
> Toshi Kani and mtrr/pat handling by Luis Rodriguez).
That means I will reset the bisection. Right? Is there any other
On 18/11/15 22:43, Vassilis Virvilis wrote:
> Hi,
>
> I have been hit by a hibernate/resume bug. Other people may have too:
> The following links are consistent with my observations
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1490494
> https://bugs.archlinux.org/task/44807
>
> Some
21 matches
Mail list logo
