On Mon, 18 Mar 2013, Chris Wilson wrote:
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
void
intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
-
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
On Mon, 18 Mar 2013, Chris Wilson wrote:
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
void
intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
How about just using:
if (!HAS_GMBUS_IRQ(dev_priv-dev)) gmbus4_irq_en = 0;
and the existing wait loop?
I explicitly wanted to avoid touching GMBUS4 register, as the real cause
of the failure is not clear.
My laptop is an Acer 1810T. I see this error message each boot.
Kind regards
Thomas
Jiri Kosina jkos...@suse.cz schrieb:
On Fri, 15 Mar 2013, Jiri Kosina wrote:
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one
On Fri, Mar 15, 2013 at 08:47:39AM -0700, Greg KH wrote:
On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
On Fri, 15 Mar 2013, Greg KH wrote:
I have the same problem on my Lenovo T500. I think the graphics card
is
involved.
This laptop has hybrid
On Fri, 15 Mar 2013, Yinghai Lu wrote:
Just a datapoint -- I have put a trivial debugging patch in place, and it
reveals that nobody cared for irq 16 happens long after last
I915_WRITE(GMBUS4 + reg_offset, 0);
has been performed in gmbus_wait_hw_status(). On the other hand, if
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 (drm/i915: use the gmbus
On Mon, Mar 18, 2013 at 04:56:02PM +0100, Jiri Kosina wrote:
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] drm/i915: stop
On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina jkos...@suse.cz wrote:
On Fri, 15 Mar 2013, Yinghai Lu wrote:
Just a datapoint -- I have put a trivial debugging patch in place, and it
reveals that nobody cared for irq 16 happens long after last
I915_WRITE(GMBUS4 + reg_offset, 0);
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
On Fri, 15 Mar 2013, Yinghai Lu wrote:
Just a datapoint -- I have put a trivial debugging patch in place, and it
reveals that nobody cared for irq 16 happens long after last
I915_WRITE(GMBUS4 + reg_offset, 0);
On Mon, Mar 18, 2013 at 08:19:03PM +0100, Daniel Vetter wrote:
On Mon, Mar 18, 2013 at 10:12:49AM +0100, Jiri Kosina wrote:
On Fri, 15 Mar 2013, Yinghai Lu wrote:
Just a datapoint -- I have put a trivial debugging patch in place, and
it
reveals that nobody cared for irq 16
On Mon, 18 Mar 2013, Daniel Vetter wrote:
Yep, there's a big comment in the irq handler for that chipset that we
have a gaping race with when using MSI interrupts. Although the comment
bodly claims that the race is small enough to avoid the dreaded nobody
cared message. Looks like gmbus is
On Mon, 18 Mar 2013, Yinghai Lu wrote:
Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
interrupts go away.
My understanding from the other mail is that DAniel Vetter already has an
idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
this
On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina jkos...@suse.cz wrote:
On Mon, 18 Mar 2013, Yinghai Lu wrote:
Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
interrupts go away.
My understanding from the other mail is that DAniel Vetter already has an
idea what
On Thu, 14 Mar 2013, Rafael J. Wysocki wrote:
commit 181380b702eee1a9aca51354d7b87c7b08541fcf
Author: Yinghai Lu ying...@kernel.org
Date: Sat Feb 16 11:58:34 2013 -0700
PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers
This patch __fixed__ this
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get irq 16:
nobody cared during boot, not when I boot with the ATI card.
And
On Fri, 15 Mar 2013, Harald Arnesen wrote:
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get irq 16:
nobody cared during boot,
On Fri, 15 Mar 2013, Jiri Kosina wrote:
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get irq 16:
nobody cared during
On Fri, Mar 15, 2013 at 02:33:13PM +0100, Jiri Kosina wrote:
On Fri, 15 Mar 2013, Harald Arnesen wrote:
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When
On Fri, 15 Mar 2013, Greg KH wrote:
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get irq 16:
nobody cared during
On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
On Fri, 15 Mar 2013, Greg KH wrote:
I have the same problem on my Lenovo T500. I think the graphics card is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650.
On Fri, 15 Mar 2013, Greg KH wrote:
I have the same problem on my Lenovo T500. I think the graphics card
is
involved.
This laptop has hybrid graphics - one Intel GMA 4500MHD and one ATI
Mobility Radeon HD 3650. When I boot with the Intel card, I get irq
16:
On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina jkos...@suse.cz wrote:
Just a datapoint -- I have put a trivial debugging patch in place, and it
reveals that nobody cared for irq 16 happens long after last
I915_WRITE(GMBUS4 + reg_offset, 0);
has been performed in
On Wed, 13 Mar 2013, Jiri Kosina wrote:
OK, this is a me too, on Thinkpad x200s.
[4.116847] irq 16: nobody cared (try booting with the irqpoll option)
[4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb #186
[4.116850] Call Trace:
[4.116860] IRQ
On Thu, 14 Mar 2013, Alan Stern wrote:
[4.116847] irq 16: nobody cared (try booting with the irqpoll option)
[4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb
#186
[4.116850] Call Trace:
[4.116860] IRQ [810db0f8] __report_bad_irq+0x38/0xf0
On Thu, 14 Mar 2013, Jiri Kosina wrote:
On Thu, 14 Mar 2013, Alan Stern wrote:
[4.116847] irq 16: nobody cared (try booting with the irqpoll
option)
[4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb
#186
[4.116850] Call Trace:
[4.116860]
On Thu, 14 Mar 2013, Alan Stern wrote:
Can you try to do a git bisect for this? Is the sluggish system
response clear enough that you can tell reliably when it is present and
when it isn't?
That was my first thought, but unfortunately I am afraid there will be
point at which I
On Thu, 14 Mar 2013, Jiri Kosina wrote:
Is occurrence of the nobody cared connected with any particular
device? Somebody reported a similar problem not long ago (although IIRC
it was for OHCI rather than UHCI) which appeared to be related to
activity on the built-in webcam.
Will
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I don't think I have seen this message on rc1+ (8343bce, to be precise),
but I have definitely seen sluggish system response on that kernel as
well.
Attaching lspci, /proc/interrupts and dmesg.
Can you try to do a git bisect for
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I have reverted all three commits, and the nobody cared is still there.
If you revert all three and still see the problem then it must be
caused by changes outside of the USB stack. Differences in interrupt
routing could be a result of changes to
On Thu, 14 Mar 2013, Jiri Kosina wrote:
There have been only three significant changes to uhci-hcd since last
summer, and two of them appear to be completely unrelated to this
issue. The three commits are
3171fcabb169 USB: uhci: beautify source code
13996ca7afd5 USB:
On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I don't think I have seen this message on rc1+ (8343bce, to be
precise),
but I have definitely seen sluggish system response on that kernel as
well.
Attaching lspci,
On Thu, 2013-03-14 at 17:09 +0100, Jiri Kosina wrote:
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I don't think I have seen this message on rc1+ (8343bce, to be
precise),
but I have definitely seen sluggish system response on that kernel as
well.
Attaching lspci,
On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I don't think I have seen this message on rc1+ (8343bce, to be
precise),
but I have definitely seen sluggish system
On Thursday, March 14, 2013 01:06:04 PM Peter Hurley wrote:
On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
On Thu, 14 Mar 2013, Jiri Kosina wrote:
I don't think I have seen this message on rc1+ (8343bce, to be
On Thu, 2013-03-14 at 18:22 +0100, Rafael J. Wysocki wrote:
On Thursday, March 14, 2013 01:06:04 PM Peter Hurley wrote:
On Thu, 2013-03-14 at 17:46 +0100, Rafael J. Wysocki wrote:
On Thursday, March 14, 2013 05:09:59 PM Jiri Kosina wrote:
On Thu, 14 Mar 2013, Jiri Kosina wrote:
On Wed, Mar 13, 2013 at 2:35 PM, Jiri Kosina jkos...@suse.cz wrote:
OK, this is a me too, on Thinkpad x200s.
[4.116847] irq 16: nobody cared (try booting with the irqpoll option)
[4.116849] Pid: 1, comm: systemd Not tainted 3.9.0-rc2-00188-g6c23cbb #186
[4.116850] Call Trace:
[
Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
On Fri, 8 Mar 2013, Peter Hurley wrote:
[ +linux-usb ]
On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr wrote:
Hello folks,
I am noticing since rc0 and now rc1, very poor interrupt handling.
Keyboard response, mouse
[ +linux-pci, +linux-acpi, +Rafael Wysocki, +Bjorn Helgaas ]
On Sat, 2013-03-09 at 09:53 +0100, Thomas Meyer wrote:
Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
On Fri, 8 Mar 2013, Peter Hurley wrote:
[ +linux-usb ]
On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr
On Fri, 8 Mar 2013, Peter Hurley wrote:
[ +linux-usb ]
On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr wrote:
Hello folks,
I am noticing since rc0 and now rc1, very poor interrupt handling. Keyboard
response, mouse movements, display refreshing etc. General input/display
40 matches
Mail list logo
