[BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Arnd Bergmann]

Commit c64f7ba5f10 "agp/intel: Remove confusion of stolen entries not stolen memory" caused a regression on my Intel G45 based system, using the VESA
Xorg driver or uvesafb. I have not tried if i915 with KMS shows the same
behaviour, but can try if necessary.

Reverting the patch on Friday's linux-next restores the normal behaviour
and lets me use X again.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 356f73e..7812a3a 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -342,12 +342,13 @@ static const struct aper_size_info_fixed intel_fake_agp_sizes[] = {
 	{512, 131072, 7},
 };
 
-static unsigned int intel_gtt_stolen_size(void)
+static unsigned int intel_gtt_stolen_entries(void)
 {
 	u16 gmch_ctrl;
 	u8 rdct;
 	int local = 0;
 	static const int ddt[4] = { 0, 16, 32, 64 };
+	unsigned int overhead_entries;
 	unsigned int stolen_size = 0;
 
 	if (INTEL_GTT_GEN == 1)
@@ -356,6 +357,14 @@ static unsigned int intel_gtt_stolen_size(void)
 	pci_read_config_word(intel_private.bridge_dev,
 			     I830_GMCH_CTRL, &gmch_ctrl);
 
+	if (INTEL_GTT_GEN > 4 || IS_PINEVIEW)
+		overhead_entries = 0;
+	else
+		overhead_entries = intel_private.base.gtt_mappable_entries
+			/ 1024;
+
+	overhead_entries += 1; /* BIOS popup */
+
 	if (intel_private.bridge_dev->device == PCI_DEVICE_ID_INTEL_82830_HB ||
 	    intel_private.bridge_dev->device == PCI_DEVICE_ID_INTEL_82845G_HB) {
 		switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
@@ -490,7 +499,7 @@ static unsigned int intel_gtt_stolen_size(void)
 		stolen_size = 0;
 	}
 
-	return stolen_size;
+	return stolen_size/KB(4) - overhead_entries;
 }
 
 static void i965_adjust_pgetbl_size(unsigned int size_flag)
@@ -686,7 +695,7 @@ static int intel_gtt_init(void)
 
 	global_cache_flush();   /* FIXME: ? */
 
