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
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 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_hand
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 p
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 graph
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 boo
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 fi
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
> unreported
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 lo
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 solut
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 t
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 th
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 pro
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 driver
; 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'
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 f
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 (re
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.
> > Thu
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.
Slow
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,
> > drivers/pnp
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
> resourc
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
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, un
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. W
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 hotplug
[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 jus
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
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 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 deskto
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 deskt
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 th
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: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 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 add
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
commi
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 overlap
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 like
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.
Hi,
On Tue, Feb 25, 2014 at 11:10 PM, Borislav Petkov wrote:
> On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
>
>> I am on tip.git at cfbf8d4 Linux 3.14-rc4.
>> and I don't see the problem (using Ubuntu Saucy).
>
> Also IVB, model 58?
>
Yes.
>> Given what you commented out, it
On Tue, Feb 25, 2014 at 07:54:53PM +0100, Stephane Eranian wrote:
> I am on tip.git at cfbf8d4 Linux 3.14-rc4.
> and I don't see the problem (using Ubuntu Saucy).
Also IVB, model 58?
> Given what you commented out, it seems like you're saying
> something goes wrong with pci_get_device().
Probab
On Tue, Feb 25, 2014 at 6:39 PM, Borislav Petkov wrote:
> On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
>> No, it's a T430s. What happens if you boot vanilla tip.git?
>
> linus/master + tip/master -> fails
> tip/master-> fails
>
> All trees are from today, like
On Tue, Feb 25, 2014 at 05:33:13PM +0100, Stephane Eranian wrote:
> No, it's a T430s. What happens if you boot vanilla tip.git?
linus/master + tip/master -> fails
tip/master-> fails
All trees are from today, like an hour ago or so.
Doing what hpa suggested:
diff --git a/arch/x86
On Tue, Feb 25, 2014 at 5:30 PM, Borislav Petkov wrote:
> On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
>> I am trying to understand your test case.
>> Were you actually measure uncore_imc events at the time you suspended?
>
> No test case, just the machine booting; look at the
On Tue, Feb 25, 2014 at 05:14:01PM +0100, Stephane Eranian wrote:
> I am trying to understand your test case.
> Were you actually measure uncore_imc events at the time you suspended?
No test case, just the machine booting; look at the printk timestamps.
> I tried on my IvyBridge Lenovo and it wor
Hi,
I am trying to understand your test case.
Were you actually measure uncore_imc events at the time you suspended?
I tried on my IvyBridge Lenovo and it works fine with 3.14-rc4+ (tip.git).
I used: echo -n disk >/sys/power/state
On Tue, Feb 25, 2014 at 4:48 PM, H. Peter Anvin wrote:
> On 0
On 02/24/2014 12:19 PM, Borislav Petkov wrote:
> Btw,
>
> I don't know whether the following observation is related or not, but it
> so happens that after resume from suspend-to-disk, I see the booting up
> of the resume kernel on the console but when it is time for the original
> kernel to take o
Btw,
I don't know whether the following observation is related or not, but it
so happens that after resume from suspend-to-disk, I see the booting up
of the resume kernel on the console but when it is time for the original
kernel to take over and switch to graphics, the screen remains black but
th
60 matches
Mail list logo
