On Thu, Apr 17, 2014 at 05:30:27PM -0400, Dave Jones wrote:
> I think it's just implicated because that's the next thing that seems
> to init after the modeswitch. The config differences are small, just
> things like =m instead of =y or vice-versa.
>
> I'm about to head into a long weekend, so
On Thu, Apr 17, 2014 at 05:30:27PM -0400, Dave Jones wrote:
I think it's just implicated because that's the next thing that seems
to init after the modeswitch. The config differences are small, just
things like =m instead of =y or vice-versa.
I'm about to head into a long weekend, so I'll get
On Thu, Apr 17, 2014 at 04:53:55PM -0400, Dave Jones wrote:
> ok, with your config I get back to a console after the modesetting
> switch, but then it hangs in USB init.
Maybe because of our machines are not that similar there? Can you take
my config but paste the usb part of yours and see
On Thu, Apr 17, 2014 at 04:03:52PM -0400, Dave Jones wrote:
> On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
> > On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
> > > Just as X starts up, I see this in dmesg..
> > >
> > > [ 42.879049]
On Thu, Apr 17, 2014 at 1:48 PM, Borislav Petkov wrote:
> On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
>> Thanks a lot for testing this out and debugging my issues.
>>
>> Here's a new version that looks for both device IDs I know about.
>>
>> I'm still nervous about the modeset
On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
> On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
> > Just as X starts up, I see this in dmesg..
> >
> > [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
> > underrun
>
> FWIW, I have that
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
> Just as X starts up, I see this in dmesg..
>
> [ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
> underrun
FWIW, I have that too. It should be something i915-related:
[0.617673] [drm] Memory usable by
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
> Thanks a lot for testing this out and debugging my issues.
>
> Here's a new version that looks for both device IDs I know about.
I can confirm this patch does fix the backtrace.
I disabled lockdep, and now I can get to X each
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
> Thanks a lot for testing this out and debugging my issues.
>
> Here's a new version that looks for both device IDs I know about.
>
> I'm still nervous about the modeset problem Dave is seeing. Since the
> original patch wouldn't
Thanks a lot for testing this out and debugging my issues.
Here's a new version that looks for both device IDs I know about.
I'm still nervous about the modeset problem Dave is seeing. Since the
original patch wouldn't find an 8086:0c00 device on Dave's system, it
should have done nothing. But
Hi Bjorn,
thanks for the patch, a couple of notes below:
On Wed, Apr 16, 2014 at 04:56:00PM -0600, Bjorn Helgaas wrote:
> PNP: Work around Haswell BIOS defect in MCH area reporting
>
> From: Bjorn Helgaas
>
> Work around a Haswell BIOS defect that causes part of the MCH area to be
>
Hi Bjorn,
thanks for the patch, a couple of notes below:
On Wed, Apr 16, 2014 at 04:56:00PM -0600, Bjorn Helgaas wrote:
PNP: Work around Haswell BIOS defect in MCH area reporting
From: Bjorn Helgaas bhelg...@google.com
Work around a Haswell BIOS defect that causes part of the MCH area to
Thanks a lot for testing this out and debugging my issues.
Here's a new version that looks for both device IDs I know about.
I'm still nervous about the modeset problem Dave is seeing. Since the
original patch wouldn't find an 8086:0c00 device on Dave's system, it
should have done nothing. But
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
Thanks a lot for testing this out and debugging my issues.
Here's a new version that looks for both device IDs I know about.
I'm still nervous about the modeset problem Dave is seeing. Since the
original patch wouldn't find an
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
Thanks a lot for testing this out and debugging my issues.
Here's a new version that looks for both device IDs I know about.
I can confirm this patch does fix the backtrace.
I disabled lockdep, and now I can get to X each boot,
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
Just as X starts up, I see this in dmesg..
[ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
underrun
FWIW, I have that too. It should be something i915-related:
[0.617673] [drm] Memory usable by graphics
On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
Just as X starts up, I see this in dmesg..
[ 42.879049] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO
underrun
FWIW, I have that too. It
On Thu, Apr 17, 2014 at 1:48 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
Thanks a lot for testing this out and debugging my issues.
Here's a new version that looks for both device IDs I know about.
I'm still nervous about the
On Thu, Apr 17, 2014 at 04:03:52PM -0400, Dave Jones wrote:
On Thu, Apr 17, 2014 at 10:01:27PM +0200, Borislav Petkov wrote:
On Thu, Apr 17, 2014 at 03:52:40PM -0400, Dave Jones wrote:
Just as X starts up, I see this in dmesg..
[ 42.879049] [drm:cpt_serr_int_handler]
On Thu, Apr 17, 2014 at 04:53:55PM -0400, Dave Jones wrote:
ok, with your config I get back to a console after the modesetting
switch, but then it hangs in USB init.
Maybe because of our machines are not that similar there? Can you take
my config but paste the usb part of yours and see whether
On Wed, Apr 16, 2014 at 04:56:00PM -0600, Bjorn Helgaas wrote:
> > I'm seeing the exact same message on my thinkpad t430s.
> > When I try your patch, modesetting no longer works. When it tries
> > to change to the framebuffer I get a black screen and lockup.
> > If I boot with nomodeset it
On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian wrote:
> On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas wrote:
>> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
>>> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
>>> > Right. Even if we had this long-term
On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas wrote:
> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
>> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
>> > Right. Even if we had this long-term solution, we'd still have
>> > Stephane's current problem, because
On Wed, Apr 16, 2014 at 06:31:22PM -0400, Dave Jones wrote:
> On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote:
> > On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
> > > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> > > > Right. Even if we had
On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote:
> On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
> > On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> > > Right. Even if we had this long-term solution, we'd still have
> > > Stephane's current
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> > Right. Even if we had this long-term solution, we'd still have
> > Stephane's current problem, because the PNP0C02 _CRS is still wrong.
> >
> > We do have a
; Stephane Eranian; Yan, Zheng Z
> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> Importance: High
>
> On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> > Right. Even if we had this long-term solution, we'd still have
> > Stephane's current
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
> Right. Even if we had this long-term solution, we'd still have
> Stephane's current problem, because the PNP0C02 _CRS is still wrong.
>
> We do have a drivers/pnp/quirks.c where we could conceivably adjust
> the PNP resource if we
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem, because the PNP0C02 _CRS is still wrong.
We do have a drivers/pnp/quirks.c where we could conceivably adjust
the PNP resource if we found
, Zheng Z
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem, because the PNP0C02 _CRS is still wrong.
We do
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem, because the PNP0C02 _CRS is still wrong.
We do have a
On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote:
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current problem,
On Wed, Apr 16, 2014 at 06:31:22PM -0400, Dave Jones wrote:
On Wed, Apr 16, 2014 at 02:31:38PM -0600, Bjorn Helgaas wrote:
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this
On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if we had this long-term solution, we'd still have
Stephane's current
On Wed, Apr 16, 2014 at 5:08 PM, Stephane Eranian eran...@google.com wrote:
On Wed, Apr 16, 2014 at 1:31 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Wed, Apr 16, 2014 at 09:04:04PM +0200, Borislav Petkov wrote:
On Thu, Mar 20, 2014 at 02:48:30PM -0600, Bjorn Helgaas wrote:
Right. Even if
On Wed, Apr 16, 2014 at 04:56:00PM -0600, Bjorn Helgaas wrote:
I'm seeing the exact same message on my thinkpad t430s.
When I try your patch, modesetting no longer works. When it tries
to change to the framebuffer I get a black screen and lockup.
If I boot with nomodeset it locks up
On Thu, Mar 20, 2014 at 2:55 PM, Rafael J. Wysocki wrote:
> On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
>> The purpose of system.c is indeed to prevent resources from being
>> allocated to other devices. This is really a question for Rafael, but
>> in my opinion this function
On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
> On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui wrote:
>
> > I've talked with Yan Zheng, and I was told that this resource "0xfed1 -
> > 0xfed15fff"
> > is got from PCI device register directly, which is not in its BAR range.
> >
On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui wrote:
> I've talked with Yan Zheng, and I was told that this resource "0xfed1 -
> 0xfed15fff"
> is got from PCI device register directly, which is not in its BAR range.
> Thus IMO, it is impossible for PNP layer to be aware of this resource.
On Thu, Mar 20, 2014 at 9:16 AM, Yan, Zheng wrote:
> On 03/20/2014 03:53 PM, Zhang, Rui wrote:
>> The resource length is also hardcoded to 0x6000, right?
>> This is probably a problem, because
>> only if the resource length read from PCI config space is larger than 0x4000,
>> drivers/pnp/quirks.c
On Thu, 2014-03-20 at 16:16 +0800, Yan, Zheng wrote:
> On 03/20/2014 03:53 PM, Zhang, Rui wrote:
> > The resource length is also hardcoded to 0x6000, right?
> > This is probably a problem, because
> > only if the resource length read from PCI config space is larger than
> > 0x4000,
> >
lkml; x...@kernel.org;
> > Bjorn Helgaas; Linux PCI; ACPI Devel Maling List; Yinghai Lu; H. Peter
> > Anvin; Yan, Zheng Z
> > Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> > Importance: High
> >
> > On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui
Devel Maling
> > List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian
> > Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> > Importance: High
> >
> > On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
> > > [CC list rearranged]
&g
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
> The resource length is also hardcoded to 0x6000, right?
> This is probably a problem, because
> only if the resource length read from PCI config space is larger than 0x4000,
> drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02
>
nghai Lu; H. Peter
> Anvin; Yan, Zheng Z
> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
> Importance: High
>
> On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui wrote:
> >
> >
> >> -Original Message-
> >> From: Lu, Aaron
> >> Sent
, Zheng Z
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui rui.zh...@intel.com wrote:
-Original Message-
From: Lu, Aaron
Sent: Thursday, March 20, 2014 10:24 AM
To: Rafael J. Wysocki; Borislav Petkov
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
The resource length is also hardcoded to 0x6000, right?
This is probably a problem, because
only if the resource length read from PCI config space is larger than 0x4000,
drivers/pnp/quirks.c will detect the conflict and disable the PNP0C02
resource
. Peter Anvin; Stephane Eranian
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning
; ACPI Devel Maling List; Yinghai Lu; H. Peter
Anvin; Yan, Zheng Z
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On Thu, Mar 20, 2014 at 4:03 AM, Zhang, Rui rui.zh...@intel.com wrote:
-Original Message-
From: Lu, Aaron
Sent
On Thu, 2014-03-20 at 16:16 +0800, Yan, Zheng wrote:
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
The resource length is also hardcoded to 0x6000, right?
This is probably a problem, because
only if the resource length read from PCI config space is larger than
0x4000,
drivers/pnp/quirks.c
On Thu, Mar 20, 2014 at 9:16 AM, Yan, Zheng zheng.z@intel.com wrote:
On 03/20/2014 03:53 PM, Zhang, Rui wrote:
The resource length is also hardcoded to 0x6000, right?
This is probably a problem, because
only if the resource length read from PCI config space is larger than 0x4000,
On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui rui.zh...@intel.com wrote:
I've talked with Yan Zheng, and I was told that this resource 0xfed1 -
0xfed15fff
is got from PCI device register directly, which is not in its BAR range.
Thus IMO, it is impossible for PNP layer to be aware of this
On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
On Wed, Mar 19, 2014 at 9:03 PM, Zhang, Rui rui.zh...@intel.com wrote:
I've talked with Yan Zheng, and I was told that this resource 0xfed1 -
0xfed15fff
is got from PCI device register directly, which is not in its BAR
On Thu, Mar 20, 2014 at 2:55 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, March 20, 2014 10:45:52 AM Bjorn Helgaas wrote:
The purpose of system.c is indeed to prevent resources from being
allocated to other devices. This is really a question for Rafael, but
in my opinion this
g
>> List; Zhang, Rui; Yinghai Lu; H. Peter Anvin; Stephane Eranian
>> Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
>> Importance: High
>>
>> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
>> > [CC list rearranged]
>> >
>
ct: Re: Info: mapping multiple BARs. Your kernel is fine.
> Importance: High
>
> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
> > [CC list rearranged]
> >
> > On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> >> This started happening this mo
On Thu, Mar 20, 2014 at 3:24 AM, Aaron Lu wrote:
> On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
>> [CC list rearranged]
>>
>> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
>>> This started happening this morning after booting -rc4+tip, let's
>>> add *everybody* to CC :-)
>>>
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
> [CC list rearranged]
>
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
>> This started happening this morning after booting -rc4+tip, let's
>> add *everybody* to CC :-)
>>
>> We have intel_uncore_init, snb_uncore_imc_init_box,
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's
add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box,
On Thu, Mar 20, 2014 at 3:24 AM, Aaron Lu aaron...@intel.com wrote:
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's
add *everybody* to CC
multiple BARs. Your kernel is fine.
Importance: High
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's
add
*everybody* to CC :-)
We have
Lu; H. Peter Anvin; Stephane Eranian
Subject: Re: Info: mapping multiple BARs. Your kernel is fine.
Importance: High
On 03/15/2014 10:15 PM, Rafael J. Wysocki wrote:
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning
On Monday, March 17, 2014 01:09:39 AM Rafael J. Wysocki wrote:
> On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
> > Rafael,
> >
> > Thanks for the analysis.
> >
> > On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> > > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J.
On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
> Rafael,
>
> Thanks for the analysis.
>
> On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> > On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
> >> I've just gone throught this.
> >
> > Thanks.
> >
> >> So
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov wrote:
> On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
>> I've just gone throught this.
>
> Thanks.
>
>> So the problem is that we have the PNP "system" driver whose only purpose
>> seems
>>
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
> I've just gone throught this.
Thanks.
> So the problem is that we have the PNP "system" driver whose only purpose
> seems
> to be to reserve system resources so that the PCI layer doesn't assign them to
> new devices on
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
I've just gone throught this.
Thanks.
So the problem is that we have the PNP system driver whose only purpose
seems
to be to reserve system resources so that the PCI layer doesn't assign them to
new devices on hotplug
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
I've just gone throught this.
Thanks.
So the problem is that we have the PNP system driver whose only purpose
seems
On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J. Wysocki wrote:
I've just gone throught this.
Thanks.
So the
On Monday, March 17, 2014 01:09:39 AM Rafael J. Wysocki wrote:
On Sunday, March 16, 2014 02:08:16 PM Stephane Eranian wrote:
Rafael,
Thanks for the analysis.
On Sun, Mar 16, 2014 at 12:55 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Mar 15, 2014 at 03:15:04PM +0100, Rafael J.
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> This started happening this morning after booting -rc4+tip, let's
> add *everybody* to CC :-)
>
> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
> other goodies on the stack.
I've
[CC list rearranged]
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's
add *everybody* to CC :-)
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
other goodies on the stack.
I've just
Hi,
Any update on this problem?
On Thu, Feb 27, 2014 at 11:21 PM, Borislav Petkov wrote:
> On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
>> I won't be able to look at that before Monday I'm afraid (personal
>> stuff).
>
> No worries, sir, whenever. It can wait.
>
> Thanks a
Hi,
Any update on this problem?
On Thu, Feb 27, 2014 at 11:21 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
I won't be able to look at that before Monday I'm afraid (personal
stuff).
No worries, sir, whenever. It can wait.
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
> I won't be able to look at that before Monday I'm afraid (personal
> stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> > there to BAR is at a completely different address. Same thing on my
> > Haswell
On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
>> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra
>> wrote:
>> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> >> As a asides, my SNB and HSW
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra wrote:
> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> >> They hang if I type
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
>> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
>> not so sure
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
> not so sure this is all related to the uncore IMC support, though.
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> there to BAR is at a completely different address. Same thing on my
> Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what
On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov wrote:
> Can you please, pretty please, not top-post...
>
> On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
>> Hi,
>>
>> Ok, so I am getting the same error message as you.
>> I checked my syslog now.
>>
>> I have my uncore_imc
On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov b...@alien8.de wrote:
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
Hi,
Ok, so I am getting the same error message as you.
I checked my syslog now.
I have my uncore_imc
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
there to BAR is at a completely different address. Same thing on my
Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what we're
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
not so sure this is all related to the uncore IMC support, though.
Unstable
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
They
On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
As a
On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
there to BAR is at a completely different address. Same thing on my
Haswell desktop
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
I won't be able to look at that before Monday I'm afraid (personal
stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
I don't think so because
On Wed, Feb 26, 2014 at 02:57:16PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> > This started happening this morning after booting -rc4+tip, let's
> > add *everybody* to CC :-)
>
> What about -rc4 without tip?
The driver causing this is new
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
> This started happening this morning after booting -rc4+tip, let's
> add *everybody* to CC :-)
What about -rc4 without tip?
> We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
> other goodies on the stack.
>
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
> Hi,
>
> Ok, so I am getting the same error message as you.
> I checked my syslog now.
>
> I have my uncore_imc addr=0xfed1 (after masking)
>
> And I also have pnp 00:01
Hi,
Ok, so I am getting the same error message as you.
I checked my syslog now.
I have my uncore_imc addr=0xfed1 (after masking)
And I also have pnp 00:01 overlapping the imc range completely.
What pnp device does it really represent? the DRAM controller?
So I think my laptop behaves
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
> > Also IVB, model 58?
> >
> Yes.
Right, so it must be chipset-specific.
> > Dunno. What do you mean by "pm callbacks" exactly? I don't know that
> > code so I have to ask.
> >
> power management callbacks.
Ok, just as I
On Wed, Feb 26, 2014 at 07:56:58AM +0100, Stephane Eranian wrote:
Also IVB, model 58?
Yes.
Right, so it must be chipset-specific.
Dunno. What do you mean by pm callbacks exactly? I don't know that
code so I have to ask.
power management callbacks.
Ok, just as I thought. But why
Hi,
Ok, so I am getting the same error message as you.
I checked my syslog now.
I have my uncore_imc addr=0xfed1 (after masking)
And I also have pnp 00:01 overlapping the imc range completely.
What pnp device does it really represent? the DRAM controller?
So I think my laptop behaves
Can you please, pretty please, not top-post...
On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
Hi,
Ok, so I am getting the same error message as you.
I checked my syslog now.
I have my uncore_imc addr=0xfed1 (after masking)
And I also have pnp 00:01 overlapping
On Monday, February 24, 2014 05:24:00 PM Borislav Petkov wrote:
This started happening this morning after booting -rc4+tip, let's
add *everybody* to CC :-)
What about -rc4 without tip?
We have intel_uncore_init, snb_uncore_imc_init_box, uncore_pci_probe and
other goodies on the stack.
...
1 - 100 of 120 matches
Mail list logo