-	intel_private.base.stolen_size = intel_gtt_stolen_size();
+	intel_private.base.gtt_stolen_entries = intel_gtt_stolen_entries();
 
 	ret = intel_gtt_setup_scratch_page();
 	if (ret != 0) {
@@ -867,7 +876,8 @@ static int intel_fake_agp_configure(void)
 
 	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
 
-	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
+	for (i = intel_private.base.gtt_stolen_entries;
+			i < intel_private.base.gtt_total_entries; i++) {
 		intel_private.driver->write_entry(intel_private.scratch_page_dma,
 						  i, 0);
 	}
@@ -942,7 +952,17 @@ static int intel_fake_agp_insert_entries(struct agp_memory *mem,
 	if (mem->page_count == 0)
 		goto out;
 
-	if (pg_start + mem->page_count > intel_private.base.gtt_total_entries)
+	if (pg_start < intel_private.base.gtt_stolen_entries) {
+		dev_printk(KERN_DEBUG, &intel_private.pcidev->dev,
+			   "pg_start == 0x%.8lx, gtt_stolen_entries == 0x%.8x\n",
+			   pg_start, intel_private.base.gtt_stolen_entries);
+
+		dev_info(&intel_private.pcidev->dev,
+			 "trying to insert into local/stolen memory\n");
+		goto out_err;
+	}
+
+	if ((pg_start + mem->page_count) > intel_private.base.gtt_total_entries)
 		goto out_err;
 
 	if (type != mem->type)
@@ -991,6 +1011,12 @@ static int intel_fake_agp_remove_entries(struct agp_memory *mem,
 	if (mem->page_count == 0)
 		return 0;
 
+	if (pg_start < intel_private.base.gtt_stolen_entries) {
+		dev_info(&intel_private.pcidev->dev,
+			 "trying to disable local/stolen memory\n");
+		return -EINVAL;
+	}
+
 	if (intel_private.base.needs_dmar) {
 		intel_gtt_unmap_memory(mem->sg_list, mem->num_sg);
 		mem->sg_list = NULL;
@@ -1489,7 +1515,7 @@ int intel_gmch_probe(struct pci_dev *pdev,
 }
 EXPORT_SYMBOL(intel_gmch_probe);
 
-const struct intel_gtt *intel_gtt_get(void)
+struct intel_gtt *intel_gtt_get(void)
 {
 	return &intel_private.base;
 }
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f7b203..1655c39 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1049,7 +1049,7 @@ static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset)
 		pci_read_config_byte(pdev, 0x9c, &val);
 		base = val >> 3 << 27;
 	}
-	base -= dev_priv->mm.gtt->stolen_size;
+	base -= dev_priv->mm.gtt->gtt_stolen_entries << PAGE_SHIFT;
 #endif
 
 	return base + offset;
@@ -1173,7 +1173,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 	unsigned long prealloc_size, gtt_size, mappable_size;
 	int ret = 0;
 
-	prealloc_size = dev_priv->mm.gtt->stolen_size;
+	prealloc_size = dev_priv->mm.gtt->gtt_stolen_entries << PAGE_SHIFT;
 	gtt_size = dev_priv->mm.gtt->gtt_total_entries << PAGE_SHIFT;
 	mappable_size = dev_priv->mm.gtt->gtt_mappable_entries << PAGE_SHIFT;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30780f2..b41edf6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -532,7 +532,7 @@ typedef struct drm_i915_private {
 
 	struct {
 		/** Bridge to intel-gtt-ko */
-		const struct intel_gtt *gtt;
+		struct intel_gtt *gtt;
 		/** Memory allocator for GTT stolen memory */
 		struct drm_mm stolen;
 		/** Memory allocator for GTT */
diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 9e343c0..75c2088 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -2,10 +2,9 @@
 
 #ifndef _DRM_INTEL_GTT_H
 #define	_DRM_INTEL_GTT_H
-
-const struct intel_gtt {
-	/* Size of memory reserved for graphics by the BIOS */
-	unsigned int stolen_size;
+struct intel_gtt {
+	/* Number of stolen gtt entries at the beginning. */
+	unsigned int gtt_stolen_entries;
 	/* Total number of gtt entries. */
 	unsigned int gtt_total_entries;
 	/* Part of the gtt that is mappable by the cpu, for those chips where

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Chris Wilson]

On Mon, 20 Dec 2010 19:12:19 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> Commit c64f7ba5f10 "agp/intel: Remove confusion of stolen entries not stolen memory" caused a regression on my Intel G45 based system, using the VESA
> Xorg driver or uvesafb. I have not tried if i915 with KMS shows the same
> behaviour, but can try if necessary.

I'm very confused as to how this would have impacted the VESA video
driver. Any clues as to what VESA is doing? And what is the nature of
the regression?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Arnd Bergmann]

On Monday 20 December 2010 19:53:35 Chris Wilson wrote:
> On Mon, 20 Dec 2010 19:12:19 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> > Commit c64f7ba5f10 "agp/intel: Remove confusion of stolen entries not stolen memory" caused a regression on my Intel G45 based system, using the VESA
> > Xorg driver or uvesafb. I have not tried if i915 with KMS shows the same
> > behaviour, but can try if necessary.
> 
> I'm very confused as to how this would have impacted the VESA video
> driver. Any clues as to what VESA is doing?

Not the slightest idea. I don't understand what your code is doing
either, I only bisected it in order to get a running linux-next
kernel.

> And what is the nature of the regression?

The machine is very much alive, but the screen output is garbled. On
the text console, it shows a couple of characters around the cursor
position all over the screen. In X, it seems to be similar. The kdm
login screen gets shown as a nice pattern of colours, and they
change when I move the mouse. I can't identify anything visible on the
screen though.

Trying with i915 KMS next.

	Arnd

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Chris Wilson]

Also, which modules do you have loaded when using VESA? i.e. is the
i915.ko loaded, but in UMS mode (i915.modeset=0)?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Arnd Bergmann]

On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
> 
> Also, which modules do you have loaded when using VESA? i.e. is the
> i915.ko loaded, but in UMS mode (i915.modeset=0)?

This doesn't seem to matter, as far as I can tell, i915 can be loaded
or now.

I've seen the system crash once while loading i915 with
modeset=1 and my revert patch applied and backed it out.

After that, I could no longer even get i915 to do modesetting,
the ioremap in intel_opregion_setup now fails because reserve_memtype
decides that the opregion should be write-back when we ask for
an uncached mapping. That's probably an unrelated problem, but
I'm mentioning it anyway in case it's significant.

	Arnd

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Chris Wilson]

On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
> > 
> > Also, which modules do you have loaded when using VESA? i.e. is the
> > i915.ko loaded, but in UMS mode (i915.modeset=0)?
> 
> This doesn't seem to matter, as far as I can tell, i915 can be loaded
> or now.

Thanks, that rules out the likely explanation that we [i915] loaded the
GTT with some conflicting entries. Instead it is likely the initialisation
of the GTT to point to the scratch page that is triggering the problem.
Can you try disabling it with:

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 356f73e..238848e 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -867,11 +867,13 @@ static int intel_fake_agp_configure(void)
 
 	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
 
+#if 0
 	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
 		intel_private.driver->write_entry(intel_private.scratch_page_dma,
 						  i, 0);
 	}
 	readl(intel_private.gtt+i-1);	/* PCI Posting. */
+#endif
 
 	global_cache_flush();

> I've seen the system crash once while loading i915 with
> modeset=1 and my revert patch applied and backed it out.
> 
> After that, I could no longer even get i915 to do modesetting,
> the ioremap in intel_opregion_setup now fails because reserve_memtype
> decides that the opregion should be write-back when we ask for
> an uncached mapping. That's probably an unrelated problem, but
> I'm mentioning it anyway in case it's significant.

I hope not. But it sounds like we're in for a turbulent ride if ioremap is
failing in -next.

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Arnd Bergmann]

On Monday 20 December 2010 22:06:47 Chris Wilson wrote:
> On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
> > > 
> > > Also, which modules do you have loaded when using VESA? i.e. is the
> > > i915.ko loaded, but in UMS mode (i915.modeset=0)?
> > 
> > This doesn't seem to matter, as far as I can tell, i915 can be loaded
> > or now.
> 
> Thanks, that rules out the likely explanation that we [i915] loaded the
> GTT with some conflicting entries. Instead it is likely the initialisation
> of the GTT to point to the scratch page that is triggering the problem.
> Can you try disabling it with:
> 
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 356f73e..238848e 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -867,11 +867,13 @@ static int intel_fake_agp_configure(void)
>  
>  	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
>  
> +#if 0
>  	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
>  		intel_private.driver->write_entry(intel_private.scratch_page_dma,
>  						  i, 0);
>  	}
>  	readl(intel_private.gtt+i-1);	/* PCI Posting. */
> +#endif
>  
>  	global_cache_flush();

Yes, this works as well, good catch!

> > I've seen the system crash once while loading i915 with
> > modeset=1 and my revert patch applied and backed it out.
> > 
> > After that, I could no longer even get i915 to do modesetting,
> > the ioremap in intel_opregion_setup now fails because reserve_memtype
> > decides that the opregion should be write-back when we ask for
> > an uncached mapping. That's probably an unrelated problem, but
> > I'm mentioning it anyway in case it's significant.
> 
> I hope not. But it sounds like we're in for a turbulent ride if ioremap is
> failing in -next.

It only fails for the opregion. I feel I've done enough bisecting for today,
but it's certainly broken in -next and the ioremap works in 2.6.37-rc6.
Should the opregion actually be writeback cached? Maybe something is
wrong in reserve_memtype.

Loading i915 in -rc6 also crashes my system hard when modeset=1, but
that may be a hardware problem -- the same one that used to cause occasional
hangs with i915 KMS, forcing me to run X11 with the vesa driver.

	Arnd

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Dave Airlie]

On Tue, Dec 21, 2010 at 7:54 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 20 December 2010 22:06:47 Chris Wilson wrote:
>> On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
>> > >
>> > > Also, which modules do you have loaded when using VESA? i.e. is the
>> > > i915.ko loaded, but in UMS mode (i915.modeset=0)?
>> >
>> > This doesn't seem to matter, as far as I can tell, i915 can be loaded
>> > or now.
>>
>> Thanks, that rules out the likely explanation that we [i915] loaded the
>> GTT with some conflicting entries. Instead it is likely the initialisation
>> of the GTT to point to the scratch page that is triggering the problem.
>> Can you try disabling it with:
>>
>> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
>> index 356f73e..238848e 100644
>> --- a/drivers/char/agp/intel-gtt.c
>> +++ b/drivers/char/agp/intel-gtt.c
>> @@ -867,11 +867,13 @@ static int intel_fake_agp_configure(void)
>>
>>       agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
>>
>> +#if 0
>>       for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
>>               intel_private.driver->write_entry(intel_private.scratch_page_dma,
>>                                                 i, 0);
>>       }
>>       readl(intel_private.gtt+i-1);   /* PCI Posting. */
>> +#endif
>>
>>       global_cache_flush();
>
> Yes, this works as well, good catch!
>
>> > I've seen the system crash once while loading i915 with
>> > modeset=1 and my revert patch applied and backed it out.
>> >
>> > After that, I could no longer even get i915 to do modesetting,
>> > the ioremap in intel_opregion_setup now fails because reserve_memtype
>> > decides that the opregion should be write-back when we ask for
>> > an uncached mapping. That's probably an unrelated problem, but
>> > I'm mentioning it anyway in case it's significant.
>>
>> I hope not. But it sounds like we're in for a turbulent ride if ioremap is
>> failing in -next.
>
> It only fails for the opregion. I feel I've done enough bisecting for today,
> but it's certainly broken in -next and the ioremap works in 2.6.37-rc6.
> Should the opregion actually be writeback cached? Maybe something is
> wrong in reserve_memtype.
>
> Loading i915 in -rc6 also crashes my system hard when modeset=1, but
> that may be a hardware problem -- the same one that used to cause occasional
> hangs with i915 KMS, forcing me to run X11 with the vesa driver.

I wonder if the ACPI table mapping stuff is in -next yet.

As a first guess.

Dave.

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Frederic Weisbecker]

On Mon, Dec 20, 2010 at 09:06:47PM +0000, Chris Wilson wrote:
> On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
> > > 
> > > Also, which modules do you have loaded when using VESA? i.e. is the
> > > i915.ko loaded, but in UMS mode (i915.modeset=0)?
> > 
> > This doesn't seem to matter, as far as I can tell, i915 can be loaded
> > or now.
> 
> Thanks, that rules out the likely explanation that we [i915] loaded the
> GTT with some conflicting entries. Instead it is likely the initialisation
> of the GTT to point to the scratch page that is triggering the problem.
> Can you try disabling it with:

Hi,

I have the problem too with -rc1, and even with latest linus tree.

I too bisected back to:
"agp/intel: Remove confusion of stolen entries not stolen memory)"
(c64f7ba5f1006d8c20eacafecf98d4d00a6902a0)

Symptom is I see a big vertical cursor blinking in my screen and
nothing else. If something tries to be displayed it gets very messy.

[PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Chris Wilson]

We can only utilize the stolen portion of the GTT if we are in sole
charge of the hardware. This is only true if using GEM and KMS,
otherwise VESA continues to access stolen memory.

Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/char/agp/intel-gtt.c    |   18 ++++++++----------
 drivers/gpu/drm/i915/i915_gem.c |    6 ++++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 826ab09..cbbcaba 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -68,6 +68,7 @@ static struct _intel_private {
 	phys_addr_t gma_bus_addr;
 	u32 PGETBL_save;
 	u32 __iomem *gtt;		/* I915G */
+	bool clear_fake_agp; /* on first access via agp, fill with scratch */
 	int num_dcache_entries;
 	union {
 		void __iomem *i9xx_flush_page;
@@ -869,21 +870,12 @@ static int intel_fake_agp_free_gatt_table(struct agp_bridge_data *bridge)
 
 static int intel_fake_agp_configure(void)
 {
-	int i;
-
 	if (!intel_enable_gtt())
 	    return -EIO;
 
+	intel_private.clear_fake_agp = true;
 	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
 
-	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
-		intel_private.driver->write_entry(intel_private.scratch_page_dma,
-						  i, 0);
-	}
-	readl(intel_private.gtt+i-1);	/* PCI Posting. */
-
-	global_cache_flush();
-
 	return 0;
 }
 
@@ -945,6 +937,12 @@ static int intel_fake_agp_insert_entries(struct agp_memory *mem,
 {
 	int ret = -EINVAL;
 
+	if (intel_private.clear_fake_agp) {
+		intel_gtt_clear_range(intel_private.base.stolen_size / PAGE_SIZE,
+				      intel_private.base.gtt_total_entries);
+		intel_private.clear_fake_agp = false;
+	}
+
 	if (INTEL_GTT_GEN == 1 && type == AGP_DCACHE_MEMORY)
 		return i810_insert_dcache_entries(mem, pg_start, type);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 812b97b..6542e7d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -140,12 +140,14 @@ void i915_gem_do_init(struct drm_device *dev,
 {
 	drm_i915_private_t *dev_priv = dev->dev_private;
 
-	drm_mm_init(&dev_priv->mm.gtt_space, start,
-		    end - start);
+	drm_mm_init(&dev_priv->mm.gtt_space, start, end - start);
 
 	dev_priv->mm.gtt_total = end - start;
 	dev_priv->mm.mappable_gtt_total = min(end, mappable_end) - start;
 	dev_priv->mm.gtt_mappable_end = mappable_end;
+
+	/* Take over this portion of the GTT */
+	intel_gtt_clear_range(start / PAGE_SIZE, end / PAGE_SIZE);
 }
 
 int
-- 
1.7.2.3

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Jiri Olsa]

this patch fixed the issue for me

Tested-by: Jiri Olsa <jolsa@redhat.com>
if needed :)

thanks,
jirka


On Fri, Jan 21, 2011 at 10:58:57AM +0000, Chris Wilson wrote:
> We can only utilize the stolen portion of the GTT if we are in sole
> charge of the hardware. This is only true if using GEM and KMS,
> otherwise VESA continues to access stolen memory.
> 
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/char/agp/intel-gtt.c    |   18 ++++++++----------
>  drivers/gpu/drm/i915/i915_gem.c |    6 ++++--
>  2 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 826ab09..cbbcaba 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -68,6 +68,7 @@ static struct _intel_private {
>  	phys_addr_t gma_bus_addr;
>  	u32 PGETBL_save;
>  	u32 __iomem *gtt;		/* I915G */
> +	bool clear_fake_agp; /* on first access via agp, fill with scratch */
>  	int num_dcache_entries;
>  	union {
>  		void __iomem *i9xx_flush_page;
> @@ -869,21 +870,12 @@ static int intel_fake_agp_free_gatt_table(struct agp_bridge_data *bridge)
>  
>  static int intel_fake_agp_configure(void)
>  {
> -	int i;
> -
>  	if (!intel_enable_gtt())
>  	    return -EIO;
>  
> +	intel_private.clear_fake_agp = true;
>  	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
>  
> -	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
> -		intel_private.driver->write_entry(intel_private.scratch_page_dma,
> -						  i, 0);
> -	}
> -	readl(intel_private.gtt+i-1);	/* PCI Posting. */
> -
> -	global_cache_flush();
> -
>  	return 0;
>  }
>  
> @@ -945,6 +937,12 @@ static int intel_fake_agp_insert_entries(struct agp_memory *mem,
>  {
>  	int ret = -EINVAL;
>  
> +	if (intel_private.clear_fake_agp) {
> +		intel_gtt_clear_range(intel_private.base.stolen_size / PAGE_SIZE,
> +				      intel_private.base.gtt_total_entries);
> +		intel_private.clear_fake_agp = false;
> +	}
> +
>  	if (INTEL_GTT_GEN == 1 && type == AGP_DCACHE_MEMORY)
>  		return i810_insert_dcache_entries(mem, pg_start, type);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 812b97b..6542e7d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -140,12 +140,14 @@ void i915_gem_do_init(struct drm_device *dev,
>  {
>  	drm_i915_private_t *dev_priv = dev->dev_private;
>  
> -	drm_mm_init(&dev_priv->mm.gtt_space, start,
> -		    end - start);
> +	drm_mm_init(&dev_priv->mm.gtt_space, start, end - start);
>  
>  	dev_priv->mm.gtt_total = end - start;
>  	dev_priv->mm.mappable_gtt_total = min(end, mappable_end) - start;
>  	dev_priv->mm.gtt_mappable_end = mappable_end;
> +
> +	/* Take over this portion of the GTT */
> +	intel_gtt_clear_range(start / PAGE_SIZE, end / PAGE_SIZE);
>  }
>  
>  int
> -- 
> 1.7.2.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Frederic Weisbecker]

On Fri, Jan 21, 2011 at 10:58:57AM +0000, Chris Wilson wrote:
> We can only utilize the stolen portion of the GTT if we are in sole
> charge of the hardware. This is only true if using GEM and KMS,
> otherwise VESA continues to access stolen memory.
> 
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---


Applied on top of -rc2, it crashes the kernel early on
boot with an unhandle page request.
I don't have a serial line and it's too early for netconsole,
so I wrote the stacktrace I saw with printk delayed.

i830_write_entry
intel_gtt_clar_range
intel_fake_agp_insert_entries
agp_bind_memory
?agp_generic_alloc_pages
?intelfb_pci_register
?raw_spin_unlock_irqrestore
?local_pci_probe
?pci_device_probe
?driver_probe_device
?__driver_attach
?bus_for_each_dev
?driver_attach
?__driver_attach
?bus_add_driver
?pci_device_remove
?driver_register
?raw_spin_lock_init
?pci_register_driver
?intelfb_init
?do_one_initcall
?radix_tree_lookup
?irq_to_desc
?intelfb_init
?kernel_init

Given the ip (c12ccf12) it must be:

c12ccef0 <i830_write_entry>:
c12ccef0:       55                      push   %ebp
c12ccef1:       81 f9 01 00 01 00       cmp    $0x10001,%ecx
c12ccef7:       89 e5                   mov    %esp,%ebp
c12ccef9:       b9 01 00 00 00          mov    $0x1,%ecx
c12ccefe:       53                      push   %ebx
c12cceff:       bb 07 00 00 00          mov    $0x7,%ebx
c12ccf04:       0f 45 d9                cmovne %ecx,%ebx
c12ccf07:       09 c3                   or     %eax,%ebx
c12ccf09:       c1 e2 02                shl    $0x2,%edx
c12ccf0c:       03 15 8c 5e d5 c1       add    0xc1d55e8c,%edx
c12ccf12:       89 1a                   mov    %ebx,(%edx)  <--- here
c12ccf14:       5b                      pop    %ebx
c12ccf15:       5d                      pop    %ebp
c12ccf16:       c3                      ret    
c12ccf17:       89 f6                   mov    %esi,%esi
c12ccf19:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi

So, it seems to be the actual writel() that faults.

[PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Chris Wilson]

We can only utilize the stolen portion of the GTT if we are in sole
charge of the hardware. This is only true if using GEM and KMS,
otherwise VESA continues to access stolen memory.

Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---

Frederic, updated patch attached. The bug was that clear_range took (start,
count) and I was passing in (start, end) so we were dereferencing past the
end of the valid pages.
-Chris

---
 drivers/char/agp/intel-gtt.c        |   19 +++++++++----------
 drivers/gpu/drm/i915/i915_drv.h     |    5 ++++-
 drivers/gpu/drm/i915/i915_gem.c     |   10 +++++++---
 drivers/gpu/drm/i915/i915_gem_gtt.c |    4 ++++
 4 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 826ab09..fab3d32 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -68,6 +68,7 @@ static struct _intel_private {
 	phys_addr_t gma_bus_addr;
 	u32 PGETBL_save;
 	u32 __iomem *gtt;		/* I915G */
+	bool clear_fake_agp; /* on first access via agp, fill with scratch */
 	int num_dcache_entries;
 	union {
 		void __iomem *i9xx_flush_page;
@@ -869,21 +870,12 @@ static int intel_fake_agp_free_gatt_table(struct agp_bridge_data *bridge)
 
 static int intel_fake_agp_configure(void)
 {
-	int i;
-
 	if (!intel_enable_gtt())
 	    return -EIO;
 
+	intel_private.clear_fake_agp = true;
 	agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
 
-	for (i = 0; i < intel_private.base.gtt_total_entries; i++) {
-		intel_private.driver->write_entry(intel_private.scratch_page_dma,
-						  i, 0);
-	}
-	readl(intel_private.gtt+i-1);	/* PCI Posting. */
-
-	global_cache_flush();
-
 	return 0;
 }
 
@@ -945,6 +937,13 @@ static int intel_fake_agp_insert_entries(struct agp_memory *mem,
 {
 	int ret = -EINVAL;
 
+	if (intel_private.clear_fake_agp) {
+		int start = intel_private.base.stolen_size / PAGE_SIZE;
+		int end = intel_private.base.gtt_mappable_entries;
+		intel_gtt_clear_range(start, end - start);
+		intel_private.clear_fake_agp = false;
+	}
+
 	if (INTEL_GTT_GEN == 1 && type == AGP_DCACHE_MEMORY)
 		return i810_insert_dcache_entries(mem, pg_start, type);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5969f46..a0149c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -543,8 +543,11 @@ typedef struct drm_i915_private {
 		/** List of all objects in gtt_space. Used to restore gtt
 		 * mappings on resume */
 		struct list_head gtt_list;
-		/** End of mappable part of GTT */
+
+		/** Usable portion of the GTT for GEM */
+		unsigned long gtt_start;
 		unsigned long gtt_mappable_end;
+		unsigned long gtt_end;
 
 		struct io_mapping *gtt_mapping;
 		int gtt_mtrr;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 812b97b..b1d7461 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -140,12 +140,16 @@ void i915_gem_do_init(struct drm_device *dev,
 {
 	drm_i915_private_t *dev_priv = dev->dev_private;
 
-	drm_mm_init(&dev_priv->mm.gtt_space, start,
-		    end - start);
+	drm_mm_init(&dev_priv->mm.gtt_space, start, end - start);
 
+	dev_priv->mm.gtt_start = start;
+	dev_priv->mm.gtt_mappable_end = mappable_end;
+	dev_priv->mm.gtt_end = end;
 	dev_priv->mm.gtt_total = end - start;
 	dev_priv->mm.mappable_gtt_total = min(end, mappable_end) - start;
-	dev_priv->mm.gtt_mappable_end = mappable_end;
+
+	/* Take over this portion of the GTT */
+	intel_gtt_clear_range(start / PAGE_SIZE, end / PAGE_SIZE);
 }
 
 int
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 70433ae..9c41f54 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -34,6 +34,10 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct drm_i915_gem_object *obj;
 
+	/* First fill with scratch pages */
+	intel_gtt_clear_range(dev_priv->mm.gtt_start / PAGE_SIZE,
+			      dev_priv->mm.gtt_end / PAGE_SIZE);
+
 	list_for_each_entry(obj, &dev_priv->mm.gtt_list, gtt_list) {
 		i915_gem_clflush_object(obj);
 
-- 
1.7.2.3

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Frederic Weisbecker]

On Sun, Jan 23, 2011 at 11:01:12AM +0000, Chris Wilson wrote:
> We can only utilize the stolen portion of the GTT if we are in sole
> charge of the hardware. This is only true if using GEM and KMS,
> otherwise VESA continues to access stolen memory.
> 
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
> Tested-by: Jiri Olsa <jolsa@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> 
> Frederic, updated patch attached. The bug was that clear_range took (start,
> count) and I was passing in (start, end) so we were dereferencing past the
> end of the valid pages.
> -Chris

Works well, thank you :)

Tested-by: Frederic Weisbecker <fweisbec@gmail.com>

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Hugh Dickins]

On Sun, 23 Jan 2011, Frederic Weisbecker wrote:
> On Sun, Jan 23, 2011 at 11:01:12AM +0000, Chris Wilson wrote:
> > We can only utilize the stolen portion of the GTT if we are in sole
> > charge of the hardware. This is only true if using GEM and KMS,
> > otherwise VESA continues to access stolen memory.
> > 
> > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > Reported-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Tested-by: Jiri Olsa <jolsa@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > 
> > Frederic, updated patch attached. The bug was that clear_range took (start,
> > count) and I was passing in (start, end) so we were dereferencing past the
> > end of the valid pages.
> > -Chris
> 
> Works well, thank you :)
> 
> Tested-by: Frederic Weisbecker <fweisbec@gmail.com>

It improved matters for me (on a two-year-old Aspire One which had been
showing the same few characters of text repeated a large number of times
across the screen with 2.6.38-rc1 and rc2): the VESA framebuffer showing
good text at last.  But crashed once I tried startx, netconsole showing:

BUG: unable to handle kernel paging request at c00c0000
IP: [<802dcd32>] i830_write_entry+0x22/0x30
*pdpt = 0000000000730001 *pde = 000000003e4a0067 *pte = 0000000000000000 
Oops: 0002 [#1] PREEMPT SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.4/resource

Pid: 2908, comm: X Not tainted 2.6.38-rc2+ #16         /AOA110
EIP: 0060:[<802dcd32>] EFLAGS: 00213286 CPU: 0
EIP is at i830_write_entry+0x22/0x30
EAX: 3e4a1000 EBX: 3e4a1001 ECX: 00000001 EDX: c00c0000
ESI: 00010001 EDI: 000107b4 EBP: bbc45e00 ESP: bbc45dfc
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process X (pid: 2908, ti=bbc44000 task=bdb62370 task.ti=bbc44000)
Stack:
 8055e7d4 bbc45e14 802dce45 be56a000 007bf000 0fff5000 bbc45e30 80306720
 0f836000 0fff5000 be4ca800 be4ca814 40106453 bbc45e48 80306776 0fff5000
 bbc45e94 bbc43380 be4ca800 bbc45f20 802e6a7e 00000001 8061e704 8055ef16
Call Trace:
 [<802dce45>] intel_gtt_clear_range+0x25/0x50
 [<80306720>] i915_gem_do_init+0x70/0x80
 [<80306776>] i915_gem_init_ioctl+0x46/0x70
 [<802e6a7e>] drm_ioctl+0x1ce/0x420
 [<80306730>] ? i915_gem_init_ioctl+0x0/0x70
 [<8018b1d1>] ? handle_pte_fault+0x81/0x7b0
 [<8017a325>] ? __free_pages+0x35/0x40
 [<8018c996>] ? handle_mm_fault+0xb6/0xf0
 [<802e68b0>] ? drm_ioctl+0x0/0x420
 [<801b2bcc>] do_vfs_ioctl+0x7c/0x580
 [<8011e543>] ? do_page_fault+0x173/0x3d0
 [<801a3417>] ? filp_close+0x47/0x70
 [<801b3109>] sys_ioctl+0x39/0x70
 [<80102b90>] sysenter_do_call+0x12/0x26
 [<80520000>] ? pci_scan_bridge+0x29b/0x414
Code: 26 00 8d bc 27 00 00 00 00 55 81 f9 01 00 01 00 89 e5 b9 01 00 00 00 53 bb 07 00 00 00 0f 45 d9 09 c3 c1 e2 02 03 15 34 bf 79 80 <89> 1a 5b 5d c3 89 f6 8d bc 27 00 00 00 00 a1 a0 be 79 80 55 89 
EIP: [<802dcd32>] i830_write_entry+0x22/0x30 SS:ESP 0068:bbc45dfc
CR2: 00000000c00c0000
---[ end trace 5eaf99b7f1ac958b ]---

But your comment above on clear_range was very helpful: your latest
patch fixed one call, but left two others unfixed.  Please fold in:

--- a/drivers/gpu/drm/i915/i915_gem_gtt.c	2011-01-23 11:52:47.350395154 -0800
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c	2011-01-23 20:13:01.457805176 -0800
@@ -36,7 +36,7 @@ void i915_gem_restore_gtt_mappings(struc
 
 	/* First fill with scratch pages */
 	intel_gtt_clear_range(dev_priv->mm.gtt_start / PAGE_SIZE,
-			      dev_priv->mm.gtt_end / PAGE_SIZE);
+		(dev_priv->mm.gtt_end - dev_priv->mm.gtt_start) / PAGE_SIZE);
 
 	list_for_each_entry(obj, &dev_priv->mm.gtt_list, gtt_list) {
 		i915_gem_clflush_object(obj);
--- a/drivers/gpu/drm/i915/i915_gem.c	2011-01-23 11:52:47.346395154 -0800
+++ b/drivers/gpu/drm/i915/i915_gem.c	2011-01-23 20:10:58.081193280 -0800
@@ -149,7 +149,7 @@ void i915_gem_do_init(struct drm_device
 	dev_priv->mm.mappable_gtt_total = min(end, mappable_end) - start;
 
 	/* Take over this portion of the GTT */
-	intel_gtt_clear_range(start / PAGE_SIZE, end / PAGE_SIZE);
+	intel_gtt_clear_range(start / PAGE_SIZE, (end - start) / PAGE_SIZE);
 }
 
 int

With that added into the mix, starting X then crashed with
i915_get_vblank_timestamp in the trace: which directed me to other
mailthreads, from which I picked up first your "Increase the amount
of defense" patch, which got X working at last, with reports of
[drm:i915_get_vblank_timestamp] *ERROR* Invalid crtc 0
and then your "Disable high-precision vblank timestamping for UMS"
patch (I'd forgotten I was using UMS), which equally got X working.

So it's now running with your revised patch to Frederic, my correction
above, and your UMS vblank fix to Chris Clayton (looks like I don't
need the interrupts one).

On this laptop I'm typing from (GM965 with KMS), I've had no trouble
getting X up; but when typing in one of the xterms, typed characters
often stop echoing, until I shift to a different window, whereupon
they appear.  This condition cleared (for a while) by switching to
VESA fb console and back; no such problem observed on that console.

Does that sound familiar?  I have no evidence whatever that i915 is
to blame here.  Several times I tried bisecting last week, but each
attempt ended up in a nonsensical place, because the effect does not
occur to order.  So I'd sometimes mark a bisection point as good when
I guess it must actually have been bad.  Perhaps it's a matter of
timing or an uninitialized variable.  But while I'm here, worth asking
if that behaviour sounds like anything you might be responsible for?

Thanks,
Hugh

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Chris Wilson]

On Sun, 23 Jan 2011 23:40:41 -0800 (PST), Hugh Dickins <hughd@google.com> wrote:
> It improved matters for me (on a two-year-old Aspire One which had been
> showing the same few characters of text repeated a large number of times
> across the screen with 2.6.38-rc1 and rc2): the VESA framebuffer showing
> good text at last.  But crashed once I tried startx, netconsole showing:

[snip]
 
> But your comment above on clear_range was very helpful: your latest
> patch fixed one call, but left two others unfixed.  Please fold in:
> 
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c	2011-01-23 11:52:47.350395154 -0800
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c	2011-01-23 20:13:01.457805176 -0800
> @@ -36,7 +36,7 @@ void i915_gem_restore_gtt_mappings(struc
>  
>  	/* First fill with scratch pages */
>  	intel_gtt_clear_range(dev_priv->mm.gtt_start / PAGE_SIZE,
> -			      dev_priv->mm.gtt_end / PAGE_SIZE);
> +		(dev_priv->mm.gtt_end - dev_priv->mm.gtt_start) / PAGE_SIZE);
>  
>  	list_for_each_entry(obj, &dev_priv->mm.gtt_list, gtt_list) {
>  		i915_gem_clflush_object(obj);
> --- a/drivers/gpu/drm/i915/i915_gem.c	2011-01-23 11:52:47.346395154 -0800
> +++ b/drivers/gpu/drm/i915/i915_gem.c	2011-01-23 20:10:58.081193280 -0800
> @@ -149,7 +149,7 @@ void i915_gem_do_init(struct drm_device
>  	dev_priv->mm.mappable_gtt_total = min(end, mappable_end) - start;
>  
>  	/* Take over this portion of the GTT */
> -	intel_gtt_clear_range(start / PAGE_SIZE, end / PAGE_SIZE);
> +	intel_gtt_clear_range(start / PAGE_SIZE, (end - start) / PAGE_SIZE);
>  }

The patch I finally applied did include those fixes. After making the
mistake once, I had to double check the other call sites.

> On this laptop I'm typing from (GM965 with KMS), I've had no trouble
> getting X up; but when typing in one of the xterms, typed characters
> often stop echoing, until I shift to a different window, whereupon
> they appear.  This condition cleared (for a while) by switching to
> VESA fb console and back; no such problem observed on that console.
> 
> Does that sound familiar?  I have no evidence whatever that i915 is
> to blame here.  Several times I tried bisecting last week, but each
> attempt ended up in a nonsensical place, because the effect does not
> occur to order.  So I'd sometimes mark a bisection point as good when
> I guess it must actually have been bad.  Perhaps it's a matter of
> timing or an uninitialized variable.  But while I'm here, worth asking
> if that behaviour sounds like anything you might be responsible for?

Sounds suspiciously like the batch buffer is not being dispatched and
flushed to the scanout. A very similar bug was recently fixed for
xf86-video-intel 2.14.0 which was causing deferred output. 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Arnd Bergmann]

On Monday 24 January 2011 11:10:20 Chris Wilson wrote:
> The patch I finally applied did include those fixes. After making the
> mistake once, I had to double check the other call sites.

Not sure which repository you applied it to, but 2.6.38-rc2 with the two
patches applied works for me.

Tested-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Hugh Dickins]

Sorry, this is now abount vblank or scanout rather than stolen entries.

On Mon, 24 Jan 2011, Chris Wilson wrote:
> On Sun, 23 Jan 2011 23:40:41 -0800 (PST), Hugh Dickins <hughd@google.com> wrote:
> 
> > On this laptop I'm typing from (GM965 with KMS), I've had no trouble
> > getting X up; but when typing in one of the xterms, typed characters
> > often stop echoing, until I shift to a different window, whereupon
> > they appear.  This condition cleared (for a while) by switching to
> > VESA fb console and back; no such problem observed on that console.
> > 
> > Does that sound familiar?  I have no evidence whatever that i915 is
> > to blame here.  Several times I tried bisecting last week, but each
> > attempt ended up in a nonsensical place, because the effect does not
> > occur to order.  So I'd sometimes mark a bisection point as good when
> > I guess it must actually have been bad.  Perhaps it's a matter of
> > timing or an uninitialized variable.  But while I'm here, worth asking
> > if that behaviour sounds like anything you might be responsible for?
> 
> Sounds suspiciously like the batch buffer is not being dispatched and
> flushed to the scanout. A very similar bug was recently fixed for
> xf86-video-intel 2.14.0 which was causing deferred output. 

I made a more patient bisection during the week, on x86_64 which
seemed more consistent than i386, and this time it converged sensibly:
to commit 0af7e4dff50454905092d468e91c1ef92e10e6b4
drm/i915: Add support for precise vblank timestamping (v2)

Which kindly notes in its commit message:
    This code has been only tested on a HP-Mini Netbook with
    Atom processor and Intel 945GME gpu. The codepath for
    (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
    has not been tested so far due to lack of hardware.
so not surprising that it doesn't work on GM965.

I'm now running with this silly revert:

--- a/drivers/gpu/drm/i915/i915_drv.c	2011-01-18 22:04:29.000000000 -0800
+++ b/drivers/gpu/drm/i915/i915_drv.c	2011-01-24 19:35:51.000000000 -0800
@@ -674,8 +674,8 @@ static struct drm_driver driver = {
 	.device_is_agp = i915_driver_device_is_agp,
 	.enable_vblank = i915_enable_vblank,
 	.disable_vblank = i915_disable_vblank,
-	.get_vblank_timestamp = i915_get_vblank_timestamp,
-	.get_scanout_position = i915_get_crtc_scanoutpos,
+	.get_vblank_timestamp = NULL /* i915_get_vblank_timestamp */,
+	.get_scanout_position = NULL /* i915_get_crtc_scanoutpos */,
 	.irq_preinstall = i915_driver_irq_preinstall,
 	.irq_postinstall = i915_driver_irq_postinstall,
 	.irq_uninstall = i915_driver_irq_uninstall,

which makes 2.6.38-rc usable; though I do believe that I've seen
the same issue (unflushed text) occur a couple of times since, much
too rare to bisect or get upset by, but indicative of some remaining bug.

Hugh

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Mario Kleiner]

On Jan 28, 2011, at 11:00 PM, Hugh Dickins wrote:

> Sorry, this is now abount vblank or scanout rather than stolen  
> entries.
>
> On Mon, 24 Jan 2011, Chris Wilson wrote:
>> On Sun, 23 Jan 2011 23:40:41 -0800 (PST), Hugh Dickins  
>> <hughd@google.com> wrote:
>>
>>> On this laptop I'm typing from (GM965 with KMS), I've had no trouble
>>> getting X up; but when typing in one of the xterms, typed characters
>>> often stop echoing, until I shift to a different window, whereupon
>>> they appear.  This condition cleared (for a while) by switching to
>>> VESA fb console and back; no such problem observed on that console.
>>>
>>> Does that sound familiar?  I have no evidence whatever that i915 is
>>> to blame here.  Several times I tried bisecting last week, but each
>>> attempt ended up in a nonsensical place, because the effect does not
>>> occur to order.  So I'd sometimes mark a bisection point as good  
>>> when
>>> I guess it must actually have been bad.  Perhaps it's a matter of
>>> timing or an uninitialized variable.  But while I'm here, worth  
>>> asking
>>> if that behaviour sounds like anything you might be responsible for?
>>
>> Sounds suspiciously like the batch buffer is not being dispatched and
>> flushed to the scanout. A very similar bug was recently fixed for
>> xf86-video-intel 2.14.0 which was causing deferred output.
>
> I made a more patient bisection during the week, on x86_64 which
> seemed more consistent than i386, and this time it converged sensibly:
> to commit 0af7e4dff50454905092d468e91c1ef92e10e6b4
> drm/i915: Add support for precise vblank timestamping (v2)
>
> Which kindly notes in its commit message:
>     This code has been only tested on a HP-Mini Netbook with
>     Atom processor and Intel 945GME gpu. The codepath for
>     (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
>     has not been tested so far due to lack of hardware.
> so not surprising that it doesn't work on GM965.
>
> I'm now running with this silly revert:
>
> --- a/drivers/gpu/drm/i915/i915_drv.c	2011-01-18 22:04:29.000000000  
> -0800
> +++ b/drivers/gpu/drm/i915/i915_drv.c	2011-01-24 19:35:51.000000000  
> -0800
> @@ -674,8 +674,8 @@ static struct drm_driver driver = {
>  	.device_is_agp = i915_driver_device_is_agp,
>  	.enable_vblank = i915_enable_vblank,
>  	.disable_vblank = i915_disable_vblank,
> -	.get_vblank_timestamp = i915_get_vblank_timestamp,
> -	.get_scanout_position = i915_get_crtc_scanoutpos,
> +	.get_vblank_timestamp = NULL /* i915_get_vblank_timestamp */,
> +	.get_scanout_position = NULL /* i915_get_crtc_scanoutpos */,
>  	.irq_preinstall = i915_driver_irq_preinstall,
>  	.irq_postinstall = i915_driver_irq_postinstall,
>  	.irq_uninstall = i915_driver_irq_uninstall,
>
> which makes 2.6.38-rc usable; though I do believe that I've seen
> the same issue (unflushed text) occur a couple of times since, much
> too rare to bisect or get upset by, but indicative of some  
> remaining bug.
>

Hi,

just skimmed through the archives of this thread. Do i understand  
correctly that the problem that gets fixed by your revert is that

<snip>
>>> when typing in one of the xterms, typed characters
>>> often stop echoing, until I shift to a different window, whereupon
>>> they appear.  This condition cleared (for a while) by switching to
>>> VESA fb console and back; no such problem observed on that console.
>>
</snip>

Is this with desktop composition enabled? Do things like glxgears in  
a window work correctly? If desktop composition is off?

For a softer fix to the problem you can revert your revert and  
disable use of those functions by the drm core via:

echo 0 > /sys/modules/drm/parameters/timestamp_precision_usec

But can you run it with echo 7 >  /sys/modules/drm/parameters/debug

and show me bits of the syslog output when the problem happens?  
Especially output from the functions  
"drm_calc_vbltimestamp_from_scanoutpos" and "drm_handle_vblank" and  
maybe for "vblank_disable_fn", "drm_update_vblank_count", and  
"drm_vblank_get".

Those functions (are supposed to) compute exact timestamps of start  
of scanout after each vblank. If they get disabled via the "echo  
0 ..." then a do_gettimeofday() is called for a crude approximation  
of start of scanout. The computed timestamps are returned to clients  
which want them (oml_sync_control extension). I doubt that many apps  
use that extension or its timestamps already, especially not desktop  
compositors etc., so i wouldn't expect trouble from such wrong  
timestamps.

However, the timestamps are also used in drm_handle_vblank() in  
drivers/gpu/drm/drm_irq.c at each vblank irq to detect and filter out  
redundant vblank irq's to avoid miscounting of vblanks (observed on  
some Radeon's). If the kms driver would deliver a grossly wrong  
timestamp and something would be wrong in the implementation of that  
filtering, it could happen that the vblank counter doesn't get  
incremented -> delivery of a vblank event to the x-server gets  
delayed -> a swapbuffer operation on a composited desktop gets  
delayed -> content of a redirected window updates only with a delay.

The relevant check which could prevent vblank counter increments and  
delay vblank event delivery to the x-server in drm_handle_vblank()  
would be:

         if (abs(diff_ns) > DRM_REDUNDANT_VBLIRQ_THRESH_NS) {

The condition should be satisfied if everything works correctly, but  
also if timestamps would be grossly wrong, thereby leading to a  
larger than 1 msec positive or negative diff_ns. s64 diff_ns is a  
signed 64 bit integer. Could abs(diff_ns) somehow miscompute for  
large 64 bit numbers?

All guesswork, the syslog output should tell us more if the  
timestamping is really involved in the problem.

thanks,
-mario

*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mario.kleiner@tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Hugh Dickins]

On Fri, Jan 28, 2011 at 6:59 PM, Mario Kleiner
<mario.kleiner@tuebingen.mpg.de> wrote:
> On Jan 28, 2011, at 11:00 PM, Hugh Dickins wrote:
>
>> Sorry, this is now abount vblank or scanout rather than stolen entries.
>>
>> On Mon, 24 Jan 2011, Chris Wilson wrote:
>>>
>>> On Sun, 23 Jan 2011 23:40:41 -0800 (PST), Hugh Dickins <hughd@google.com>
>>> wrote:
>>>
>>>> On this laptop I'm typing from (GM965 with KMS), I've had no trouble
>>>> getting X up; but when typing in one of the xterms, typed characters
>>>> often stop echoing, until I shift to a different window, whereupon
>>>> they appear.  This condition cleared (for a while) by switching to
>>>> VESA fb console and back; no such problem observed on that console.
>>>>
>>>> Does that sound familiar?  I have no evidence whatever that i915 is
>>>> to blame here.  Several times I tried bisecting last week, but each
>>>> attempt ended up in a nonsensical place, because the effect does not
>>>> occur to order.  So I'd sometimes mark a bisection point as good when
>>>> I guess it must actually have been bad.  Perhaps it's a matter of
>>>> timing or an uninitialized variable.  But while I'm here, worth asking
>>>> if that behaviour sounds like anything you might be responsible for?
>>>
>>> Sounds suspiciously like the batch buffer is not being dispatched and
>>> flushed to the scanout. A very similar bug was recently fixed for
>>> xf86-video-intel 2.14.0 which was causing deferred output.
>>
>> I made a more patient bisection during the week, on x86_64 which
>> seemed more consistent than i386, and this time it converged sensibly:
>> to commit 0af7e4dff50454905092d468e91c1ef92e10e6b4
>> drm/i915: Add support for precise vblank timestamping (v2)
>>
>> Which kindly notes in its commit message:
>>    This code has been only tested on a HP-Mini Netbook with
>>    Atom processor and Intel 945GME gpu. The codepath for
>>    (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
>>    has not been tested so far due to lack of hardware.
>> so not surprising that it doesn't work on GM965.
>>
>> I'm now running with this silly revert:
>>
>> --- a/drivers/gpu/drm/i915/i915_drv.c   2011-01-18 22:04:29.000000000
>> -0800
>> +++ b/drivers/gpu/drm/i915/i915_drv.c   2011-01-24 19:35:51.000000000
>> -0800
>> @@ -674,8 +674,8 @@ static struct drm_driver driver = {
>>        .device_is_agp = i915_driver_device_is_agp,
>>        .enable_vblank = i915_enable_vblank,
>>        .disable_vblank = i915_disable_vblank,
>> -       .get_vblank_timestamp = i915_get_vblank_timestamp,
>> -       .get_scanout_position = i915_get_crtc_scanoutpos,
>> +       .get_vblank_timestamp = NULL /* i915_get_vblank_timestamp */,
>> +       .get_scanout_position = NULL /* i915_get_crtc_scanoutpos */,
>>        .irq_preinstall = i915_driver_irq_preinstall,
>>        .irq_postinstall = i915_driver_irq_postinstall,
>>        .irq_uninstall = i915_driver_irq_uninstall,
>>
>> which makes 2.6.38-rc usable; though I do believe that I've seen
>> the same issue (unflushed text) occur a couple of times since, much
>> too rare to bisect or get upset by, but indicative of some remaining bug.
>>
>
> Hi,
>
> just skimmed through the archives of this thread. Do i understand correctly
> that the problem that gets fixed by your revert is that
>
> <snip>
>>>>
>>>> when typing in one of the xterms, typed characters
>>>> often stop echoing, until I shift to a different window, whereupon
>>>> they appear.  This condition cleared (for a while) by switching to
>>>> VESA fb console and back; no such problem observed on that console.
>>>
> </snip>

Yes, that's the problem that's fixed by the little revert patch I
posted last time.
Sorry, this thread started out with other problems, then I asked Chris
if this might also be an i915 issue.

>
> Is this with desktop composition enabled?

Not that I'm aware of.  The see-through business.  I'm just using four
xterms in fvwm2 on openSUSE11.2 with own kernel.  If desktop
composition might be enabled by the X startup script, expecting me to
use gnome rather than fvwm2, then I suppose it might be enabled; but
it's not something I've chosen to turn on.  What should I check to
answer you for sure, if it matters?

> Do things like glxgears in a
> window work correctly? If desktop composition is off?

Yes, glxgears appears to work correctly: I type "glxgears" at the
xterm shell prompt, those letters and carriage return are not echoed
back to me, but the glxgears window appears with the gears turning
correctly, then I close that window, type more and again my typing is
not echoed.

>
> For a softer fix to the problem you can revert your revert and disable use
> of those functions by the drm core via:
>
> echo 0 > /sys/modules/drm/parameters/timestamp_precision_usec

Thanks for the info.  ("module" rather than "modules".)

>
> But can you run it with echo 7 >  /sys/modules/drm/parameters/debug
>
> and show me bits of the syslog output when the problem happens? Especially
> output from the functions "drm_calc_vbltimestamp_from_scanoutpos" and
> "drm_handle_vblank" and maybe for "vblank_disable_fn",
> "drm_update_vblank_count", and "drm_vblank_get".

Wow, millions of lines of output (partly because I couldn't see the
typo that had prevented me from turning it off after a few seconds).
I rebuilt the kernel with the DRM_DEBUG at the head of drm_ioctl()
edited out: that generates so many messages (cmd=0x400c645f
mostly, but some cmd=0x6458)  that the logging cannot keep up, and
hardly gets a chance to print anything else.

But even with that edited out, nothing from any of the functions that
you suggest: only, and perhaps this is the problem?,
[drm:i915_driver_irq_handler}, pipe a underrun
about 64 times per second.

I just tried setting the debug to 7 for a few seconds on 2.6.37, where
I see no problem: I appear to get the "pipe a underrun" messages with
that too; and the drm_ioctl messages, but much much fewer of them.
Though I've been veering between i386 and x86_64 in these tests, so
keep that in mind if what I'm saying makes no sense: the huge number
of drm_ioctls was with 2.6.36-rc2 (plus some of Chris's fixes) on
i386; the 64 underruns per second was with 2.6.36-rc2 (plus some of
Chris's fixes, minus the drm_ioctl DRM_DEBUG) on x86_64; the underruns
and reasonable number of drm_ioctls was with 2.6.37 on x86_64.

On this laptop I'm working with
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_HZ_250=y
CONFIG_HZ=250
if those have any relevance.

Thanks,
Hugh

>
> Those functions (are supposed to) compute exact timestamps of start of
> scanout after each vblank. If they get disabled via the "echo 0 ..." then a
> do_gettimeofday() is called for a crude approximation of start of scanout.
> The computed timestamps are returned to clients which want them
> (oml_sync_control extension). I doubt that many apps use that extension or
> its timestamps already, especially not desktop compositors etc., so i
> wouldn't expect trouble from such wrong timestamps.
>
> However, the timestamps are also used in drm_handle_vblank() in
> drivers/gpu/drm/drm_irq.c at each vblank irq to detect and filter out
> redundant vblank irq's to avoid miscounting of vblanks (observed on some
> Radeon's). If the kms driver would deliver a grossly wrong timestamp and
> something would be wrong in the implementation of that filtering, it could
> happen that the vblank counter doesn't get incremented -> delivery of a
> vblank event to the x-server gets delayed -> a swapbuffer operation on a
> composited desktop gets delayed -> content of a redirected window updates
> only with a delay.
>
> The relevant check which could prevent vblank counter increments and delay
> vblank event delivery to the x-server in drm_handle_vblank() would be:
>
>        if (abs(diff_ns) > DRM_REDUNDANT_VBLIRQ_THRESH_NS) {
>
> The condition should be satisfied if everything works correctly, but also if
> timestamps would be grossly wrong, thereby leading to a larger than 1 msec
> positive or negative diff_ns. s64 diff_ns is a signed 64 bit integer. Could
> abs(diff_ns) somehow miscompute for large 64 bit numbers?
>
> All guesswork, the syslog output should tell us more if the timestamping is
> really involved in the problem.
>
> thanks,
> -mario
>
> *********************************************************************
> Mario Kleiner
> Max Planck Institute for Biological Cybernetics
> Spemannstr. 38
> 72076 Tuebingen
> Germany
>
> e-mail: mario.kleiner@tuebingen.mpg.de
> office: +49 (0)7071/601-1623
> fax:    +49 (0)7071/601-616
> www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
> *********************************************************************
> "For a successful technology, reality must take precedence
> over public relations, for Nature cannot be fooled."
> (Richard Feynman)
>
>

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Mario Kleiner]

On Jan 30, 2011, at 1:28 AM, Hugh Dickins wrote:

> On Fri, Jan 28, 2011 at 6:59 PM, Mario Kleiner
> <mario.kleiner@tuebingen.mpg.de> wrote:
>> On Jan 28, 2011, at 11:00 PM, Hugh Dickins wrote:
>>
>>> Sorry, this is now abount vblank or scanout rather than stolen  
>>> entries.
>>>
>>> On Mon, 24 Jan 2011, Chris Wilson wrote:
>>>>
>>>> On Sun, 23 Jan 2011 23:40:41 -0800 (PST), Hugh Dickins  
>>>> <hughd@google.com>
>>>> wrote:
>>>>
>>>>> On this laptop I'm typing from (GM965 with KMS), I've had no  
>>>>> trouble
>>>>> getting X up; but when typing in one of the xterms, typed  
>>>>> characters
>>>>> often stop echoing, until I shift to a different window, whereupon
>>>>> they appear.  This condition cleared (for a while) by switching to
>>>>> VESA fb console and back; no such problem observed on that  
>>>>> console.
>>>>>
>>>>> Does that sound familiar?  I have no evidence whatever that  
>>>>> i915 is
>>>>> to blame here.  Several times I tried bisecting last week, but  
>>>>> each
>>>>> attempt ended up in a nonsensical place, because the effect  
>>>>> does not
>>>>> occur to order.  So I'd sometimes mark a bisection point as  
>>>>> good when
>>>>> I guess it must actually have been bad.  Perhaps it's a matter of
>>>>> timing or an uninitialized variable.  But while I'm here, worth  
>>>>> asking
>>>>> if that behaviour sounds like anything you might be responsible  
>>>>> for?
>>>>
>>>> Sounds suspiciously like the batch buffer is not being  
>>>> dispatched and
>>>> flushed to the scanout. A very similar bug was recently fixed for
>>>> xf86-video-intel 2.14.0 which was causing deferred output.
>>>
>>> I made a more patient bisection during the week, on x86_64 which
>>> seemed more consistent than i386, and this time it converged  
>>> sensibly:
>>> to commit 0af7e4dff50454905092d468e91c1ef92e10e6b4
>>> drm/i915: Add support for precise vblank timestamping (v2)
>>>
>>> Which kindly notes in its commit message:
>>>    This code has been only tested on a HP-Mini Netbook with
>>>    Atom processor and Intel 945GME gpu. The codepath for
>>>    (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
>>>    has not been tested so far due to lack of hardware.
>>> so not surprising that it doesn't work on GM965.
>>>
>>> I'm now running with this silly revert:
>>>
>>> --- a/drivers/gpu/drm/i915/i915_drv.c   2011-01-18  
>>> 22:04:29.000000000
>>> -0800
>>> +++ b/drivers/gpu/drm/i915/i915_drv.c   2011-01-24  
>>> 19:35:51.000000000
>>> -0800
>>> @@ -674,8 +674,8 @@ static struct drm_driver driver = {
>>>        .device_is_agp = i915_driver_device_is_agp,
>>>        .enable_vblank = i915_enable_vblank,
>>>        .disable_vblank = i915_disable_vblank,
>>> -       .get_vblank_timestamp = i915_get_vblank_timestamp,
>>> -       .get_scanout_position = i915_get_crtc_scanoutpos,
>>> +       .get_vblank_timestamp = NULL /* i915_get_vblank_timestamp  
>>> */,
>>> +       .get_scanout_position = NULL /* i915_get_crtc_scanoutpos */,
>>>        .irq_preinstall = i915_driver_irq_preinstall,
>>>        .irq_postinstall = i915_driver_irq_postinstall,
>>>        .irq_uninstall = i915_driver_irq_uninstall,
>>>
>>> which makes 2.6.38-rc usable; though I do believe that I've seen
>>> the same issue (unflushed text) occur a couple of times since, much
>>> too rare to bisect or get upset by, but indicative of some  
>>> remaining bug.
>>>
>>
>> Hi,
>>
>> just skimmed through the archives of this thread. Do i understand  
>> correctly
>> that the problem that gets fixed by your revert is that
>>
>> <snip>
>>>>>
>>>>> when typing in one of the xterms, typed characters
>>>>> often stop echoing, until I shift to a different window, whereupon
>>>>> they appear.  This condition cleared (for a while) by switching to
>>>>> VESA fb console and back; no such problem observed on that  
>>>>> console.
>>>>
>> </snip>
>
> Yes, that's the problem that's fixed by the little revert patch I
> posted last time.
> Sorry, this thread started out with other problems, then I asked Chris
> if this might also be an i915 issue.
>
>>
>> Is this with desktop composition enabled?
>
> Not that I'm aware of.  The see-through business.  I'm just using four
> xterms in fvwm2 on openSUSE11.2 with own kernel.  If desktop
> composition might be enabled by the X startup script, expecting me to
> use gnome rather than fvwm2, then I suppose it might be enabled; but
> it's not something I've chosen to turn on.  What should I check to
> answer you for sure, if it matters?
>

Hm, probably not. You could check if compiz is running or if debug  
messages from "drm_wait_vblank" show up in syslog while you move and  
resize windows etc., or if there is visible tearing.

What xserver version is this?

>> Do things like glxgears in a
>> window work correctly? If desktop composition is off?
>
> Yes, glxgears appears to work correctly: I type "glxgears" at the
> xterm shell prompt, those letters and carriage return are not echoed
> back to me, but the glxgears window appears with the gears turning
> correctly, then I close that window, type more and again my typing is
> not echoed.
>
>>
>> For a softer fix to the problem you can revert your revert and  
>> disable use
>> of those functions by the drm core via:
>>
>> echo 0 > /sys/modules/drm/parameters/timestamp_precision_usec
>
> Thanks for the info.  ("module" rather than "modules".)
>
>>
>> But can you run it with echo 7 >  /sys/modules/drm/parameters/debug
>>
>> and show me bits of the syslog output when the problem happens?  
>> Especially
>> output from the functions "drm_calc_vbltimestamp_from_scanoutpos" and
>> "drm_handle_vblank" and maybe for "vblank_disable_fn",
>> "drm_update_vblank_count", and "drm_vblank_get".
>
> Wow, millions of lines of output (partly because I couldn't see the
> typo that had prevented me from turning it off after a few seconds).
> I rebuilt the kernel with the DRM_DEBUG at the head of drm_ioctl()
> edited out: that generates so many messages (cmd=0x400c645f
> mostly, but some cmd=0x6458)  that the logging cannot keep up, and
> hardly gets a chance to print anything else.
>
> But even with that edited out, nothing from any of the functions that
> you suggest: only, and perhaps this is the problem?,
> [drm:i915_driver_irq_handler}, pipe a underrun
> about 64 times per second.
>

That doesn't sound healthy. Chris Wilson will know, but afaik it  
means that the display pipeline doesn't get enough memory bandwidth  
to fetch pixels from the framebuffer fast/often enough for display,  
so there could be some misconfiguration of the memory controller or  
the display watermarks?

At the moment i can't see how the timestamping functions in the i915  
kms driver from my patch could cause your problem, except that  
disabling them apparently changes something to the better.

Could it be some side-effect, e.g., that if a display pipe suffers a  
fifo underrun and my timestamping code reads some mmio registers  
related to that pipe after the underrun, the chip somehow doesn't  
like that and chokes on it a bit?

If you haven't uncommented the kms timestamping functions with your  
patch and they are enabled, e.g., via echo 1000 > /sys/module/drm/ 
parameters/timestamp_precision_usec and logging of drm debug output  
is enabled, you should see some output from those functions in the  
syslog or dmesg output. There isn't any path through them that  
wouldn't produce a DRM_DEBUG, DRM_ERROR, DRM_DEBUG_DRIVER or  
DRM_DEBUG_KMS output at some point. An additional function to check  
would be "i915_get_vblank_timestamp".

If they exit with an error, you should see debug output and the drm  
core would fall back to the implementation you get when you apply  
your revert, or disable them via the echo 0 ...

If they succeed you should see output from  
drm_calc_vbltimestamp_from_scanoutpos with sensible timestamps and  
status info.

If they "succeed" but return garbage results due to some lingering  
bug in the untested codepath for GM965 and there would be an  
additional bug in the filtering of timestamps, you should see some  
debug output from drm_handle_vblank (..."Redundant vblirq  
ignored"...). OpenGL apps like glxgears could show some slight  
hiccups or jerks in their redraws. A desktop with composition enabled  
could also show some small jerks and delays. The only possible kind  
of bug i would expect in the untested codepath would be calculated  
timestamps that could be off by a few milliseconds, nothing more  
serious than that.

I'm not sure why a non-composited desktop would be affected at all,  
unless it makes use of the vblank counter and vblank counter  
incrementing is broken.

You could add a

DRM_DEBUG("crtc %d: vblcount %d\n", crtc, (int) vblcount);

right before the atomic_inc(&dev->_vblank_count[crtc]);
in drm_handle_vblank() at the bottom of drivers/gpu/drm/drm_irq.c
to print out the vblank counter at each vblank irq to verify that it  
increments nicely as it should.

You could also turn the abs(diff_ns) in that function into a abs64 
(diff_ns). The use of abs() is wrong, as it truncates the s64 diff_ns  
numbers to 32 bits. I'll prepare a patch to fix that. But this  
mistake should only cause trouble if the timestamps are already  
grossly wrong due to a kms driver bug, and even then it should only  
cause a slight, barely noticeable hiccup for OpenGL rendering due to  
at most one skipped frame every two seconds worst-case when the 32  
bit value wraps around.

You could also try ftrace to check the execution path of the code and  
its timing:

cd /sys/kernel/debug/tracing/
echo drm_handle_vblank > set_graph_function

or maybe one level deeper:  echo i915_driver_irq_handler >  
set_graph_function if this function is traceable.

echo function_graph > current_tracer
cat trace_pipe > /tmp/trace.out &
sleep 5 ; echo 1 > tracing_enabled ; sleep 10 ; echo 0 > tracing_enabled
more /tmp/trace.out


> I just tried setting the debug to 7 for a few seconds on 2.6.37, where
> I see no problem: I appear to get the "pipe a underrun" messages with
> that too; and the drm_ioctl messages, but much much fewer of them.
> Though I've been veering between i386 and x86_64 in these tests, so
> keep that in mind if what I'm saying makes no sense: the huge number
> of drm_ioctls was with 2.6.36-rc2 (plus some of Chris's fixes) on
> i386; the 64 underruns per second was with 2.6.36-rc2 (plus some of

I assume you meant 2.6.38-rc2?

thanks,
-mario


> Chris's fixes, minus the drm_ioctl DRM_DEBUG) on x86_64; the underruns
> and reasonable number of drm_ioctls was with 2.6.37 on x86_64.
>
> On this laptop I'm working with
> # CONFIG_NO_HZ is not set
> # CONFIG_HIGH_RES_TIMERS is not set
> CONFIG_HZ_250=y
> CONFIG_HZ=250
> if those have any relevance.
>
> Thanks,
> Hugh
>
>>
>> Those functions (are supposed to) compute exact timestamps of  
>> start of
>> scanout after each vblank. If they get disabled via the "echo  
>> 0 ..." then a
>> do_gettimeofday() is called for a crude approximation of start of  
>> scanout.
>> The computed timestamps are returned to clients which want them
>> (oml_sync_control extension). I doubt that many apps use that  
>> extension or
>> its timestamps already, especially not desktop compositors etc., so i
>> wouldn't expect trouble from such wrong timestamps.
>>
>> However, the timestamps are also used in drm_handle_vblank() in
>> drivers/gpu/drm/drm_irq.c at each vblank irq to detect and filter out
>> redundant vblank irq's to avoid miscounting of vblanks (observed  
>> on some
>> Radeon's). If the kms driver would deliver a grossly wrong  
>> timestamp and
>> something would be wrong in the implementation of that filtering,  
>> it could
>> happen that the vblank counter doesn't get incremented -> delivery  
>> of a
>> vblank event to the x-server gets delayed -> a swapbuffer  
>> operation on a
>> composited desktop gets delayed -> content of a redirected window  
>> updates
>> only with a delay.
>>
>> The relevant check which could prevent vblank counter increments  
>> and delay
>> vblank event delivery to the x-server in drm_handle_vblank() would  
>> be:
>>
>>        if (abs(diff_ns) > DRM_REDUNDANT_VBLIRQ_THRESH_NS) {
>>
>> The condition should be satisfied if everything works correctly,  
>> but also if
>> timestamps would be grossly wrong, thereby leading to a larger  
>> than 1 msec
>> positive or negative diff_ns. s64 diff_ns is a signed 64 bit  
>> integer. Could
>> abs(diff_ns) somehow miscompute for large 64 bit numbers?
>>
>> All guesswork, the syslog output should tell us more if the  
>> timestamping is
>> really involved in the problem.
>>
>> thanks,
>> -mario
>>
>> *********************************************************************
>> Mario Kleiner
>> Max Planck Institute for Biological Cybernetics
>> Spemannstr. 38
>> 72076 Tuebingen
>> Germany
>>
>> e-mail: mario.kleiner@tuebingen.mpg.de
>> office: +49 (0)7071/601-1623
>> fax:    +49 (0)7071/601-616
>> www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
>> *********************************************************************
>> "For a successful technology, reality must take precedence
>> over public relations, for Nature cannot be fooled."
>> (Richard Feynman)
>>
>>

*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mario.kleiner@tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Chris Wilson]

> On Jan 30, 2011, at 1:28 AM, Hugh Dickins wrote:
> > I just tried setting the debug to 7 for a few seconds on 2.6.37, where
> > I see no problem: I appear to get the "pipe a underrun" messages with
> > that too; and the drm_ioctl messages, but much much fewer of them.
> > Though I've been veering between i386 and x86_64 in these tests, so
> > keep that in mind if what I'm saying makes no sense: the huge number
> > of drm_ioctls was with 2.6.36-rc2 (plus some of Chris's fixes) on
> > i386; the 64 underruns per second was with 2.6.36-rc2 (plus some of

There shouldn't be any difference between the drm_ioctl() calls between
2.6.37 and 2.6.38 as the userspace is the same. I think this might the
crux of the issue. Can you attach a drm.debug=0xe boot dmesg, and a sample
of drm.debug=0x7 during the busy period for .37 and .38? And also your
Xorg.0.log.

Running fvwm and a couple of xterms you should not be utilizing vblanks at
all (not even suffering the vblank interrupt being enabled) so this code
should not even be causing unwanted side-effects. Bizarre.

The delay in characters showing up is a bug in the ddx; the render queue
is not being flushed before X goes to sleep. It's either the batch not
being submitted or the render cache not being flushed to the scan out in a
timely manner. (And these bugs can be complicated further by the
introduction of a compositing WM.) Both bugs have existed off-and-on in
the ddx over the years. And over time, we have weaned the kernel from
flushing the graphics caches unnecessarily; though the larger impact would
have been during the .37 cycle, at least the ones that sprang to mind as
likely candidates.

The pipe-a underrun is a nuisance; at best nothing will happen, there's an
outside chance that your display may flicker and at worst your machine may
hard hang.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/i915: Suppress spurious vblank interrupts

[Chris Wilson]

Hugh Dickins found that characters in xterm were going missing and oft
delayed. Being the curious type, he managed to associate this with the
new high-precision vblank patches; disabling these he found, restored
the orderliness of his characters.

The oddness begins when one realised that Hugh was not using vblanks at
all on his system (fvwm and some xterms). Instead, all he had to go on
were warning of a pipe underrun, curiously enough at around 60Hz. He
poked and found that in addition to the underrun warning, the hardware
was flagging the start of a new frame, a vblank, which in turn was
kicking off the pending vblank processing code.

There is little we can do for the underruns on Hugh's machine, a
Crestline [965GM], which must have its FIFO watermarks set to 8.
However, we do not need to process the vblank if we know that they are
disabled...

Reported-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/drm_irq.c       |    7 ++++---
 drivers/gpu/drm/i915/i915_irq.c |    8 ++++----
 include/drm/drmP.h              |    2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0054e95..3dadfa2 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1250,7 +1250,7 @@ void drm_handle_vblank_events(struct drm_device *dev, int crtc)
  * Drivers should call this routine in their vblank interrupt handlers to
  * update the vblank counter and send any signals that may be pending.
  */
-void drm_handle_vblank(struct drm_device *dev, int crtc)
+bool drm_handle_vblank(struct drm_device *dev, int crtc)
 {
 	u32 vblcount;
 	s64 diff_ns;
@@ -1258,7 +1258,7 @@ void drm_handle_vblank(struct drm_device *dev, int crtc)
 	unsigned long irqflags;
 
 	if (!dev->num_crtcs)
-		return;
+		return false;
 
 	/* Need timestamp lock to prevent concurrent execution with
 	 * vblank enable/disable, as this would cause inconsistent
@@ -1269,7 +1269,7 @@ void drm_handle_vblank(struct drm_device *dev, int crtc)
 	/* Vblank irq handling disabled. Nothing to do. */
 	if (!dev->vblank_enabled[crtc]) {
 		spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags);
-		return;
+		return false;
 	}
 
 	/* Fetch corresponding timestamp for this vblank interval from
@@ -1311,5 +1311,6 @@ void drm_handle_vblank(struct drm_device *dev, int crtc)
 	drm_handle_vblank_events(dev, crtc);
 
 	spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags);
+	return true;
 }
 EXPORT_SYMBOL(drm_handle_vblank);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d388bbb..1a33aea 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1202,18 +1202,18 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
 				intel_finish_page_flip_plane(dev, 1);
 		}
 
-		if (pipea_stats & vblank_status) {
+		if (pipea_stats & vblank_status &&
+		    drm_handle_vblank(dev, 0)) {
 			vblank++;
-			drm_handle_vblank(dev, 0);
 			if (!dev_priv->flip_pending_is_done) {
 				i915_pageflip_stall_check(dev, 0);
 				intel_finish_page_flip(dev, 0);
 			}
 		}
 
-		if (pipeb_stats & vblank_status) {
+		if (pipeb_stats & vblank_status &&
+		    drm_handle_vblank(dev, 1)) {
 			vblank++;
-			drm_handle_vblank(dev, 1);
 			if (!dev_priv->flip_pending_is_done) {
 				i915_pageflip_stall_check(dev, 1);
 				intel_finish_page_flip(dev, 1);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index a4694c6..fe29aad 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1367,7 +1367,7 @@ extern int drm_vblank_wait(struct drm_device *dev, unsigned int *vbl_seq);
 extern u32 drm_vblank_count(struct drm_device *dev, int crtc);
 extern u32 drm_vblank_count_and_time(struct drm_device *dev, int crtc,
 				     struct timeval *vblanktime);
-extern void drm_handle_vblank(struct drm_device *dev, int crtc);
+extern bool drm_handle_vblank(struct drm_device *dev, int crtc);
 extern int drm_vblank_get(struct drm_device *dev, int crtc);
 extern void drm_vblank_put(struct drm_device *dev, int crtc);
 extern void drm_vblank_off(struct drm_device *dev, int crtc);
-- 
1.7.2.3

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Hugh Dickins]

On Mon, 31 Jan 2011, Chris Wilson wrote:

> Hugh Dickins found that characters in xterm were going missing and oft
> delayed. Being the curious type, he managed to associate this with the
> new high-precision vblank patches; disabling these he found, restored
> the orderliness of his characters.
> 
> The oddness begins when one realised that Hugh was not using vblanks at
> all on his system (fvwm and some xterms). Instead, all he had to go on
> were warning of a pipe underrun, curiously enough at around 60Hz. He
> poked and found that in addition to the underrun warning, the hardware
> was flagging the start of a new frame, a vblank, which in turn was
> kicking off the pending vblank processing code.
> 
> There is little we can do for the underruns on Hugh's machine, a
> Crestline [965GM], which must have its FIFO watermarks set to 8.
> However, we do not need to process the vblank if we know that they are
> disabled...
> 
> Reported-by: Hugh Dickins <hughd@google.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks a lot for devising this, Chris, I really appreciate it.

But so far I can't be more enthusiastic than "seems to be a good
improvement most of the time" - though I've not spent long on this
laptop since putting it on to -rc3.

I've not seen it go wrong on x86_64, but my first boot with it on
i386 behaved just as badly as before; thereafter it's not gone wrong
yet (and I had to double-check boot.omsg to make sure I'd really been
running what I thought I was running the first time).  I'm relying
upon it to type this mail, which I wouldn't have managed before.

As you know (I went off-list to send more info at the weekend), this
behaviour is very elusive, probably depends on more than one issue,
comes and goes with irrelevant patches and config changes and reboots.

So I don't yet have a lot of confidence that your patch will work out
better in the long run than what I tried at the weekend (when moving
do_intel_finish_page_flip's do_gettimeofday back into the work->event
block worked well until the evening).  If I had time, I'd experiment
further - but I don't have time, so I'll just keep running with your
patch to gather more confidence in it.

So far, so (fairly) good.

Thanks,
Hugh

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Chris Wilson]

On Tue, 1 Feb 2011 09:34:12 -0800 (PST), Hugh Dickins <hughd@google.com> wrote:
> Thanks a lot for devising this, Chris, I really appreciate it.
> 
> But so far I can't be more enthusiastic than "seems to be a good
> improvement most of the time" - though I've not spent long on this
> laptop since putting it on to -rc3.

Yeah, this is really just an interim patch. Removes one instance of doing
work when we don't need to, but it does not answer why the vblank patches
made your machines worse (since the same spurious interrupt bug is present
in 2.6.37 and earlier).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Jesse Barnes]

On Tue, 1 Feb 2011 09:34:12 -0800 (PST)
Hugh Dickins <hughd@google.com> wrote:

> On Mon, 31 Jan 2011, Chris Wilson wrote:
> 
> > Hugh Dickins found that characters in xterm were going missing and oft
> > delayed. Being the curious type, he managed to associate this with the
> > new high-precision vblank patches; disabling these he found, restored
> > the orderliness of his characters.
> > 
> > The oddness begins when one realised that Hugh was not using vblanks at
> > all on his system (fvwm and some xterms). Instead, all he had to go on
> > were warning of a pipe underrun, curiously enough at around 60Hz. He
> > poked and found that in addition to the underrun warning, the hardware
> > was flagging the start of a new frame, a vblank, which in turn was
> > kicking off the pending vblank processing code.
> > 
> > There is little we can do for the underruns on Hugh's machine, a
> > Crestline [965GM], which must have its FIFO watermarks set to 8.
> > However, we do not need to process the vblank if we know that they are
> > disabled...
> > 
> > Reported-by: Hugh Dickins <hughd@google.com>
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Thanks a lot for devising this, Chris, I really appreciate it.
> 
> But so far I can't be more enthusiastic than "seems to be a good
> improvement most of the time" - though I've not spent long on this
> laptop since putting it on to -rc3.
> 
> I've not seen it go wrong on x86_64, but my first boot with it on
> i386 behaved just as badly as before; thereafter it's not gone wrong
> yet (and I had to double-check boot.omsg to make sure I'd really been
> running what I thought I was running the first time).  I'm relying
> upon it to type this mail, which I wouldn't have managed before.
> 
> As you know (I went off-list to send more info at the weekend), this
> behaviour is very elusive, probably depends on more than one issue,
> comes and goes with irrelevant patches and config changes and reboots.

Are you still seeing underruns during normal activity?  I wonder if the
ones you were seeing before were only reported at 60Hz due to vblank
interrupt processing.  If we failed to clear the underrun status, we'd
report one every time we got a vblank interrupt (since the underruns
don't report interrupts by themselves).

If so, that may just be a red herring in this case.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Jesse Barnes]

On Tue, 1 Feb 2011 09:46:43 -0800
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Tue, 1 Feb 2011 09:34:12 -0800 (PST)
> Hugh Dickins <hughd@google.com> wrote:
> > As you know (I went off-list to send more info at the weekend), this
> > behaviour is very elusive, probably depends on more than one issue,
> > comes and goes with irrelevant patches and config changes and reboots.
> 
> Are you still seeing underruns during normal activity?  I wonder if the
> ones you were seeing before were only reported at 60Hz due to vblank
> interrupt processing.  If we failed to clear the underrun status, we'd
> report one every time we got a vblank interrupt (since the underruns
> don't report interrupts by themselves).
> 
> If so, that may just be a red herring in this case.

More random questions arise from the info provided:
 - why are we ending up in the flip code at all?  fvwm shouldn't
   trigger that path...
 - what's with all the underruns?  it looks like we *do* ack those
   flags as needed, so apparently they're valid, but they indicate a
   serious problem with the display pipeline; maybe self-refresh
   shouldn't be enabled on your system (that would increase memory
   latency and potentially cause underruns), running with
   i915.powersave=0 would disable that feature

The lack of text really does sound like a render cache flushing
problem, but the other issues are worrying as well, and could be
compounding things.  And the last time I saw the issue, it was related
to compositing and required an X server fix.  But supposedly you're not
using compositing, so...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Hugh Dickins]

On Tue, Feb 1, 2011 at 10:08 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Tue, 1 Feb 2011 09:46:43 -0800
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>>
>> Are you still seeing underruns during normal activity?

Yes.  That is, I see the "pipe a underrun" messages when I set drm
debug 7: I'm unaware of any ill-effect from them, unless they are
indeed a factor in my unflushed text issue.

>> I wonder if the
>> ones you were seeing before were only reported at 60Hz due to vblank
>> interrupt processing.  If we failed to clear the underrun status, we'd
>> report one every time we got a vblank interrupt (since the underruns
>> don't report interrupts by themselves).

I was surprised that i915_driver_irq_handler  "Clear the PIPE(A|B)STAT
regs" writes back precisely the pipea_stats it reads in, I'd have
expected to clear something there (and did earlier experiment with
writing back 0: black screen at boot!).  But assumed the protocol is
such that it acknowledges the status bits by writing same back.

>>
>> If so, that may just be a red herring in this case.
>
> More random questions arise from the info provided:
>  - why are we ending up in the flip code at all?  fvwm shouldn't
>   trigger that path...

Right.  I haven't double-checked the logic, but I believe it's because
of bits set in the underrunning pipea_stats.  I did one time modify
the underrun message to print out pipea_stats, over five seconds most
(265) values were 0x80440207
(there were also 14 occurrences of 0x80440007, 5 of 0x80440004 and 3
of 0x80440204).

>  - what's with all the underruns?  it looks like we *do* ack those
>   flags as needed, so apparently they're valid, but they indicate a
>   serious problem with the display pipeline; maybe self-refresh
>   shouldn't be enabled on your system (that would increase memory
>   latency and potentially cause underruns), running with
>   i915.powersave=0 would disable that feature

I just tried i915.powersave=0 but the underruns still appeared.  I
then tried earlier kernels, and was surprised to find no underruns
with 2.6.34, 2.6.36: the underruns appeared with 2.6.37.

>
> The lack of text really does sound like a render cache flushing
> problem, but the other issues are worrying as well, and could be
> compounding things.  And the last time I saw the issue, it was related
> to compositing and required an X server fix.  But supposedly you're not
> using compositing, so...

That's right.

Hugh

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Jesse Barnes]

On Tue, 1 Feb 2011 10:46:17 -0800
Hugh Dickins <hughd@google.com> wrote:

> On Tue, Feb 1, 2011 at 10:08 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Tue, 1 Feb 2011 09:46:43 -0800
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >>
> >> Are you still seeing underruns during normal activity?
> 
> Yes.  That is, I see the "pipe a underrun" messages when I set drm
> debug 7: I'm unaware of any ill-effect from them, unless they are
> indeed a factor in my unflushed text issue.

They can cause your display to shake or flicker, or the memory
controller to get confused enough to hang your system.

> I was surprised that i915_driver_irq_handler  "Clear the PIPE(A|B)STAT
> regs" writes back precisely the pipea_stats it reads in, I'd have
> expected to clear something there (and did earlier experiment with
> writing back 0: black screen at boot!).  But assumed the protocol is
> such that it acknowledges the status bits by writing same back.

Exactly.  High bits are the interrupt enable bits, low bits are set for
status, write of 1 to clear status.

> Right.  I haven't double-checked the logic, but I believe it's because
> of bits set in the underrunning pipea_stats.  I did one time modify
> the underrun message to print out pipea_stats, over five seconds most
> (265) values were 0x80440207
> (there were also 14 occurrences of 0x80440007, 5 of 0x80440004 and 3
> of 0x80440204).

Well, vblank interrupts are enabled (though they shouldn't be for your
config as far as we know), so the interrupt status and handling is
occurring as expected.

What I find strange is that you're seeing flip pending interrupts.  Are
your symptoms affected if you remove the
I915_DISPLAY_PLANE_[AB]_FLIP_PENDING_INTERRUPT lines from
I915_INTERRUPT_ENABLE_FIX at the top of i915_irq.c?

Do you see any calls to drm_mode_page_flip_ioctl() in your environment?

> I just tried i915.powersave=0 but the underruns still appeared.  I
> then tried earlier kernels, and was surprised to find no underruns
> with 2.6.34, 2.6.36: the underruns appeared with 2.6.37.

Ok, that rules out self-refresh then I think.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Hugh Dickins]

On Tue, Feb 1, 2011 at 11:32 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> What I find strange is that you're seeing flip pending interrupts.  Are
> your symptoms affected if you remove the
> I915_DISPLAY_PLANE_[AB]_FLIP_PENDING_INTERRUPT lines from
> I915_INTERRUPT_ENABLE_FIX at the top of i915_irq.c?

No.  The first time it looked like yes it fixed it; but when I
rebooted again, same symptoms and same underruns back: this thing is
very erratic.

> Do you see any calls to drm_mode_page_flip_ioctl() in your environment?

None at all.

Sometime I should do a bisection between v2.6.36 and v2.6.37 to see
what started the underruns; but I can't promise when "sometime" will
arrive.

Hugh

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Jesse Barnes]

On Tue, 1 Feb 2011 19:37:09 -0800
Hugh Dickins <hughd@google.com> wrote:

> On Tue, Feb 1, 2011 at 11:32 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > What I find strange is that you're seeing flip pending interrupts.  Are
> > your symptoms affected if you remove the
> > I915_DISPLAY_PLANE_[AB]_FLIP_PENDING_INTERRUPT lines from
> > I915_INTERRUPT_ENABLE_FIX at the top of i915_irq.c?
> 
> No.  The first time it looked like yes it fixed it; but when I
> rebooted again, same symptoms and same underruns back: this thing is
> very erratic.
> 
> > Do you see any calls to drm_mode_page_flip_ioctl() in your environment?
> 
> None at all.
> 
> Sometime I should do a bisection between v2.6.36 and v2.6.37 to see
> what started the underruns; but I can't promise when "sometime" will
> arrive.

But presumably the FLIP_PENDING_INTERRUPT bits are stuck on in your
case, otherwise we wouldn't be getting to flip prepare/finish at all.

Some updated docs indicate those bits may not be reliable on 965
(though earlier ones did), so we may need to disable the flip code
entirely on 965 if we can't figure out what's going wrong on your
config...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Hugh Dickins]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4117 bytes --]

On Wed, 2 Feb 2011, Jesse Barnes wrote:
> On Tue, 1 Feb 2011 19:37:09 -0800
> Hugh Dickins <hughd@google.com> wrote:
> 
> > On Tue, Feb 1, 2011 at 11:32 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > 
> > > What I find strange is that you're seeing flip pending interrupts.  Are
> > > your symptoms affected if you remove the
> > > I915_DISPLAY_PLANE_[AB]_FLIP_PENDING_INTERRUPT lines from
> > > I915_INTERRUPT_ENABLE_FIX at the top of i915_irq.c?
> > 
> > No.  The first time it looked like yes it fixed it; but when I
> > rebooted again, same symptoms and same underruns back: this thing is
> > very erratic.
> > 
> > > Do you see any calls to drm_mode_page_flip_ioctl() in your environment?
> > 
> > None at all.
> > 
> > Sometime I should do a bisection between v2.6.36 and v2.6.37 to see
> > what started the underruns; but I can't promise when "sometime" will
> > arrive.
> 
> But presumably the FLIP_PENDING_INTERRUPT bits are stuck on in your
> case, otherwise we wouldn't be getting to flip prepare/finish at all.
> 
> Some updated docs indicate those bits may not be reliable on 965
> (though earlier ones did), so we may need to disable the flip code
> entirely on 965 if we can't figure out what's going wrong on your
> config...

Sometime arrived, I did a bisection between v2.6.36 and v2.6.37,
and my "pipe a underrun"s on 965 begin with 29e1316ab129 drm/i915/tv:
Sleep before checking for state changes (appended below).

But that's a necessary patch for me: without it both VESA framebuffer
and X mistake the size and shape of the laptop screen, and my windows
don't fit in properly.

I experimented a little with intel_tv.c on 2.6.38-rc3 and rc4.
Indeed, just deleting that intel_wait_for_vblank() stops the underruns,
but leaves the display missized.  Replacing it by msleep(20), as used to
be done, behaves the same as with intel_wait_for_vblank() there: underruns
with correctly sized display.  "#if 0"ing all of intel_tv_detect_type(),
just returning -1 from it, gives no underruns and correctly sized display.

I was going to work with the latter, when my original unflushed text
problem resurfaced again (just as it had later done when trying Chris's
"Suppress spurious vblank interrupts" patch).  It appears that the
underruns, while mysterious and worrisome, have litte or nothing to do
with the unflushed text problem which is making 2.6.38-rc unusable.

For the moment I've gone back to my patch moving intel_display.c's
do_gettimeofday() call into the block where it's needed; though that
too disappointed eventually before.  It all rather stinks of something
uninitialized somewhere.

Hugh

commit 29e1316ab129f2d3a9ea874e7c9a4cb936f43542
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 22 19:10:09 2010 +0100

    drm/i915/tv: Sleep before checking for state changes.
    
    We need to wait for the PLLs to settle prior to detecting the state
    changes. The BIOS writers guide suggests waiting for the next vblank.
    
    Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 49ab11c..106560b 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1271,8 +1271,12 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
 	I915_WRITE(TV_DAC, tv_dac);
 	POSTING_READ(TV_DAC);
 
+	intel_wait_for_vblank(intel_tv->base.base.dev,
+			      to_intel_crtc(intel_tv->base.base.crtc)->pipe);
+
 	type = -1;
 	if (wait_for((tv_dac = I915_READ(TV_DAC)) & TVDAC_STATE_CHG, 20) == 0) {
+		DRM_DEBUG_KMS("TV detected: %x, %x\n", tv_ctl, tv_dac);
 		/*
 		 *  A B C
 		 *  0 1 1 Composite
@@ -1289,8 +1293,7 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
 			DRM_DEBUG_KMS("Detected Component TV connection\n");
 			type = DRM_MODE_CONNECTOR_Component;
 		} else {
-			DRM_DEBUG_KMS("Unrecognised TV connection: %x\n",
-				      tv_dac);
+			DRM_DEBUG_KMS("Unrecognised TV connection\n");
 		}
 	}
 

[PATCH] drm/i915/tv: Use polling rather than interrupt-based hotplug

[Chris Wilson]

The documentation recommends that we should use a polling method for TV
detection as this is more power efficient than the interrupt based
mechanism (as the encoder can be completely switched off). A secondary
effect is that leaving the hotplug enabled seems to be causing pipe
underruns as reported by Hugh Dickins on his Crestline.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
---

Hugh, does this prevent the persistent PIPE UNDERRUN issue?

---
 drivers/gpu/drm/i915/intel_tv.c |   43 +++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 93206e4..fe4a53a 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1234,7 +1234,8 @@ static const struct drm_display_mode reported_modes[] = {
  * \return false if TV is disconnected.
  */
 static int
-intel_tv_detect_type (struct intel_tv *intel_tv)
+intel_tv_detect_type (struct intel_tv *intel_tv,
+		      struct drm_connector *connector)
 {
 	struct drm_encoder *encoder = &intel_tv->base.base;
 	struct drm_device *dev = encoder->dev;
@@ -1245,11 +1246,13 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
 	int type;
 
 	/* Disable TV interrupts around load detect or we'll recurse */
-	spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
-	i915_disable_pipestat(dev_priv, 0,
-			      PIPE_HOTPLUG_INTERRUPT_ENABLE |
-			      PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
-	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+	if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
+		spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+		i915_disable_pipestat(dev_priv, 0,
+				      PIPE_HOTPLUG_INTERRUPT_ENABLE |
+				      PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
+		spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+	}
 
 	save_tv_dac = tv_dac = I915_READ(TV_DAC);
 	save_tv_ctl = tv_ctl = I915_READ(TV_CTL);
@@ -1302,11 +1305,13 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
 	I915_WRITE(TV_CTL, save_tv_ctl);
 
 	/* Restore interrupt config */
-	spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
-	i915_enable_pipestat(dev_priv, 0,
-			     PIPE_HOTPLUG_INTERRUPT_ENABLE |
-			     PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
-	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+	if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
+		spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
+		i915_enable_pipestat(dev_priv, 0,
+				     PIPE_HOTPLUG_INTERRUPT_ENABLE |
+				     PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
+		spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
+	}
 
 	return type;
 }
@@ -1356,7 +1361,7 @@ intel_tv_detect(struct drm_connector *connector, bool force)
 	drm_mode_set_crtcinfo(&mode, CRTC_INTERLACE_HALVE_V);
 
 	if (intel_tv->base.base.crtc && intel_tv->base.base.crtc->enabled) {
-		type = intel_tv_detect_type(intel_tv);
+		type = intel_tv_detect_type(intel_tv, connector);
 	} else if (force) {
 		struct drm_crtc *crtc;
 		int dpms_mode;
@@ -1364,7 +1369,7 @@ intel_tv_detect(struct drm_connector *connector, bool force)
 		crtc = intel_get_load_detect_pipe(&intel_tv->base, connector,
 						  &mode, &dpms_mode);
 		if (crtc) {
-			type = intel_tv_detect_type(intel_tv);
+			type = intel_tv_detect_type(intel_tv, connector);
 			intel_release_load_detect_pipe(&intel_tv->base, connector,
 						       dpms_mode);
 		} else
@@ -1658,6 +1663,18 @@ intel_tv_init(struct drm_device *dev)
 	intel_encoder = &intel_tv->base;
 	connector = &intel_connector->base;
 
+	/* The documentation, for the older chipsets at least, recommend
+	 * using a polling method rather than hotplug detection for TVs.
+	 * This is because in order to perform the hotplug detection, the PLLs
+	 * for the TV must be kept alive increasing power drain and starving
+	 * bandwidth from other encoders. Notably for instance, it causes
+	 * pipe underruns on Crestline when this encoder is supposedly idle.
+	 *
+	 * More recent chipsets favour HDMI rather than integrated S-Video.
+	 */
+	connector->polled =
+		DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT;
+
 	drm_connector_init(dev, connector, &intel_tv_connector_funcs,
 			   DRM_MODE_CONNECTOR_SVIDEO);
 
-- 
1.7.2.3

Re: [PATCH] drm/i915/tv: Use polling rather than interrupt-based hotplug

[Hugh Dickins]

On Thu, 10 Feb 2011, Chris Wilson wrote:

> The documentation recommends that we should use a polling method for TV
> detection as this is more power efficient than the interrupt based
> mechanism (as the encoder can be completely switched off). A secondary
> effect is that leaving the hotplug enabled seems to be causing pipe
> underruns as reported by Hugh Dickins on his Crestline.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: stable@kernel.org
> ---
> 
> Hugh, does this prevent the persistent PIPE UNDERRUN issue?

Brilliant, Chris, yes it does, thank you.  I checked both 2.6.38-rc4
and 2.6.37 (changing "irq_lock" back to "user_irq_lock") and verified
that both i386 and x86_64 "pipe a underrun"s have been fixed.  I also
just tried hooking up laptop to TV by VGA cable, and it appears to
drive the TV correctly too.

(It doesn't fix my text flush problem, but we'd given up expecting that.)

Thanks,
Hugh

> 
> ---
>  drivers/gpu/drm/i915/intel_tv.c |   43 +++++++++++++++++++++++++++-----------
>  1 files changed, 30 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 93206e4..fe4a53a 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1234,7 +1234,8 @@ static const struct drm_display_mode reported_modes[] = {
>   * \return false if TV is disconnected.
>   */
>  static int
> -intel_tv_detect_type (struct intel_tv *intel_tv)
> +intel_tv_detect_type (struct intel_tv *intel_tv,
> +		      struct drm_connector *connector)
>  {
>  	struct drm_encoder *encoder = &intel_tv->base.base;
>  	struct drm_device *dev = encoder->dev;
> @@ -1245,11 +1246,13 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
>  	int type;
>  
>  	/* Disable TV interrupts around load detect or we'll recurse */
> -	spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> -	i915_disable_pipestat(dev_priv, 0,
> -			      PIPE_HOTPLUG_INTERRUPT_ENABLE |
> -			      PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
> -	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +	if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
> +		spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +		i915_disable_pipestat(dev_priv, 0,
> +				      PIPE_HOTPLUG_INTERRUPT_ENABLE |
> +				      PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
> +		spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +	}
>  
>  	save_tv_dac = tv_dac = I915_READ(TV_DAC);
>  	save_tv_ctl = tv_ctl = I915_READ(TV_CTL);
> @@ -1302,11 +1305,13 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
>  	I915_WRITE(TV_CTL, save_tv_ctl);
>  
>  	/* Restore interrupt config */
> -	spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> -	i915_enable_pipestat(dev_priv, 0,
> -			     PIPE_HOTPLUG_INTERRUPT_ENABLE |
> -			     PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
> -	spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +	if (connector->polled & DRM_CONNECTOR_POLL_HPD) {
> +		spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +		i915_enable_pipestat(dev_priv, 0,
> +				     PIPE_HOTPLUG_INTERRUPT_ENABLE |
> +				     PIPE_HOTPLUG_TV_INTERRUPT_ENABLE);
> +		spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +	}
>  
>  	return type;
>  }
> @@ -1356,7 +1361,7 @@ intel_tv_detect(struct drm_connector *connector, bool force)
>  	drm_mode_set_crtcinfo(&mode, CRTC_INTERLACE_HALVE_V);
>  
>  	if (intel_tv->base.base.crtc && intel_tv->base.base.crtc->enabled) {
> -		type = intel_tv_detect_type(intel_tv);
> +		type = intel_tv_detect_type(intel_tv, connector);
>  	} else if (force) {
>  		struct drm_crtc *crtc;
>  		int dpms_mode;
> @@ -1364,7 +1369,7 @@ intel_tv_detect(struct drm_connector *connector, bool force)
>  		crtc = intel_get_load_detect_pipe(&intel_tv->base, connector,
>  						  &mode, &dpms_mode);
>  		if (crtc) {
> -			type = intel_tv_detect_type(intel_tv);
> +			type = intel_tv_detect_type(intel_tv, connector);
>  			intel_release_load_detect_pipe(&intel_tv->base, connector,
>  						       dpms_mode);
>  		} else
> @@ -1658,6 +1663,18 @@ intel_tv_init(struct drm_device *dev)
>  	intel_encoder = &intel_tv->base;
>  	connector = &intel_connector->base;
>  
> +	/* The documentation, for the older chipsets at least, recommend
> +	 * using a polling method rather than hotplug detection for TVs.
> +	 * This is because in order to perform the hotplug detection, the PLLs
> +	 * for the TV must be kept alive increasing power drain and starving
> +	 * bandwidth from other encoders. Notably for instance, it causes
> +	 * pipe underruns on Crestline when this encoder is supposedly idle.
> +	 *
> +	 * More recent chipsets favour HDMI rather than integrated S-Video.
> +	 */
> +	connector->polled =
> +		DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT;
> +
>  	drm_connector_init(dev, connector, &intel_tv_connector_funcs,
>  			   DRM_MODE_CONNECTOR_SVIDEO);
>  
> -- 
> 1.7.2.3

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Mario Kleiner]

On Feb 8, 2011, at 8:52 PM, Hugh Dickins wrote:
>>
>> But presumably the FLIP_PENDING_INTERRUPT bits are stuck on in your
>> case, otherwise we wouldn't be getting to flip prepare/finish at all.
>>
>> Some updated docs indicate those bits may not be reliable on 965
>> (though earlier ones did), so we may need to disable the flip code
>> entirely on 965 if we can't figure out what's going wrong on your
>> config...
>
> Sometime arrived, I did a bisection between v2.6.36 and v2.6.37,
> and my "pipe a underrun"s on 965 begin with 29e1316ab129 drm/i915/tv:
> Sleep before checking for state changes (appended below).
>
> But that's a necessary patch for me: without it both VESA framebuffer
> and X mistake the size and shape of the laptop screen, and my windows
> don't fit in properly.
>
> I experimented a little with intel_tv.c on 2.6.38-rc3 and rc4.
> Indeed, just deleting that intel_wait_for_vblank() stops the  
> underruns,
> but leaves the display missized.  Replacing it by msleep(20), as  
> used to
> be done, behaves the same as with intel_wait_for_vblank() there:  
> underruns
> with correctly sized display.  "#if 0"ing all of  
> intel_tv_detect_type(),
> just returning -1 from it, gives no underruns and correctly sized  
> display.
> I was going to work with the latter, when my original unflushed text
> problem resurfaced again (just as it had later done when trying  
> Chris's
> "Suppress spurious vblank interrupts" patch).  It appears that the
> underruns, while mysterious and worrisome, have litte or nothing to do
> with the unflushed text problem which is making 2.6.38-rc unusable.
>
> For the moment I've gone back to my patch moving intel_display.c's
> do_gettimeofday() call into the block where it's needed; though that
> too disappointed eventually before.  It all rather stinks of something
> uninitialized somewhere.

Just a remark, the do_gettimeofday() call is placed where it is  
(Before the spin_lock_irqsave() call for the event_lock), so that  
taking that timestamp (which is only needed later for some  
comparisons) isn't delayed by a possible blocking on that lock.  
Getting the timestamp as early as possible after entering that  
function is needed to make pageflip timestamping more robust.

I'm puzzled why calling do_gettimeofday() could cause any harm, even  
if that code gets executed by accident. I stared at the code for a  
while and couldn't see missing initializations or similar. Maybe it  
would still make sense to try to get some ftrace's on how the code  
there executes, e.g., which path does it actually take or if some  
piece of code takes an unusual and excessive amount of time to execute?

-mario

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Hugh Dickins]

On Fri, Feb 11, 2011 at 10:21 AM, Mario Kleiner
<mario.kleiner@tuebingen.mpg.de> wrote:
> On Feb 8, 2011, at 8:52 PM, Hugh Dickins wrote:
>>  It appears that the
>> underruns, while mysterious and worrisome, have litte or nothing to do
>> with the unflushed text problem which is making 2.6.38-rc unusable.
>>
>> For the moment I've gone back to my patch moving intel_display.c's
>> do_gettimeofday() call into the block where it's needed; though that
>> too disappointed eventually before.  It all rather stinks of something
>> uninitialized somewhere.
>
> Just a remark, the do_gettimeofday() call is placed where it is (Before the
> spin_lock_irqsave() call for the event_lock), so that taking that timestamp
> (which is only needed later for some comparisons) isn't delayed by a
> possible blocking on that lock. Getting the timestamp as early as possible
> after entering that function is needed to make pageflip timestamping more
> robust.
>
> I'm puzzled why calling do_gettimeofday() could cause any harm, even if that
> code gets executed by accident. I stared at the code for a while and
> couldn't see missing initializations or similar. Maybe it would still make
> sense to try to get some ftrace's on how the code there executes, e.g.,
> which path does it actually take or if some piece of code takes an unusual
> and excessive amount of time to execute?

I'm sorry to say that I have now given up on this: it has already
consumed a lot more time than I can afford to give it.  So I've now
just turned CONFIG_DRM_I915_KMS off, which gives me a laptop on which
2.6.38-rc is usable.

If in due course there's a likely patch someone would like me to try,
that I can do.  And from time to time, with new kernels and with
upgraded userspace, I'll give I915_KMS a try again - indeed, for the
moment I still have it in my 64bit kernel.

Before switching KMS off, I did establish that, with Chris's overrun
fix, do_intel_finish_page_flip() - the function whose call to
do_gettimeofday() I moved - is no longer called at all.  So that
modification was just cargo-cult magic by now (though perhaps made a
difference to timings when overruns were happening), and there's no
reason to suspect Mario's vblank patch at all.  Let's assume that if I
attempted a fifth bisection, it would lead me to another (equally
blameless) patch.  Nobody else is complaining: maybe my 965 is broken
and just gets along better with 2.6.38 KMS off.

Hugh

Re: [PATCH] drm/i915: Suppress spurious vblank interrupts

[Hugh Dickins]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1648 bytes --]

On Mon, 14 Feb 2011, Hugh Dickins wrote:
> On Fri, Feb 11, 2011 at 10:21 AM, Mario Kleiner
> <mario.kleiner@tuebingen.mpg.de> wrote:
> > On Feb 8, 2011, at 8:52 PM, Hugh Dickins wrote:
> >>  It appears that the
> >> underruns, while mysterious and worrisome, have litte or nothing to do
> >> with the unflushed text problem which is making 2.6.38-rc unusable.
> >>
> I'm sorry to say that I have now given up on this: it has already
> consumed a lot more time than I can afford to give it.  So I've now
> just turned CONFIG_DRM_I915_KMS off, which gives me a laptop on which
> 2.6.38-rc is usable.
> 
> If in due course there's a likely patch someone would like me to try,
> that I can do.  And from time to time, with new kernels and with
> upgraded userspace, I'll give I915_KMS a try again - indeed, for the
> moment I still have it in my 64bit kernel.
> 
> Before switching KMS off, I did establish that, with Chris's overrun
> fix, do_intel_finish_page_flip() - the function whose call to
> do_gettimeofday() I moved - is no longer called at all.  So that
> modification was just cargo-cult magic by now (though perhaps made a
> difference to timings when overruns were happening), and there's no
> reason to suspect Mario's vblank patch at all.  Let's assume that if I
> attempted a fifth bisection, it would lead me to another (equally
> blameless) patch.  Nobody else is complaining: maybe my 965 is broken
> and just gets along better with 2.6.38 KMS off.

Just wanted to report that something (sorry, no time to work out what)
in 3.0-rc1 fixed this issue for me, so now I am back on I915_KMS: thanks.

Hugh

Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

[Chris Clayton]

On Sunday 30 January 2011, Hugh Dickins wrote:

<snip>
> Yes, that's the problem that's fixed by the little revert patch I
> posted last time.
> Sorry, this thread started out with other problems, then I asked Chris
> if this might also be an i915 issue.
>

My problem is fixed now, so the thread is all yours :)

Good luck

Chris (Clayton)

<snip>

-- 
The more I see, the more I know. The more I know, the less I understand. 
Changing Man - Paul Weller

Re: [BISECTED] agp/intel: revert "Remove confusion of stolen entries not stolen memory"

[Jiri Olsa]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

On Fri, Jan 21, 2011 at 12:24:14AM +0100, Frederic Weisbecker wrote:
> On Mon, Dec 20, 2010 at 09:06:47PM +0000, Chris Wilson wrote:
> > On Mon, 20 Dec 2010 21:52:38 +0100, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Monday 20 December 2010 20:52:07 Chris Wilson wrote:
> > > > 
> > > > Also, which modules do you have loaded when using VESA? i.e. is the
> > > > i915.ko loaded, but in UMS mode (i915.modeset=0)?
> > > 
> > > This doesn't seem to matter, as far as I can tell, i915 can be loaded
> > > or now.
> > 
> > Thanks, that rules out the likely explanation that we [i915] loaded the
> > GTT with some conflicting entries. Instead it is likely the initialisation
> > of the GTT to point to the scratch page that is triggering the problem.
> > Can you try disabling it with:
> 
> Hi,
> 
> I have the problem too with -rc1, and even with latest linus tree.
> 
> I too bisected back to:
> "agp/intel: Remove confusion of stolen entries not stolen memory)"
> (c64f7ba5f1006d8c20eacafecf98d4d00a6902a0)
> 
> Symptom is I see a big vertical cursor blinking in my screen and
> nothing else. If something tries to be displayed it gets very messy.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
hi,

same for me, it's showing just blinking horizontal white lines

I use following kernel command line:
"fbcon=rotate:3 vga=0x318"

and bissected the issue to the same commit

agp/intel: Remove confusion of stolen entries not stolen memory
commit c64f7ba5f1006d8c20eacafecf98d4d00a6902a0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Nov 23 14:24:24 2010 +0000

I'm attaching lspci -vvv and my config file,
please let me know if you need more info/retest

thanks,
jirka

[-- Attachment #2: lspci --]
[-- Type: text/plain, Size: 16668 bytes --]

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 06)
	Subsystem: Intel Corporation Device 1999
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information: Len=0a <?>
	Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
	Subsystem: Intel Corporation Device 1999
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 90000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at 80000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 31c0 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 06)
	Subsystem: Intel Corporation Device 1999
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: Memory at 90400000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
	Subsystem: Intel Corporation Device 0000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 20
	Region 0: Memory at 91900000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at 91920000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at 30e0 [size=32]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [e0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: e1000e

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation Optiplex 755
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 4: I/O ports at 30c0 [size=32]
	Capabilities: [50] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: uhci_hcd

00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation Optiplex 755
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 21
	Region 4: I/O ports at 30a0 [size=32]
	Capabilities: [50] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: uhci_hcd

00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation Optiplex 755
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 19
	Region 0: Memory at 91921400 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci_hcd

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00002000-00002fff
	Memory behind bridge: 90500000-918fffff
	Prefetchable memory behind bridge: 00000000fe900000-00000000feafffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
			ClockPM- Surprise- LLActRep+ BwNot-
		LnkCtl:	ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train+ SlotClk+ DLActive+ BWMgmt- ABWMgmt-
		SltCap:	AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
			Slot #0, PowerLimit 6.500W; Interlock- NoCompl-
		SltCtl:	Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
			Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
		SltSta:	Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
			Changed: MRL- PresDet+ LinkState+
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [90] Subsystem: Gammagraphx, Inc. (or missing ID) Device 0000
	Capabilities: [a0] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 4: I/O ports at 3080 [size=32]
	Capabilities: [50] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: uhci_hcd

00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 4: I/O ports at 3060 [size=32]
	Capabilities: [50] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: uhci_hcd

00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 18
	Region 4: I/O ports at 3040 [size=32]
	Capabilities: [50] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: uhci_hcd

00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 16
	Region 4: I/O ports at 3020 [size=32]
	Capabilities: [50] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: uhci_hcd

00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at 91921000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci_hcd

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [50] Subsystem: Gammagraphx, Inc. (or missing ID) Device 0000

00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
	Subsystem: Intel Corporation ICH9M-E LPC Interface Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [e0] Vendor Specific Information: Len=0c <?>

00:1f.2 IDE interface: Intel Corporation ICH9M/M-E 2 port SATA IDE Controller (rev 03) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: Intel Corporation ICH9M/M-E 2 port SATA IDE Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 0: I/O ports at 31b0 [size=8]
	Region 1: I/O ports at 31a0 [size=4]
	Region 2: I/O ports at 3190 [size=8]
	Region 3: I/O ports at 3180 [size=4]
	Region 4: I/O ports at 3170 [size=16]
	Region 5: I/O ports at 3160 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ata_piix

00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
	Subsystem: Intel Corporation 82801I (ICH9 Family) SMBus Controller
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin C routed to IRQ 11
	Region 0: Memory at 91921800 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at 3000 [size=32]

00:1f.5 IDE interface: Intel Corporation ICH9M/M-E 2 port SATA IDE Controller (rev 03) (prog-if 85 [Master SecO PriO])
	Subsystem: Intel Corporation ICH9M/M-E 2 port SATA IDE Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at 3150 [size=8]
	Region 1: I/O ports at 3140 [size=4]
	Region 2: I/O ports at 3130 [size=8]
	Region 3: I/O ports at 3120 [size=4]
	Region 4: I/O ports at 3110 [size=16]
	Region 5: I/O ports at 3100 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ata_piix

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
	Subsystem: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: I/O ports at 2000 [size=256]
	Region 2: Memory at 90530000 (64-bit, non-prefetchable) [size=4K]
	Region 4: Memory at 90520000 (64-bit, prefetchable) [size=64K]
	Expansion ROM at 90500000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v2) Endpoint, MSI 01
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <8us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 4096 bytes
		DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
			ClockPM+ Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis+
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
			 Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
			 Compliance De-emphasis: -6dB
		LnkSta2: Current De-emphasis Level: -6dB
	Capabilities: [ac] MSI-X: Enable- Count=2 Masked-
		Vector table: BAR=4 offset=00000000
		PBA: BAR=4 offset=00000800
	Capabilities: [cc] Vital Product Data
		Unknown small resource type 05, will not decode more.
	Kernel driver in use: r8169


[-- Attachment #3: config --]
[-- Type: text/plain, Size: 52138 bytes --]

#
# Automatically generated make config: don't edit
# Linux/x86_64 2.6.37-rc3 Kernel Configuration
# Fri Jan 21 16:58:37 2011
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
# CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
# CONFIG_AUTO_IRQ_AFFINITY is not set
# CONFIG_IRQ_PER_CPU is not set
# CONFIG_HARDIRQS_SW_RESEND is not set
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=19
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_PERF_COUNTERS is not set
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_SCHED_OMIT_FRAME_POINTER is not set
# CONFIG_PARAVIRT_GUEST is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
CONFIG_MAXSMP=y
CONFIG_NR_CPUS=4096
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
# CONFIG_NUMA is not set
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_MEMORY_PROBE=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
# CONFIG_MEMORY_HOTREMOVE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
# CONFIG_HWPOISON_INJECT is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND_NVS=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_RUNTIME=y
CONFIG_PM_OPS=y
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_PROCESSOR_AGGREGATOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_SBS=y
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
CONFIG_I7300_IDLE_IOAT_CHANNEL=y
CONFIG_I7300_IDLE=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_MMCONFIG is not set
CONFIG_PCI_DOMAINS=y
# CONFIG_PCI_CNB20LE_QUIRK is not set
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCIE_ECRC=y
CONFIG_PCIEAER_INJECT=y
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIE_PME=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
# CONFIG_HT_IRQ is not set
# CONFIG_PCI_IOV is not set
CONFIG_PCI_IOAPIC=y
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=y
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=y
CONFIG_NF_CT_PROTO_GRE=y
CONFIG_NF_CT_PROTO_SCTP=y
# CONFIG_NF_CT_PROTO_UDPLITE is not set
CONFIG_NF_CONNTRACK_AMANDA=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_H323=y
CONFIG_NF_CONNTRACK_IRC=y
CONFIG_NF_CONNTRACK_NETBIOS_NS=y
CONFIG_NF_CONNTRACK_PPTP=y
CONFIG_NF_CONNTRACK_SANE=y
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CONNTRACK_TFTP=y
CONFIG_NF_CT_NETLINK=y
# CONFIG_NETFILTER_TPROXY is not set
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=y
CONFIG_NETFILTER_XT_CONNMARK=y

#
# Xtables targets
#
# CONFIG_NETFILTER_XT_TARGET_CHECKSUM is not set
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
# CONFIG_NETFILTER_XT_TARGET_CT is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_HL=y
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y
CONFIG_NETFILTER_XT_TARGET_LED=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
# CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set
CONFIG_NETFILTER_XT_TARGET_RATEEST=y
CONFIG_NETFILTER_XT_TARGET_TEE=y
# CONFIG_NETFILTER_XT_TARGET_TRACE is not set
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set

#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_CLUSTER=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_CPU=y
CONFIG_NETFILTER_XT_MATCH_DCCP=y
CONFIG_NETFILTER_XT_MATCH_DSCP=y
CONFIG_NETFILTER_XT_MATCH_ESP=y
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_HL=y
CONFIG_NETFILTER_XT_MATCH_IPRANGE=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_OSF=y
CONFIG_NETFILTER_XT_MATCH_OWNER=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_QUOTA=y
CONFIG_NETFILTER_XT_MATCH_RATEEST=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
CONFIG_NETFILTER_XT_MATCH_RECENT=y
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_TIME=y
CONFIG_NETFILTER_XT_MATCH_U32=y
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_AH=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=y
CONFIG_NF_NAT_PROTO_GRE=y
CONFIG_NF_NAT_PROTO_SCTP=y
CONFIG_NF_NAT_FTP=y
CONFIG_NF_NAT_IRC=y
CONFIG_NF_NAT_TFTP=y
CONFIG_NF_NAT_AMANDA=y
CONFIG_NF_NAT_PPTP=y
CONFIG_NF_NAT_H323=y
CONFIG_NF_NAT_SIP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_SECURITY=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
CONFIG_RPS=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y

#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
# CONFIG_IDE_GD_ATAPI is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8172 is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=y
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_SATA_INIC162X=y
CONFIG_SATA_SIL24=y
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=y
CONFIG_SATA_SX4=y
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=y
CONFIG_SATA_NV=y
CONFIG_SATA_PROMISE=y
CONFIG_SATA_SIL=y
CONFIG_SATA_SIS=y
CONFIG_SATA_SVW=y
CONFIG_SATA_ULI=y
CONFIG_SATA_VIA=y
CONFIG_SATA_VITESSE=y

#
# PATA SFF controllers with BMDMA
#
CONFIG_PATA_ALI=y
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
CONFIG_PATA_ATP867X=y
CONFIG_PATA_CMD64X=y
CONFIG_PATA_CS5520=y
CONFIG_PATA_CS5530=y
CONFIG_PATA_CYPRESS=y
CONFIG_PATA_EFAR=y
CONFIG_PATA_HPT366=y
CONFIG_PATA_HPT37X=y
CONFIG_PATA_HPT3X2N=y
CONFIG_PATA_HPT3X3=y
CONFIG_PATA_HPT3X3_DMA=y
CONFIG_PATA_IT8213=y
CONFIG_PATA_IT821X=y
CONFIG_PATA_JMICRON=y
CONFIG_PATA_MARVELL=y
CONFIG_PATA_NETCELL=y
CONFIG_PATA_NINJA32=y
CONFIG_PATA_NS87415=y
CONFIG_PATA_OLDPIIX=y
CONFIG_PATA_OPTIDMA=y
CONFIG_PATA_PDC2027X=y
CONFIG_PATA_PDC_OLD=y
CONFIG_PATA_RADISYS=y
CONFIG_PATA_RDC=y
CONFIG_PATA_SC1200=y
CONFIG_PATA_SCH=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_SIL680=y
CONFIG_PATA_SIS=y
CONFIG_PATA_TOSHIBA=y
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_VIA=y
CONFIG_PATA_WINBOND=y

#
# PIO-only SFF controllers
#
CONFIG_PATA_CMD640_PCI=y
CONFIG_PATA_MPIIX=y
CONFIG_PATA_NS87410=y
CONFIG_PATA_OPTI=y
CONFIG_PATA_RZ1000=y

#
# Generic fallback / legacy drivers
#
CONFIG_PATA_ACPI=y
CONFIG_ATA_GENERIC=y
CONFIG_PATA_LEGACY=y
# CONFIG_MD is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
CONFIG_MII=y
# CONFIG_PHYLIB is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_STMMAC_ETH is not set
# CONFIG_PCH_GBE is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
# CONFIG_WLAN is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_WAN is not set

#
# CAIF transport drivers
#
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=y
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_LKKBD=y
CONFIG_KEYBOARD_NEWTON=y
CONFIG_KEYBOARD_OPENCORES=y
CONFIG_KEYBOARD_STOWAWAY=y
CONFIG_KEYBOARD_SUNKBD=y
CONFIG_KEYBOARD_XTKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_PS2_SENTELIC=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_APPLETOUCH=y
CONFIG_MOUSE_BCM5974=y
CONFIG_MOUSE_VSXXXAA=y
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_WINBOND_CIR is not set
# CONFIG_INPUT_ADXL34X is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=y
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_VIA=y
# CONFIG_NVRAM is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=y
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_RAMOOPS is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=y
CONFIG_SSB_SPROM=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
# CONFIG_SSB_B43_PCI_BRIDGE is not set
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y
# CONFIG_MFD_SUPPORT is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=64
# CONFIG_VGA_SWITCHEROO is not set
# CONFIG_DRM is not set
# CONFIG_STUB_POULSBO is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_LOGO is not set
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_3M_PCT=y
CONFIG_HID_A4TECH=y
CONFIG_HID_ACRUX_FF=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CANDO=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_HID_DRAGONRISE=y
CONFIG_DRAGONRISE_FF=y
CONFIG_HID_EGALAX=y
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
CONFIG_HID_GYRATION=y
CONFIG_HID_TWINHAN=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_LOGITECH_FF=y
CONFIG_LOGIRUMBLEPAD2_FF=y
CONFIG_LOGIG940_FF=y
# CONFIG_LOGIWII_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MOSART=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_ORTEK=y
CONFIG_HID_PANTHERLORD=y
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_PICOLCD=y
CONFIG_HID_PICOLCD_FB=y
CONFIG_HID_PICOLCD_LEDS=y
CONFIG_HID_QUANTA=y
CONFIG_HID_ROCCAT=y
CONFIG_HID_ROCCAT_KONE=y
# CONFIG_HID_ROCCAT_PYRA is not set
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_STANTUM=y
CONFIG_HID_SUNPLUS=y
CONFIG_HID_GREENASIA=y
CONFIG_GREENASIA_FF=y
CONFIG_HID_SMARTJOYPLUS=y
CONFIG_SMARTJOYPLUS_FF=y
CONFIG_HID_TOPSEED=y
CONFIG_HID_THRUSTMASTER=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_HID_ZEROPLUS=y
CONFIG_ZEROPLUS_FF=y
CONFIG_HID_ZYDACRON=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_MON is not set
CONFIG_USB_WUSB=y
CONFIG_USB_WUSB_CBAF=y
# CONFIG_USB_WUSB_CBAF_DEBUG is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_ISP1362_HCD=y
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_SL811_HCD=y
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
CONFIG_USB_HWA_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_UAS is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_EZUSB is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MOTOROLA is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_QCAUX is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SAMBA is not set
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_SYMBOL is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_VIVOPAY_SERIAL is not set
# CONFIG_USB_SERIAL_ZIO is not set
# CONFIG_USB_SERIAL_SSU100 is not set
CONFIG_USB_SERIAL_DEBUG=y

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
CONFIG_UWB=y
CONFIG_UWB_HWA=y
# CONFIG_UWB_WHCI is not set
# CONFIG_UWB_I1480U is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_ALIX2=y
CONFIG_LEDS_CLEVO_MAIL=y
# CONFIG_LEDS_INTEL_SS4200 is not set
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=y
# CONFIG_LEDS_TRIGGER_IDE_DISK is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
CONFIG_INTEL_IOATDMA=y
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set
CONFIG_DCA=y
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=y
CONFIG_UIO_CIF=y
CONFIG_UIO_PDRV=y
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_UIO_AEC=y
CONFIG_UIO_SERCOS3=y
CONFIG_UIO_PCI_GENERIC=y
# CONFIG_UIO_NETX is not set
# CONFIG_STAGING is not set
# CONFIG_X86_PLATFORM_DEVICES is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
CONFIG_FSCACHE=y
# CONFIG_FSCACHE_STATS is not set
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=y
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
# CONFIG_MISC_FILESYSTEMS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_HARDLOCKUP_DETECTOR is not set
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
CONFIG_BKL=y
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_LOCK_STAT is not set
CONFIG_TRACE_IRQFLAGS=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_LKDTM is not set
# CONFIG_CPU_NOTIFIER_ERROR_INJECT is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_RING_BUFFER=y
CONFIG_FTRACE_NMI_ENTER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACE_BRANCH_PROFILING=y
# CONFIG_BRANCH_PROFILE_NONE is not set
CONFIG_PROFILE_ANNOTATED_BRANCHES=y
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_TRACING_BRANCHES=y
CONFIG_BRANCH_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
CONFIG_MMIOTRACE=y
# CONFIG_MMIOTRACE_TEST is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_BUILD_DOCSRC is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
CONFIG_KGDB_LOW_LEVEL_TRAP=y
# CONFIG_KGDB_KDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DEBUG_NX_TEST is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_IMA is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
# CONFIG_VIRTUALIZATION is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_NLATTR=y