Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

[Robert P. J. Day]

"dirver"?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

is there a reason for include/uapi/drm to contain files not in Kbuild?

[Robert P. J. Day]

  just noticed that, in include/uapi/drm/, there are three header
files:

* armada_drm.h
* etnaviv_drm.h
* omap_drm.h

that are not referenced in the corresponding Kbuild file. is there any
rationale for this? in general, is there *any* reason for header files
under include/uapi/ to not be mentioned in their respective Kbuild
files?

rday


-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

[PATCH][DRM] Tweak DRM-related kernel-doc content to get rid of warnings.

[Robert P. J. Day]

Fix kernel-doc content to suppress warnings. No functional change.

Signed-off-by: Robert P. J. Day 

---

  someone is welcome to peruse this and tweak it further if they wish.
this gets rid of all of the DRM-related kerneldoc warnings.

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2acfdb..7591e70 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -982,14 +982,15 @@ EXPORT_SYMBOL(drm_edid_is_valid);

 #define DDC_SEGMENT_ADDR 0x30
 /**
- * Get EDID information via I2C.
- *
- * \param adapter : i2c device adaptor
- * \param buf : EDID data buffer to be filled
- * \param len : EDID data buffer length
- * \return 0 on success or -1 on failure.
+ * drm_do_probe_ddc_edid - get EDID information via I2C.
+ * @adapter:   i2c device adaptor
+ * @buf:   EDID data buffer to be filled
+ * @block: start block
+ * @len:   EDID data buffer length
  *
  * Try to fetch EDID information by calling i2c driver function.
+ *
+ * Return: 0 on success or -1 on failure.
  */
 static int
 drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
@@ -1128,10 +1129,11 @@ out:
 }

 /**
- * Probe DDC presence.
+ * drm_probe_ddc - probe DDC presence.
+ *
+ * @adapter: i2c device adaptor
  *
- * \param adapter : i2c device adaptor
- * \return 1 on success
+ * Return: 1 on success
  */
 bool
 drm_probe_ddc(struct i2c_adapter *adapter)
@@ -1455,8 +1457,10 @@ bad_std_timing(u8 a, u8 b)

 /**
  * drm_mode_std - convert standard mode info (width, height, refresh) into mode
+ * @connector: DRM connector
+ * @edid: EDID structure
  * @t: standard timing params
- * @timing_level: standard timing level
+ * @revision: revision
  *
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
@@ -2001,6 +2005,7 @@ do_established_modes(struct detailed_timing *timing, void 
*c)

 /**
  * add_established_modes - get est. modes from EDID and add them
+ * @connector: DRM connector
  * @edid: EDID block to scan
  *
  * Each EDID block contains a bitmap of the supported "established modes" list
@@ -2063,6 +2068,7 @@ do_standard_modes(struct detailed_timing *timing, void *c)

 /**
  * add_standard_modes - get std. modes from EDID and add them
+ * @connector: DRM connector
  * @edid: EDID block to scan
  *
  * Standard modes can be calculated using the appropriate standard (DMT,
@@ -2232,7 +2238,8 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define EDID_CEA_VCDB_QS   (1 << 6)

 /**
- * Search EDID for CEA extension block.
+ * drm_find_cea_extension - search EDID for CEA extension block.
+ * @edid: EDID block to search
  */
 u8 *drm_find_cea_extension(struct edid *edid)
 {
@@ -2605,6 +2612,7 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor);

 /**
  * drm_detect_monitor_audio - check monitor audio capability
+ * @edid: EDID block to search
  *
  * Monitor should have CEA extension block.
  * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic
@@ -2650,6 +2658,7 @@ EXPORT_SYMBOL(drm_detect_monitor_audio);

 /**
  * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
+ * @edid: EDID block to search
  *
  * Check whether the monitor reports the RGB quantization range selection
  * as supported. The AVI infoframe can then be used to inform the monitor

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

is someone fixing the erroneous kerneldoc content in drivers/gpu/drm/?

[Robert P. J. Day]

  currently running "make htmldocs" generates warnings:

  DOCPROC Documentation/DocBook/drm.xml
Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description 
found for parameter 'adapter'
Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description 
found for parameter 'buf'
Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description 
found for parameter 'block'
... etc etc ...
  HTMLDocumentation/DocBook/drm.html

because some files use "\param" which is not what kerneldoc needs to
see. was someone already working to clean that up?

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

is someone fixing the erroneous kerneldoc content in drivers/gpu/drm/?

[Robert P. J. Day]

  currently running make htmldocs generates warnings:

  DOCPROC Documentation/DocBook/drm.xml
Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description 
found for parameter 'adapter'
Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description 
found for parameter 'buf'
Warning(/home/rpjday/k/git//drivers/gpu/drm/drm_edid.c:997): No description 
found for parameter 'block'
... etc etc ...
  HTMLDocumentation/DocBook/drm.html

because some files use \param which is not what kerneldoc needs to
see. was someone already working to clean that up?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH][DRM] Tweak DRM-related kernel-doc content to get rid of warnings.

[Robert P. J. Day]

Fix kernel-doc content to suppress warnings. No functional change.

Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca

---

  someone is welcome to peruse this and tweak it further if they wish.
this gets rid of all of the DRM-related kerneldoc warnings.

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2acfdb..7591e70 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -982,14 +982,15 @@ EXPORT_SYMBOL(drm_edid_is_valid);

 #define DDC_SEGMENT_ADDR 0x30
 /**
- * Get EDID information via I2C.
- *
- * \param adapter : i2c device adaptor
- * \param buf : EDID data buffer to be filled
- * \param len : EDID data buffer length
- * \return 0 on success or -1 on failure.
+ * drm_do_probe_ddc_edid - get EDID information via I2C.
+ * @adapter:   i2c device adaptor
+ * @buf:   EDID data buffer to be filled
+ * @block: start block
+ * @len:   EDID data buffer length
  *
  * Try to fetch EDID information by calling i2c driver function.
+ *
+ * Return: 0 on success or -1 on failure.
  */
 static int
 drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
@@ -1128,10 +1129,11 @@ out:
 }

 /**
- * Probe DDC presence.
+ * drm_probe_ddc - probe DDC presence.
+ *
+ * @adapter: i2c device adaptor
  *
- * \param adapter : i2c device adaptor
- * \return 1 on success
+ * Return: 1 on success
  */
 bool
 drm_probe_ddc(struct i2c_adapter *adapter)
@@ -1455,8 +1457,10 @@ bad_std_timing(u8 a, u8 b)

 /**
  * drm_mode_std - convert standard mode info (width, height, refresh) into mode
+ * @connector: DRM connector
+ * @edid: EDID structure
  * @t: standard timing params
- * @timing_level: standard timing level
+ * @revision: revision
  *
  * Take the standard timing params (in this case width, aspect, and refresh)
  * and convert them into a real mode using CVT/GTF/DMT.
@@ -2001,6 +2005,7 @@ do_established_modes(struct detailed_timing *timing, void 
*c)

 /**
  * add_established_modes - get est. modes from EDID and add them
+ * @connector: DRM connector
  * @edid: EDID block to scan
  *
  * Each EDID block contains a bitmap of the supported established modes list
@@ -2063,6 +2068,7 @@ do_standard_modes(struct detailed_timing *timing, void *c)

 /**
  * add_standard_modes - get std. modes from EDID and add them
+ * @connector: DRM connector
  * @edid: EDID block to scan
  *
  * Standard modes can be calculated using the appropriate standard (DMT,
@@ -2232,7 +2238,8 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define EDID_CEA_VCDB_QS   (1  6)

 /**
- * Search EDID for CEA extension block.
+ * drm_find_cea_extension - search EDID for CEA extension block.
+ * @edid: EDID block to search
  */
 u8 *drm_find_cea_extension(struct edid *edid)
 {
@@ -2605,6 +2612,7 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor);

 /**
  * drm_detect_monitor_audio - check monitor audio capability
+ * @edid: EDID block to search
  *
  * Monitor should have CEA extension block.
  * If monitor has 'basic audio', but no CEA audio blocks, it's 'basic
@@ -2650,6 +2658,7 @@ EXPORT_SYMBOL(drm_detect_monitor_audio);

 /**
  * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
+ * @edid: EDID block to search
  *
  * Check whether the monitor reports the RGB quantization range selection
  * as supported. The AVI infoframe can then be used to inform the monitor

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] DRM DRIVERS: Remove unnecessary test for ARM.

[Robert P. J. Day]

Since arch/arm/include/asm/pgtable.h contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)

there is no point treating ARM as a special case in distinguishing
between remap_pfn_range() and io_remap_pfn_range().

Signed-off-by: Robert P. J. Day 

---

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 961ee08..34e6503 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -619,20 +619,11 @@ int drm_mmap_locked(struct file *filp, struct 
vm_area_struct *vma)
offset = drm_core_get_reg_ofs(dev);
vma->vm_flags |= VM_IO; /* not in core dump */
vma->vm_page_prot = drm_io_prot(map->type, vma);
-#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
   (map->offset + offset) >> PAGE_SHIFT,
   vma->vm_end - vma->vm_start,
   vma->vm_page_prot))
return -EAGAIN;
-#else
-   if (remap_pfn_range(vma, vma->vm_start,
-   (map->offset + offset) >> PAGE_SHIFT,
-   vma->vm_end - vma->vm_start,
-   vma->vm_page_prot))
-   return -EAGAIN;
-#endif
-
DRM_DEBUG("   Type = %d; start = 0x%lx, end = 0x%lx,"
  " offset = 0x%llx\n",
  map->type,

-- 

============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

[Robert P. J. Day]

On Thu, 30 Aug 2012, Robert P. J. Day wrote:

> On Thu, 30 Aug 2012, Sascha Hauer wrote:
>
> > On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote:
> > >
> > >   a pedantic observation, you can do with it what you wish (i'm not a
> > > list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):
> > >
> > > #if !defined(__arm__)
> > > if (io_remap_pfn_range(vma, vma->vm_start,
> > >(map->offset + offset) >> 
> > > PAGE_SHIFT,
> > >vma->vm_end - vma->vm_start,
> > >vma->vm_page_prot))
> > > return -EAGAIN;
> > > #else
> > > if (remap_pfn_range(vma, vma->vm_start,
> > > (map->offset + offset) >> 
> > > PAGE_SHIFT,
> > > vma->vm_end - vma->vm_start,
> > > vma->vm_page_prot))
> > > return -EAGAIN;
> > > #endif
> >
> > This code goes down to:
> >
> > commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6
> > Author: Jordan Crouse 
> > Date:   Thu May 27 13:40:26 2010 -0600
> >
> > drm: Add __arm defines to DRM
> >
> > Add __arm defines to specify behavior specific for
> > an ARM processor.
> >
> > Signed-off-by: Jordan Crouse 
> > Signed-off-by: Dave Airlie 
> >
> > Even at that time io_remap_pfn_range on arm was defined as:
> >
> > >
> > > #define io_remap_pfn_range(vma,from,pfn,size,prot) \
> > > remap_pfn_range(vma, from, pfn, size, prot)
> > >
> > > so it's not clear what the preprocessor test is for.  admittedly, it
> > > should work, it just seems unnecessary.  and it makes the code more
> > > confusing than it needs to be, but perhaps i've just misread
> > > something.
> >
> > I agree that this shouldn't be necessary.
>
>   for simplicity, i can submit a patch that just does a straight call
> to remap_pfn_range(), unless someone can recognize something really
> subtle happening here.

  sorry, that should have been a straight call to io_remap_pfn_range()
since that is the call invoked for all but ARM.  i'll post a patch
shortly and someone else can decide whether or not to apply it.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

[Robert P. J. Day]

On Thu, 30 Aug 2012, Sascha Hauer wrote:

> On Wed, Aug 29, 2012 at 06:29:53PM -0400, Robert P. J. Day wrote:
> >
> >   a pedantic observation, you can do with it what you wish (i'm not a
> > list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):
> >
> > #if !defined(__arm__)
> > if (io_remap_pfn_range(vma, vma->vm_start,
> >(map->offset + offset) >> PAGE_SHIFT,
> >vma->vm_end - vma->vm_start,
> >vma->vm_page_prot))
> > return -EAGAIN;
> > #else
> > if (remap_pfn_range(vma, vma->vm_start,
> > (map->offset + offset) >> 
> > PAGE_SHIFT,
> > vma->vm_end - vma->vm_start,
> > vma->vm_page_prot))
> > return -EAGAIN;
> > #endif
>
> This code goes down to:
>
> commit 4b7fb9b5746554d460e7bc986341d4b2db01e0b6
> Author: Jordan Crouse 
> Date:   Thu May 27 13:40:26 2010 -0600
>
> drm: Add __arm defines to DRM
>
> Add __arm defines to specify behavior specific for
> an ARM processor.
>
> Signed-off-by: Jordan Crouse 
> Signed-off-by: Dave Airlie 
>
> Even at that time io_remap_pfn_range on arm was defined as:
>
> >
> > #define io_remap_pfn_range(vma,from,pfn,size,prot) \
> > remap_pfn_range(vma, from, pfn, size, prot)
> >
> > so it's not clear what the preprocessor test is for.  admittedly, it
> > should work, it just seems unnecessary.  and it makes the code more
> > confusing than it needs to be, but perhaps i've just misread
> > something.
>
> I agree that this shouldn't be necessary.

  for simplicity, i can submit a patch that just does a straight call
to remap_pfn_range(), unless someone can recognize something really
subtle happening here.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

[Robert P. J. Day]

  a pedantic observation, you can do with it what you wish (i'm not a
list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):

#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma->vm_start,
   (map->offset + offset) >> PAGE_SHIFT,
   vma->vm_end - vma->vm_start,
   vma->vm_page_prot))
return -EAGAIN;
#else
if (remap_pfn_range(vma, vma->vm_start,
(map->offset + offset) >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
#endif

suggesting that only with ARM need we distinguish between those two
routines.  but for various architectures, in pgtable.h, you can see:

#define io_remap_pfn_range  remap_pfn_range

even the arm file contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)

so it's not clear what the preprocessor test is for.  admittedly, it
should work, it just seems unnecessary.  and it makes the code more
confusing than it needs to be, but perhaps i've just misread
something.

rday

-- 

================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

drm_vm.c: many arches equate remap_pfn_range() and io_remap_pfn_range()

[Robert P. J. Day]

  a pedantic observation, you can do with it what you wish (i'm not a
list subscriber).  in drivers/gpu/drm/drm_vm.c, we read (line 629):

#if !defined(__arm__)
if (io_remap_pfn_range(vma, vma-vm_start,
   (map-offset + offset)  PAGE_SHIFT,
   vma-vm_end - vma-vm_start,
   vma-vm_page_prot))
return -EAGAIN;
#else
if (remap_pfn_range(vma, vma-vm_start,
(map-offset + offset)  PAGE_SHIFT,
vma-vm_end - vma-vm_start,
vma-vm_page_prot))
return -EAGAIN;
#endif

suggesting that only with ARM need we distinguish between those two
routines.  but for various architectures, in pgtable.h, you can see:

#define io_remap_pfn_range  remap_pfn_range

even the arm file contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
remap_pfn_range(vma, from, pfn, size, prot)

so it's not clear what the preprocessor test is for.  admittedly, it
should work, it just seems unnecessary.  and it makes the code more
confusing than it needs to be, but perhaps i've just misread
something.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 "black screen of death" clearly still an issue

[Robert P. J. Day]

  i just built a kernel for my ubuntu 10.10 system and forgot to
include the following patch which is what i've needed to avoid the
dreaded black screen of death:

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index d2c7104..a1a5d03 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
struct opregion_asle *asle = dev_priv->opregion.asle;
u32 max;

+return ASLE_BACKLIGHT_FAILED; // rday
+
if (!(bclp & ASLE_BCLP_VALID))
return ASLE_BACKLIGHT_FAILED;



  and i once again got the black screen.  is this still a known and
unresolved issue?

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

i915 black screen of death clearly still an issue

[Robert P. J. Day]

  i just built a kernel for my ubuntu 10.10 system and forgot to
include the following patch which is what i've needed to avoid the
dreaded black screen of death:

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index d2c7104..a1a5d03 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
struct opregion_asle *asle = dev_priv-opregion.asle;
u32 max;

+return ASLE_BACKLIGHT_FAILED; // rday
+
if (!(bclp  ASLE_BCLP_VALID))
return ASLE_BACKLIGHT_FAILED;



  and i once again got the black screen.  is this still a known and
unresolved issue?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

it *appears* the i915 black screen of death issue is back

[Robert P. J. Day]

  when i built a new kernel based on the latest git tree, i once again
got the black screen of death on my gateway laptop with an integrated
intel graphics controller.

  and as i did not that long ago, i got around it by applying the
following tweak to the source tree before rebuilding:

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index d2c7104..a1a5d03 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -152,6 +152,8 @@ static u32 asle_set_backlight(struct drm_device
*dev, u32 bclp)
struct opregion_asle *asle = dev_priv->opregion.asle;
u32 max;

+return ASLE_BACKLIGHT_FAILED; // rday
+
if (!(bclp & ASLE_BCLP_VALID))
return ASLE_BACKLIGHT_FAILED;


  so if this issue was resolved, it seems to have regressed.

rday

-- 

====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Tue, 1 Feb 2011, Chris Wilson wrote:

> On Tue, 1 Feb 2011 07:05:16 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >
> >   any new developments on this issue?
>
> Not really, the only thing left to confirm is whereabouts it goes wrong.
>
> About the only routine of significance is alse_set_backlight().
>
> Does a 'return ASLE_BACKLIGHT_FAILED;' as the first line of that function
> have a similar effect to the current hack?

  apparently, it does:

@@ -150,6 +150,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
struct opregion_asle *asle = dev_priv->opregion.asle;
u32 max;

+return ASLE_BACKLIGHT_FAILED; // rday
+
if (!(bclp & ASLE_BCLP_VALID))
return ASLE_BACKLIGHT_FAILED;



gives me a good boot.  this is the diff with relation to the recently
tagged 2.6.38-rc3.  anything else you want me to test?

rday

-- 

================
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

  any new developments on this issue?  the current kernel is working
just fine with the addition of that trivial hack in
drivers/gpu/drm/i915/intel_opregion.c:

@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;

but i'm obviously still interested in the proper resolution.  let me
know if you want me to do any more testing.

rday

-- 

================
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

  any new developments on this issue?  the current kernel is working
just fine with the addition of that trivial hack in
drivers/gpu/drm/i915/intel_opregion.c:

@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion-acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes  MBOX_SWSCI) {
DRM_DEBUG_DRIVER(SWSCI supported\n);
opregion-swsci = base + OPREGION_SWSCI_OFFSET;

but i'm obviously still interested in the proper resolution.  let me
know if you want me to do any more testing.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Tue, 1 Feb 2011, Chris Wilson wrote:

 On Tue, 1 Feb 2011 07:05:16 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
 
any new developments on this issue?

 Not really, the only thing left to confirm is whereabouts it goes wrong.

 About the only routine of significance is alse_set_backlight().

 Does a 'return ASLE_BACKLIGHT_FAILED;' as the first line of that function
 have a similar effect to the current hack?

  apparently, it does:

@@ -150,6 +150,8 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)
struct opregion_asle *asle = dev_priv-opregion.asle;
u32 max;

+return ASLE_BACKLIGHT_FAILED; // rday
+
if (!(bclp  ASLE_BCLP_VALID))
return ASLE_BACKLIGHT_FAILED;



gives me a good boot.  this is the diff with relation to the recently
tagged 2.6.38-rc3.  anything else you want me to test?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

  i realize i already posted this to the LKML and CCed it here but,
just to summarize, i have a current "git pull" kernel booting fine,
with the following patch applied:

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;


  feel free to suggest more testing.

rday

-- 

================
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

  i realize i already posted this to the LKML and CCed it here but,
just to summarize, i have a current git pull kernel booting fine,
with the following patch applied:

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion-acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes  MBOX_SWSCI) {
DRM_DEBUG_DRIVER(SWSCI supported\n);
opregion-swsci = base + OPREGION_SWSCI_OFFSET;


  feel free to suggest more testing.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:

> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h .  Please
> try that and see if it makes a difference.

  as a quick followup, i applied the following simple patch:

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;


to the latest tree, and it gave me a booting kernel, no black screen
issue.  i will not pretend to understand why that fixes the problem
but it does.

rday

-- 

============
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:

> On Friday, January 28, 2011, Robert P. J. Day wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"  > > crashcourse.ca> wrote:
> > > >   sadly, no change -- still black screen.  again, rebooted
> > > > successfully under commit 8a327f23.  just to be clear, here's "git
> > > > diff":
> > > >
> > > > $ git diff
> > > > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > > > index 7180013..e035f3c 100644
> > > > --- a/include/linux/acpi_io.h
> > > > +++ b/include/linux/acpi_io.h
> > > > @@ -7,7 +7,7 @@
> > > >  static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > > > acpi_size size)
> > > >  {
> > > > -   return ioremap_cache(phys, size);
> > > > +   return ioremap(phys, size);
> > > >  }
> > >
> > > Ok, that implies the new mapping is fine and not the cause of the issue.
> > >
> > > Instead you have some OpRegion related regression hidden until till now
> > > because the conflicting mapping disabled it for i915.
> > >
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > > index 9efccb9..8c93201 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > > u32 asls, mboxes;
> > > int err = 0;
> > >
> > > +   return -ENOTSUPP;
> > > +
> > >
> > > pci_read_config_dword(dev->pdev, PCI_ASLS, );
> > > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > > if (asls == 0) {
> > >
> >
> > so you want me to revert to a stock b705120e before doing the above?
>
> Alternatively, you could take the vanilla Linus' tree and replace
> ioremap_cache() with ioremap() in include/linux/acpi_io.h .  Please try that
> and see if it makes a difference.

  been there, done that, that's all so ... this morning.  i continued
bisecting and playing and eventually verified the following
workaround for an earlier working version of the kernel:

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;


  this was based on a suggestion by chris wilson to deactivate the
"mboxes" tests in that single source file and see what happened.
adding the "return 0" above suddenly gave me a properly booting
kernel.  i applied the same diff to the current kernel and it's
building as we speak.

rday

p.s.  having that "return 0" *after* that test but before the next one
still gave me a black screen.

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 11:23:08 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >   all right.  and since we're beyond git bisection, can you post a
> > list of say 2 or 3 tests you want me to try in order?  as you're the
> > expert here, it would make more sense for you to try to optimize the
> > search pattern here.
>
> If the machine is booting (just with a blank screen), then enable
> drm.debug=0xe, and check that it is being written to the system log
> files. Then boot into the broken setup, reboot and grab the debug
> messages saved from the previous (broken) boot.
>
> Otherwise we shall just wait for the opportunity to log in with a second
> machine and look for telltales before beginning exploratory surgery.

  ok, this is what works:

==

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.
index 64fd644..645581f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,10 +495,15 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes & MBOX_SWSCI) {
DRM_DEBUG_DRIVER("SWSCI supported\n");
opregion->swsci = base + OPREGION_SWSCI_OFFSET;
}
+
+return 0; // rday
+
if (mboxes & MBOX_ASLE) {
DRM_DEBUG_DRIVER("ASLE supported\n");
opregion->asle = base + OPREGION_ASLE_OFFSET;

==

  *first*, i added the *later* "return 0", and still got the black
screen.  i then added the one *above* that, and got a good boot, so
one therefore concludes that it's the "SWSCI" processing that's
causing the problem.  of course, that says nothing about whether or
not the later "ASLE" check could be re-enabled, or does that even make
any sense?

  in any event, what's above works.  next?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >   victory is mine!  ok, that premature return seems to have solved it,
> > i'm up and running under this new kernel.  are we getting close?
>
> Not even close. We just disabled functionality that was working in
> 2.6.37; the interaction between ACPI and gfx. What a shame.
>
> Instead of return -ENOTSUPP at the start, you can return 0 before
> each of the if (mboxes & MBOX_*) to narrow down which function
> regressed.

  are there any kernel config options i should be looking at?  for
better or worse, i've attached my .config file.

  and i'm sequentially returning 0 before each of those tests starting
with the last and working my way back unless you want to prioritize
which tests i should deactivate.

rday

-- 

============
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

-- next part --
#
# Automatically generated make config: don't edit
# Linux/x86_64 2.6.38-rc2 Kernel Configuration
# Fri Jan 28 07:36:39 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_GENERIC_GPIO=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_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=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ 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=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=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=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> We're starting to get into ACPI backlight breakage territory... We
> have identified that the regression was much earlier, just masked by
> other breakage.

  as additional info, i went through this for a while during the
2.6.37-rc* progression.  it came, it went, it came back again.  then
everything was fine with both 2.6.38-rc1 and 2.6.38-rc2, and then
this.  this is on a gateway NV79 laptop running a fully-updated ubuntu
10.10.

> Let's clarify the symptoms: black panel, no backlight, no output at
> all (not even at shallow angles), but the machine is alive?

  exactly, same as it's always been when things fail.  that the
machine is still booting is obvious from lots of disk activity,
culminating in the little ubuntu drum roll at the login screen.  and,
as i mentioned before, i do get a couple early kernel messages
(/dev/pts, ureadahead), and that's where it goes black.  for a *good*
boot, what i would see at that point is the font size getting much
smaller and the boot continuing.

> Can you remotely access the machine and grab debug logs from when it
> is broken?

  i'd love to, but can't at the moment.  i'll see if i can scare up a
second machine later and try it.  if i can, what *precisely* would you
like me to post?  i'm guessing dmesg, Xorg.0.log, that sort of thing.

> >   so, before i launch into this, is there anything else i might
> > report about my system and its current setup that someone might
> > want to know?
>
> We're now just looking for telltale signs of an error.

  all right.  and since we're beyond git bisection, can you post a
list of say 2 or 3 tests you want me to try in order?  as you're the
expert here, it would make more sense for you to try to optimize the
search pattern here.

rday

-- 

============
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 10:27:09 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >   victory is mine!  ok, that premature return seems to have solved it,
> > i'm up and running under this new kernel.  are we getting close?
>
> Not even close. We just disabled functionality that was working in 2.6.37;
> the interaction between ACPI and gfx. What a shame.
>
> Instead of return -ENOTSUPP at the start,
> you can return 0 before each of the if (mboxes & MBOX_*) to narrow down
> which function regressed.

  ok, i'll see how much of that i can get to today.  but at this
point, are we fairly convinced that there *is* a problem?  i'd hate to
go through all this, only to learn at the end that it's something
stupid i did.  it seems odd that no one else has mentioned running
into this -- have you heard no other reports?

  so, before i launch into this, is there anything else i might report
about my system and its current setup that someone might want to know?

rday

-- 

============
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 10:08:07 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > > That would be easy to test by returning early in intel_opregion_setup():
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> > > b/drivers/gpu/drm/i915/intel_
> > > index 9efccb9..8c93201 100644
> > > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > > @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> > > u32 asls, mboxes;
> > > int err = 0;
> > >
> > > +   return -ENOTSUPP;
> > > +
> > >
> > > pci_read_config_dword(dev->pdev, PCI_ASLS, );
> > > DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> > > if (asls == 0) {
> > >
> >
> > so you want me to revert to a stock b705120e before doing the above?
>
> Yes. (Or latter, at this point we have lots of fun ahead.)

  victory is mine!  ok, that premature return seems to have solved it,
i'm up and running under this new kernel.  are we getting close?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 09:51:01 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >   sadly, no change -- still black screen.  again, rebooted
> > successfully under commit 8a327f23.  just to be clear, here's "git
> > diff":
> >
> > $ git diff
> > diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> > index 7180013..e035f3c 100644
> > --- a/include/linux/acpi_io.h
> > +++ b/include/linux/acpi_io.h
> > @@ -7,7 +7,7 @@
> >  static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > acpi_size size)
> >  {
> > -   return ioremap_cache(phys, size);
> > +   return ioremap(phys, size);
> >  }
>
> Ok, that implies the new mapping is fine and not the cause of the issue.
>
> Instead you have some OpRegion related regression hidden until till now
> because the conflicting mapping disabled it for i915.
>
> That would be easy to test by returning early in intel_opregion_setup():
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_
> index 9efccb9..8c93201 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
> u32 asls, mboxes;
> int err = 0;
>
> +   return -ENOTSUPP;
> +
>
> pci_read_config_dword(dev->pdev, PCI_ASLS, );
> DRM_DEBUG_DRIVER("graphic opregion physical addr: 0x%x\n", asls);
> if (asls == 0) {
>

so you want me to revert to a stock b705120e before doing the above?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 09:32:04 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > > fix your boot issue or do we need to go back to using uncached:
> > >
> > > +   return ioremap(phys, size);
> >
> >   is that the next change you want me to try?
>
> Yes. (Replacing the current return ioremap_*(phys, size).)

  sadly, no change -- still black screen.  again, rebooted
successfully under commit 8a327f23.  just to be clear, here's "git
diff":

$ git diff
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..e035f3c 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   return ioremap_cache(phys, size);
+   return ioremap(phys, size);
 }

 int acpi_os_map_generic_address(struct acpi_generic_address *addr);




rday

-- 

================
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karcher 
> > Date:   Sun Jan 23 18:17:17 2011 +
> >
> > drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >
> > The opregion is a shared memory region between ACPI and the graphics
> > driver. As the ACPI mapping has been changed to cachable in commit
> > 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> > non-cachable now fails. As no bus-master hardware is involved in the
> > opregion, cachable map should do no harm.
> >
> > Tested on a Fujitsu Lifebook P8010.
> >
> > Signed-off-by: Michael Karcher 
> > [ickle: convert to acpi_os_ioremap for consistency]
> > Signed-off-by: Chris Wilson 
> >
> >
> >   thoughts?  once again, the salient output from "lspci -v":
>
> Indeed looks like using ioremap_cache is not as safe as was assumed. Does
>
> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..42108ab 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
>  static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
>  {
> -   return ioremap_cache(phys, size);
> +   return ioremap_wc(phys, size);
>  }
>
>  int acpi_os_map_generic_address(struct acpi_generic_address *addr);

  that didn't appear to make a difference.  same black screen issue.
BTW, here's an excerpt from /var/log/dmesg for a *successful* boot (i
just rebooted to 8a327f23):

...
[   24.037114] intel ips :00:1f.6: failed to get i915 symbols, graphics 
turbo disabled
...
[   27.155660] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   27.155665] i915 :00:02.0: setting latency timer to 64
[   27.217407] mtrr: no more MTRRs available
[   27.217411] [drm] MTRR allocation failed.  Graphics performance may suffer.
[   27.217848] ioremap error for 0xb3752000-0xb3755000, requested 0x10, got 0x0
[   27.217933] i915 :00:02.0: irq 42 for MSI/MSI-X
[   27.217938] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   27.217940] [drm] Driver supports precise vblank timestamp query.
...

if any of that is of any use.

> fix your boot issue or do we need to go back to using uncached:
>
> +   return ioremap(phys, size);

  is that the next change you want me to try?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 08:53:59 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > so the culprit appears to be:
> >
> > b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
> > commit b705120e4198315f4ae043de06c62f65e0851fd3
> > Author: Michael Karcher 
> > Date:   Sun Jan 23 18:17:17 2011 +
> >
> > drm/i915: Use consistent mappings for OpRegion between ACPI and i915
> >
> > The opregion is a shared memory region between ACPI and the graphics
> > driver. As the ACPI mapping has been changed to cachable in commit
> > 6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
> > non-cachable now fails. As no bus-master hardware is involved in the
> > opregion, cachable map should do no harm.
> >
> > Tested on a Fujitsu Lifebook P8010.
> >
> > Signed-off-by: Michael Karcher 
> > [ickle: convert to acpi_os_ioremap for consistency]
> > Signed-off-by: Chris Wilson 
> >
> >
> >   thoughts?  once again, the salient output from "lspci -v":
>
> Indeed looks like using ioremap_cache is not as safe as was assumed. Does

  *sigh*.  there was, in fact, an "ioremap_error" message displayed
*very* early in the boot sequence, but it was generated even for
successful boots so i never paid it any mind.  in hindsight, might
have been useful to have mentioned it.

> diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
> index 7180013..42108ab 100644
> --- a/include/linux/acpi_io.h
> +++ b/include/linux/acpi_io.h
> @@ -7,7 +7,7 @@
>  static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> acpi_size size)
>  {
> -   return ioremap_cache(phys, size);
> +   return ioremap_wc(phys, size);
>  }
>
>  int acpi_os_map_generic_address(struct acpi_generic_address *addr);

  ok, i'll make this single change and report back shortly.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> On Fri, 28 Jan 2011 04:24:17 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Fri, 28 Jan 2011, Chris Wilson wrote:
> >
> > > Well, we have two endpoints, so let git attack:
> > >
> > > $ git bisect start
> > > $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> > > $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
> > >
> > > That shouldn't take more than a few recompiles to identify the
> > > troublemaker.
> >
> >   ok, i can get to that in a bit.  might take a while since this
> > system is not exactly a screamer but i'm curious -- have you heard no
> > other reports of people running into this issue?  i'm going to be
> > embarrassed if it turns out it's something *i've* done but, at this
> > point, it seems fairly reproducible.
>
> This is the first I'm aware of. It could just be the tip of the iceberg...

  the git bisection finally resolved to:

  BAD:  b705120e
  GOOD: 8a327f23

so the culprit appears to be:

b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
commit b705120e4198315f4ae043de06c62f65e0851fd3
Author: Michael Karcher 
Date:   Sun Jan 23 18:17:17 2011 +

drm/i915: Use consistent mappings for OpRegion between ACPI and i915

The opregion is a shared memory region between ACPI and the graphics
driver. As the ACPI mapping has been changed to cachable in commit
6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
non-cachable now fails. As no bus-master hardware is involved in the
opregion, cachable map should do no harm.

Tested on a Fujitsu Lifebook P8010.

Signed-off-by: Michael Karcher 
[ickle: convert to acpi_os_ioremap for consistency]
Signed-off-by: Chris Wilson 


  thoughts?  once again, the salient output from "lspci -v":

00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 031c
Flags: bus master, fast devsel, latency 0, IRQ 41
Memory at d000 (64-bit, non-prefetchable) [size=4M]
Memory at c000 (64-bit, prefetchable) [size=256M]
I/O ports at 3050 [size=8]
Expansion ROM at  [disabled]
Capabilities: 
    Kernel driver in use: i915
Kernel modules: i915


rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> Well, we have two endpoints, so let git attack:
>
> $ git bisect start
> $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
>
> That shouldn't take more than a few recompiles to identify the
> troublemaker.

  it appears i have one bisection left to make but, just a bit of
info, the black screen issue kicks in when the kernel tries to change
the font size of the early kernel messages to a much smaller font (or
at least it happens around that time).

  typically, regardless of the kernel, i get a couple of large font
messages (/dev/pts and one other, memory fails me), at which point a
good kernel will switch to a much smaller font and continue.  with a
"bad" kernel, the display on my laptop goes black and stays that way,
despite the fact that the boot is obviously still progressing.

  you can decide if that is at all helpful.  back to bisecting.
should be getting close.

rday

-- 

================
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

> Well, we have two endpoints, so let git attack:
>
> $ git bisect start
> $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
> $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e
>
> That shouldn't take more than a few recompiles to identify the
> troublemaker.

  ok, i can get to that in a bit.  might take a while since this
system is not exactly a screamer but i'm curious -- have you heard no
other reports of people running into this issue?  i'm going to be
embarrassed if it turns out it's something *i've* done but, at this
point, it seems fairly reproducible.

  are there any kernel command-line parms i might try that would be
informative?  anything involving modesetting?

rday

-- 

================
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 Well, we have two endpoints, so let git attack:

 $ git bisect start
 $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e

 That shouldn't take more than a few recompiles to identify the
 troublemaker.

  ok, i can get to that in a bit.  might take a while since this
system is not exactly a screamer but i'm curious -- have you heard no
other reports of people running into this issue?  i'm going to be
embarrassed if it turns out it's something *i've* done but, at this
point, it seems fairly reproducible.

  are there any kernel command-line parms i might try that would be
informative?  anything involving modesetting?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 Well, we have two endpoints, so let git attack:

 $ git bisect start
 $ git bisect good 58bbf018a70c562437eeae121a5d021ba7fe56a5
 $ git bisect bad abb72c828878a2c69b2cfb33ac30007c8ecd735e

 That shouldn't take more than a few recompiles to identify the
 troublemaker.

  it appears i have one bisection left to make but, just a bit of
info, the black screen issue kicks in when the kernel tries to change
the font size of the early kernel messages to a much smaller font (or
at least it happens around that time).

  typically, regardless of the kernel, i get a couple of large font
messages (/dev/pts and one other, memory fails me), at which point a
good kernel will switch to a much smaller font and continue.  with a
bad kernel, the display on my laptop goes black and stays that way,
despite the fact that the boot is obviously still progressing.

  you can decide if that is at all helpful.  back to bisecting.
should be getting close.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 08:53:59 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  so the culprit appears to be:
 
  b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
  commit b705120e4198315f4ae043de06c62f65e0851fd3
  Author: Michael Karcher ker...@mkarcher.dialup.fu-berlin.de
  Date:   Sun Jan 23 18:17:17 2011 +
 
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
 
  The opregion is a shared memory region between ACPI and the graphics
  driver. As the ACPI mapping has been changed to cachable in commit
  6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
  non-cachable now fails. As no bus-master hardware is involved in the
  opregion, cachable map should do no harm.
 
  Tested on a Fujitsu Lifebook P8010.
 
  Signed-off-by: Michael Karcher ker...@mkarcher.dialup.fu-berlin.de
  [ickle: convert to acpi_os_ioremap for consistency]
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 
 
thoughts?  once again, the salient output from lspci -v:

 Indeed looks like using ioremap_cache is not as safe as was assumed. Does

  *sigh*.  there was, in fact, an ioremap_error message displayed
*very* early in the boot sequence, but it was generated even for
successful boots so i never paid it any mind.  in hindsight, might
have been useful to have mentioned it.

 diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
 index 7180013..42108ab 100644
 --- a/include/linux/acpi_io.h
 +++ b/include/linux/acpi_io.h
 @@ -7,7 +7,7 @@
  static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
 acpi_size size)
  {
 -   return ioremap_cache(phys, size);
 +   return ioremap_wc(phys, size);
  }

  int acpi_os_map_generic_address(struct acpi_generic_address *addr);

  ok, i'll make this single change and report back shortly.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 08:53:59 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  so the culprit appears to be:
 
  b705120e4198315f4ae043de06c62f65e0851fd3 is the first bad commit
  commit b705120e4198315f4ae043de06c62f65e0851fd3
  Author: Michael Karcher ker...@mkarcher.dialup.fu-berlin.de
  Date:   Sun Jan 23 18:17:17 2011 +
 
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
 
  The opregion is a shared memory region between ACPI and the graphics
  driver. As the ACPI mapping has been changed to cachable in commit
  6d5bbf00d251cc73223a71422d69e069dc2e0b8d, mapping the intel opregion
  non-cachable now fails. As no bus-master hardware is involved in the
  opregion, cachable map should do no harm.
 
  Tested on a Fujitsu Lifebook P8010.
 
  Signed-off-by: Michael Karcher ker...@mkarcher.dialup.fu-berlin.de
  [ickle: convert to acpi_os_ioremap for consistency]
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 
 
thoughts?  once again, the salient output from lspci -v:

 Indeed looks like using ioremap_cache is not as safe as was assumed. Does

 diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
 index 7180013..42108ab 100644
 --- a/include/linux/acpi_io.h
 +++ b/include/linux/acpi_io.h
 @@ -7,7 +7,7 @@
  static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
 acpi_size size)
  {
 -   return ioremap_cache(phys, size);
 +   return ioremap_wc(phys, size);
  }

  int acpi_os_map_generic_address(struct acpi_generic_address *addr);

  that didn't appear to make a difference.  same black screen issue.
BTW, here's an excerpt from /var/log/dmesg for a *successful* boot (i
just rebooted to 8a327f23):

...
[   24.037114] intel ips :00:1f.6: failed to get i915 symbols, graphics 
turbo disabled
...
[   27.155660] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[   27.155665] i915 :00:02.0: setting latency timer to 64
[   27.217407] mtrr: no more MTRRs available
[   27.217411] [drm] MTRR allocation failed.  Graphics performance may suffer.
[   27.217848] ioremap error for 0xb3752000-0xb3755000, requested 0x10, got 0x0
[   27.217933] i915 :00:02.0: irq 42 for MSI/MSI-X
[   27.217938] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   27.217940] [drm] Driver supports precise vblank timestamp query.
...

if any of that is of any use.

 fix your boot issue or do we need to go back to using uncached:

 +   return ioremap(phys, size);

  is that the next change you want me to try?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 09:32:04 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
   fix your boot issue or do we need to go back to using uncached:
  
   +   return ioremap(phys, size);
 
is that the next change you want me to try?

 Yes. (Replacing the current return ioremap_*(phys, size).)

  sadly, no change -- still black screen.  again, rebooted
successfully under commit 8a327f23.  just to be clear, here's git
diff:

$ git diff
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..e035f3c 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   return ioremap_cache(phys, size);
+   return ioremap(phys, size);
 }

 int acpi_os_map_generic_address(struct acpi_generic_address *addr);




rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 09:51:01 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
sadly, no change -- still black screen.  again, rebooted
  successfully under commit 8a327f23.  just to be clear, here's git
  diff:
 
  $ git diff
  diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
  index 7180013..e035f3c 100644
  --- a/include/linux/acpi_io.h
  +++ b/include/linux/acpi_io.h
  @@ -7,7 +7,7 @@
   static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
  acpi_size size)
   {
  -   return ioremap_cache(phys, size);
  +   return ioremap(phys, size);
   }

 Ok, that implies the new mapping is fine and not the cause of the issue.

 Instead you have some OpRegion related regression hidden until till now
 because the conflicting mapping disabled it for i915.

 That would be easy to test by returning early in intel_opregion_setup():

 diff --git a/drivers/gpu/drm/i915/intel_opregion.c
 b/drivers/gpu/drm/i915/intel_
 index 9efccb9..8c93201 100644
 --- a/drivers/gpu/drm/i915/intel_opregion.c
 +++ b/drivers/gpu/drm/i915/intel_opregion.c
 @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
 u32 asls, mboxes;
 int err = 0;

 +   return -ENOTSUPP;
 +

 pci_read_config_dword(dev-pdev, PCI_ASLS, asls);
 DRM_DEBUG_DRIVER(graphic opregion physical addr: 0x%x\n, asls);
 if (asls == 0) {


so you want me to revert to a stock b705120e before doing the above?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 10:08:07 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
   That would be easy to test by returning early in intel_opregion_setup():
  
   diff --git a/drivers/gpu/drm/i915/intel_opregion.c
   b/drivers/gpu/drm/i915/intel_
   index 9efccb9..8c93201 100644
   --- a/drivers/gpu/drm/i915/intel_opregion.c
   +++ b/drivers/gpu/drm/i915/intel_opregion.c
   @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
   u32 asls, mboxes;
   int err = 0;
  
   +   return -ENOTSUPP;
   +
  
   pci_read_config_dword(dev-pdev, PCI_ASLS, asls);
   DRM_DEBUG_DRIVER(graphic opregion physical addr: 0x%x\n, asls);
   if (asls == 0) {
  
 
  so you want me to revert to a stock b705120e before doing the above?

 Yes. (Or latter, at this point we have lots of fun ahead.)

  victory is mine!  ok, that premature return seems to have solved it,
i'm up and running under this new kernel.  are we getting close?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 10:27:09 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
victory is mine!  ok, that premature return seems to have solved it,
  i'm up and running under this new kernel.  are we getting close?

 Not even close. We just disabled functionality that was working in 2.6.37;
 the interaction between ACPI and gfx. What a shame.

 Instead of return -ENOTSUPP at the start,
 you can return 0 before each of the if (mboxes  MBOX_*) to narrow down
 which function regressed.

  ok, i'll see how much of that i can get to today.  but at this
point, are we fairly convinced that there *is* a problem?  i'd hate to
go through all this, only to learn at the end that it's something
stupid i did.  it seems odd that no one else has mentioned running
into this -- have you heard no other reports?

  so, before i launch into this, is there anything else i might report
about my system and its current setup that someone might want to know?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 We're starting to get into ACPI backlight breakage territory... We
 have identified that the regression was much earlier, just masked by
 other breakage.

  as additional info, i went through this for a while during the
2.6.37-rc* progression.  it came, it went, it came back again.  then
everything was fine with both 2.6.38-rc1 and 2.6.38-rc2, and then
this.  this is on a gateway NV79 laptop running a fully-updated ubuntu
10.10.

 Let's clarify the symptoms: black panel, no backlight, no output at
 all (not even at shallow angles), but the machine is alive?

  exactly, same as it's always been when things fail.  that the
machine is still booting is obvious from lots of disk activity,
culminating in the little ubuntu drum roll at the login screen.  and,
as i mentioned before, i do get a couple early kernel messages
(/dev/pts, ureadahead), and that's where it goes black.  for a *good*
boot, what i would see at that point is the font size getting much
smaller and the boot continuing.

 Can you remotely access the machine and grab debug logs from when it
 is broken?

  i'd love to, but can't at the moment.  i'll see if i can scare up a
second machine later and try it.  if i can, what *precisely* would you
like me to post?  i'm guessing dmesg, Xorg.0.log, that sort of thing.

so, before i launch into this, is there anything else i might
  report about my system and its current setup that someone might
  want to know?

 We're now just looking for telltale signs of an error.

  all right.  and since we're beyond git bisection, can you post a
list of say 2 or 3 tests you want me to try in order?  as you're the
expert here, it would make more sense for you to try to optimize the
search pattern here.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Chris Wilson wrote:

 On Fri, 28 Jan 2011 11:23:08 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
all right.  and since we're beyond git bisection, can you post a
  list of say 2 or 3 tests you want me to try in order?  as you're the
  expert here, it would make more sense for you to try to optimize the
  search pattern here.

 If the machine is booting (just with a blank screen), then enable
 drm.debug=0xe, and check that it is being written to the system log
 files. Then boot into the broken setup, reboot and grab the debug
 messages saved from the previous (broken) boot.

 Otherwise we shall just wait for the opportunity to log in with a second
 machine and look for telltales before beginning exploratory surgery.

  ok, this is what works:

==

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.
index 64fd644..645581f 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,10 +495,15 @@ int intel_opregion_setup(struct drm_device *dev)
opregion-acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes  MBOX_SWSCI) {
DRM_DEBUG_DRIVER(SWSCI supported\n);
opregion-swsci = base + OPREGION_SWSCI_OFFSET;
}
+
+return 0; // rday
+
if (mboxes  MBOX_ASLE) {
DRM_DEBUG_DRIVER(ASLE supported\n);
opregion-asle = base + OPREGION_ASLE_OFFSET;

==

  *first*, i added the *later* return 0, and still got the black
screen.  i then added the one *above* that, and got a good boot, so
one therefore concludes that it's the SWSCI processing that's
causing the problem.  of course, that says nothing about whether or
not the later ASLE check could be re-enabled, or does that even make
any sense?

  in any event, what's above works.  next?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:

 On Friday, January 28, 2011, Robert P. J. Day wrote:
  On Fri, 28 Jan 2011, Chris Wilson wrote:
 
   On Fri, 28 Jan 2011 09:51:01 -0500 (EST), Robert P. J. Day 
   rpj...@crashcourse.ca wrote:
  sadly, no change -- still black screen.  again, rebooted
successfully under commit 8a327f23.  just to be clear, here's git
diff:
   
$ git diff
diff --git a/include/linux/acpi_io.h b/include/linux/acpi_io.h
index 7180013..e035f3c 100644
--- a/include/linux/acpi_io.h
+++ b/include/linux/acpi_io.h
@@ -7,7 +7,7 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   return ioremap_cache(phys, size);
+   return ioremap(phys, size);
 }
  
   Ok, that implies the new mapping is fine and not the cause of the issue.
  
   Instead you have some OpRegion related regression hidden until till now
   because the conflicting mapping disabled it for i915.
  
   That would be easy to test by returning early in intel_opregion_setup():
  
   diff --git a/drivers/gpu/drm/i915/intel_opregion.c
   b/drivers/gpu/drm/i915/intel_
   index 9efccb9..8c93201 100644
   --- a/drivers/gpu/drm/i915/intel_opregion.c
   +++ b/drivers/gpu/drm/i915/intel_opregion.c
   @@ -470,6 +470,8 @@ int intel_opregion_setup(struct drm_device *dev)
   u32 asls, mboxes;
   int err = 0;
  
   +   return -ENOTSUPP;
   +
  
   pci_read_config_dword(dev-pdev, PCI_ASLS, asls);
   DRM_DEBUG_DRIVER(graphic opregion physical addr: 0x%x\n, asls);
   if (asls == 0) {
  
 
  so you want me to revert to a stock b705120e before doing the above?

 Alternatively, you could take the vanilla Linus' tree and replace
 ioremap_cache() with ioremap() in include/linux/acpi_io.h .  Please try that
 and see if it makes a difference.

  been there, done that, that's all so ... this morning.  i continued
bisecting and playing and eventually verified the following
workaround for an earlier working version of the kernel:

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion-acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes  MBOX_SWSCI) {
DRM_DEBUG_DRIVER(SWSCI supported\n);
opregion-swsci = base + OPREGION_SWSCI_OFFSET;


  this was based on a suggestion by chris wilson to deactivate the
mboxes tests in that single source file and see what happened.
adding the return 0 above suddenly gave me a properly booting
kernel.  i applied the same diff to the current kernel and it's
building as we speak.

rday

p.s.  having that return 0 *after* that test but before the next one
still gave me a black screen.

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned? [BISECTED]

[Robert P. J. Day]

On Fri, 28 Jan 2011, Rafael J. Wysocki wrote:

 Alternatively, you could take the vanilla Linus' tree and replace
 ioremap_cache() with ioremap() in include/linux/acpi_io.h .  Please
 try that and see if it makes a difference.

  as a quick followup, i applied the following simple patch:

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64fd644..28adc6d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -495,6 +495,8 @@ int intel_opregion_setup(struct drm_device *dev)
opregion-acpi = base + OPREGION_ACPI_OFFSET;
}

+return 0; // rday
+
if (mboxes  MBOX_SWSCI) {
DRM_DEBUG_DRIVER(SWSCI supported\n);
opregion-swsci = base + OPREGION_SWSCI_OFFSET;


to the latest tree, and it gave me a booting kernel, no black screen
issue.  i will not pretend to understand why that fixes the problem
but it does.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

  one more observation which should nail things down:

On Thu, 27 Jan 2011, Robert P. J. Day wrote:

>   ok, i'm getting different results from this morning, not sure why,
> but i'm fairly confident i've isolated it to this extent.  here's the
> salient part of the git log i'm looking at:
>
> = git log =
>
> commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
> Merge: 58bbf01 8e934db
> Author: Dave Airlie 
> Date:   Tue Jan 25 08:41:58 2011 +1000
>
> Merge branch 'drm-intel-fixes-2' of 
> ssh://master.kernel.org/pub/scm/linux/kernel/g
>
> * 'drm-intel-fixes-2' of 
> ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr
>   drm/i915: Prevent uninitialised reads during error state capture
>   drm/i915: Use consistent mappings for OpRegion between ACPI and i915
>   drm/i915: Handle the no-interrupts case for UMS by polling
>   drm/i915: Disable high-precision vblank timestamping for UMS
>   drm/i915: Increase the amount of defense before computing vblank 
> timestamps
>   drm/i915,agp/intel: Do not clear stolen entries
>   Remove MAYBE_BUILD_BUG_ON
>   BUILD_BUG_ON: make it handle more cases
>   module: fix missing semicolons in MODULE macro usage
>   param: add null statement to compiled-in module params
>   module: fix linker error for MODULE_VERSION when !MODULE and 
> CONFIG_SYSFS=n
>   module: show version information for built-in modules in sysfs
>   selinux: return -ENOMEM when memory allocation fails
>   tpm: fix panic caused by "tpm: Autodetect itpm devices"
>   TPM: Long default timeout fix
>   trusted keys: Fix a memory leak in trusted_update().
>   keys: add trusted and encrypted maintainers
>   encrypted-keys: rename encrypted_defined files to encrypted
>   trusted-keys: rename trusted_defined files to trusted
>   drm/i915: Recognise non-VGA display devices
>   ...
>
> commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
> Author: Alex Deucher 
> Date:   Mon Jan 24 17:14:26 2011 -0500
>
> drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
>
> Needed for timer queries in the 3D driver.
>
> Signed-off-by: Alex Deucher 
> Signed-off-by: Dave Airlie 
>
> = git log =
>
> now:
>
>   * commit 58bbf018 appears to be fine, boots reliably
>   * commit 8e934dbf causes black screen issue
>
> as you can see, rather than test the *merge* above, i decided to back
> up one level and test the commit that was part of that merge, and it
> failed.  is this helpful?  here's the log entry:
>
> commit 8e934dbf264418afe4d1dff34ce074ecc14280db
> Author: Chris Wilson 
> Date:   Mon Jan 24 12:34:00 2011 +
>
> drm/i915: Prevent uninitialised reads during error state capture
>
> error_bo and pinned_bo could be used uninitialised if there were no
> active buffers.
>
> Caught by kmemcheck.
>
> Signed-off-by: Chris Wilson 
>
>
>   i'm going to go on and test the merge itself, abb72c82, since i
> thought that was working fine earlier today.  but you can see which
> commit now seems to fail.  does this make any sense?

  i did indeed test commit abb72c82 (the merge of the above), and it
failed.  not sure why i posted earlier today that it worked, i must
have built something incorrectly.  so, in conclusion:

  * commit 58bbf018 appears to be fine, boots reliably
  * commit 8e934dbf causes black screen issue
  * commit abb72c82 also causes black screen issue

and on that note, signing off for the evening.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Thu, 27 Jan 2011, Chris Wilson wrote:
> >
> > > On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day"  > > crashcourse.ca> wrote:
> > > >
> > > >   for me, this appears to be the offending commit:
> > > >
> > > > commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
> > > > Merge: ec30f34 abb72c8
> > > > Author: Linus Torvalds 
> > > > Date:   Tue Jan 25 10:46:14 2011 +1000
> > > >
> > > > Merge branch 'drm-fixes' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/ai
> > >
> > > Let's just test the other parent ec30f343d to be sure it came in with the
> > > drm merge.
> >
> >   so that's something you want me to test?  checking out that commit
> > ec30f343d and trying it?
>
> Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault
> (since the merge looks clean), verifying that the bug was introduced
> between abb72c828 and ec30f34.

  ok, i'm getting different results from this morning, not sure why,
but i'm fairly confident i've isolated it to this extent.  here's the
salient part of the git log i'm looking at:

= git log =

commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
Merge: 58bbf01 8e934db
Author: Dave Airlie 
Date:   Tue Jan 25 08:41:58 2011 +1000

Merge branch 'drm-intel-fixes-2' of 
ssh://master.kernel.org/pub/scm/linux/kernel/g

* 'drm-intel-fixes-2' of 
ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr
  drm/i915: Prevent uninitialised reads during error state capture
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
  drm/i915: Handle the no-interrupts case for UMS by polling
  drm/i915: Disable high-precision vblank timestamping for UMS
  drm/i915: Increase the amount of defense before computing vblank 
timestamps
  drm/i915,agp/intel: Do not clear stolen entries
  Remove MAYBE_BUILD_BUG_ON
  BUILD_BUG_ON: make it handle more cases
  module: fix missing semicolons in MODULE macro usage
  param: add null statement to compiled-in module params
  module: fix linker error for MODULE_VERSION when !MODULE and 
CONFIG_SYSFS=n
  module: show version information for built-in modules in sysfs
  selinux: return -ENOMEM when memory allocation fails
  tpm: fix panic caused by "tpm: Autodetect itpm devices"
  TPM: Long default timeout fix
  trusted keys: Fix a memory leak in trusted_update().
  keys: add trusted and encrypted maintainers
  encrypted-keys: rename encrypted_defined files to encrypted
  trusted-keys: rename trusted_defined files to trusted
  drm/i915: Recognise non-VGA display devices
  ...

commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
Author: Alex Deucher 
Date:   Mon Jan 24 17:14:26 2011 -0500

drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq

Needed for timer queries in the 3D driver.

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 

= git log =

now:

  * commit 58bbf018 appears to be fine, boots reliably
  * commit 8e934dbf causes black screen issue

as you can see, rather than test the *merge* above, i decided to back
up one level and test the commit that was part of that merge, and it
failed.  is this helpful?  here's the log entry:

commit 8e934dbf264418afe4d1dff34ce074ecc14280db
Author: Chris Wilson 
Date:   Mon Jan 24 12:34:00 2011 +

drm/i915: Prevent uninitialised reads during error state capture

error_bo and pinned_bo could be used uninitialised if there were no
active buffers.

Caught by kmemcheck.

Signed-off-by: Chris Wilson 


  i'm going to go on and test the merge itself, abb72c82, since i
thought that was working fine earlier today.  but you can see which
commit now seems to fail.  does this make any sense?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Thu, 27 Jan 2011, Chris Wilson wrote:
> >
> > > On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day"  > > crashcourse.ca> wrote:
> > > >
> > > >   for me, this appears to be the offending commit:
> > > >
> > > > commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
> > > > Merge: ec30f34 abb72c8
> > > > Author: Linus Torvalds 
> > > > Date:   Tue Jan 25 10:46:14 2011 +1000
> > > >
> > > > Merge branch 'drm-fixes' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/ai
> > >
> > > Let's just test the other parent ec30f343d to be sure it came in with the
> > > drm merge.
> >
> >   so that's something you want me to test?  checking out that commit
> > ec30f343d and trying it?
>
> Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault
> (since the merge looks clean), verifying that the bug was introduced
> between abb72c828 and ec30f34.

  well, now i'm confused since it *appears* that, when i went to
double-check the results, the earlier commit abb72c8 *doesn't* work,
and i could swear that it did.  so i'll just redo *all* of the
relevant commits and report back.  grr ...

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 08:55:24 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Thu, 27 Jan 2011, Chris Wilson wrote:
> >
> > > On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day"  > > crashcourse.ca> wrote:
> > > >
> > > >   for me, this appears to be the offending commit:
> > > >
> > > > commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
> > > > Merge: ec30f34 abb72c8
> > > > Author: Linus Torvalds 
> > > > Date:   Tue Jan 25 10:46:14 2011 +1000
> > > >
> > > > Merge branch 'drm-fixes' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/ai
> > >
> > > Let's just test the other parent ec30f343d to be sure it came in with the
> > > drm merge.
> >
> >   so that's something you want me to test?  checking out that commit
> > ec30f343d and trying it?
>
> Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault
> (since the merge looks clean), verifying that the bug was introduced
> between abb72c828 and ec30f34.

  ok, i'll try to get to that ASAP.  so what i'm *expecting* is for
ec30f34 to fail, then.  i'll keep you posted.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 08:42:19 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >
> >   for me, this appears to be the offending commit:
> >
> > commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
> > Merge: ec30f34 abb72c8
> > Author: Linus Torvalds 
> > Date:   Tue Jan 25 10:46:14 2011 +1000
> >
> > Merge branch 'drm-fixes' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/ai
>
> Let's just test the other parent ec30f343d to be sure it came in with the
> drm merge.

  so that's something you want me to test?  checking out that commit
ec30f343d and trying it?

rday

-- 

====
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Thu, 27 Jan 2011, Chris Wilson wrote:
> >
> > > The only missing detail is what connector is used for the display.
> > > Xorg.log or xrandr --verbose are the easiest.
> >
> >   i can supply those for the currently *successful* boot, is that
> > what you're asking?  because once we're into black screen territory,
> > there's not a whole lot i can tell you.
>
> Indeed. Fortunately the integrated hardware is unlikely to change between
> boots. But more interesting is if you can pin down the regressing commit.

  for me, this appears to be the offending commit:

commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
Merge: ec30f34 abb72c8
Author: Linus Torvalds 
Date:   Tue Jan 25 10:46:14 2011 +1000

Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ai

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2
  drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
  drm/i915: Prevent uninitialised reads during error state capture
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
  drm/i915: Handle the no-interrupts case for UMS by polling
  drm/i915: Disable high-precision vblank timestamping for UMS
  drm/i915: Increase the amount of defense before computing vblank timestamp
  drm/i915,agp/intel: Do not clear stolen entries
  drm/radeon/kms: simplify atom adjust pll setup
  drm/radeon/kms: match r6xx/r7xx/evergreen asic_reset with previous asics
  drm/radeon/kms: make the mac rv630 quirk generic
  drm/radeon/kms: fix a spelling error in an error message
  drm/radeon/kms: Initialize pageflip spinlocks.
  drm/i915: Recognise non-VGA display devices
  drm/i915: Fix use of invalid array size for ring->sync_seqno
  drm/i915/ringbuffer: Fix use of stale HEAD position whilst polling for spa
  drm/i915: Don't kick-off hangcheck after a DRI interrupt
  drm/i915: Add dependency on CONFIG_TMPFS
  drm/i915: Initialise ring vfuncs for old DRI paths
  drm/i915: make the blitter report buffer modifications to the FBC unit
  drm/i915: set more FBC chicken bits


  anything you want me to try?

rday

-- 

========
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Thu, 27 Jan 2011, Chris Wilson wrote:
> >
> > > The only missing detail is what connector is used for the display.
> > > Xorg.log or xrandr --verbose are the easiest.
> >
> >   i can supply those for the currently *successful* boot, is that
> > what you're asking?  because once we're into black screen territory,
> > there's not a whole lot i can tell you.
>
> Indeed. Fortunately the integrated hardware is unlikely to change between
> boots. But more interesting is if you can pin down the regressing commit.

  this commit seems to be fine:

commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
Merge: 58bbf01 8e934db
Author: Dave Airlie 
Date:   Tue Jan 25 08:41:58 2011 +1000

Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/ke

* 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ic
  drm/i915: Prevent uninitialised reads during error state capture
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
  drm/i915: Handle the no-interrupts case for UMS by polling
  drm/i915: Disable high-precision vblank timestamping for UMS
  drm/i915: Increase the amount of defense before computing vblank timestamp
  drm/i915,agp/intel: Do not clear stolen entries
  Remove MAYBE_BUILD_BUG_ON
  BUILD_BUG_ON: make it handle more cases
  module: fix missing semicolons in MODULE macro usage
  param: add null statement to compiled-in module params
  module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=
  module: show version information for built-in modules in sysfs
  selinux: return -ENOMEM when memory allocation fails
  tpm: fix panic caused by "tpm: Autodetect itpm devices"
  TPM: Long default timeout fix
  trusted keys: Fix a memory leak in trusted_update().
  keys: add trusted and encrypted maintainers
  encrypted-keys: rename encrypted_defined files to encrypted
  trusted-keys: rename trusted_defined files to trusted
  drm/i915: Recognise non-VGA display devices
  ...


so moving on to the very next one, which logic suggests would be the
culprit.  back shortly if time permits.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 07:12:03 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> > On Thu, 27 Jan 2011, Chris Wilson wrote:
> >
> > > The only missing detail is what connector is used for the display.
> > > Xorg.log or xrandr --verbose are the easiest.
> >
> >   i can supply those for the currently *successful* boot, is that
> > what you're asking?  because once we're into black screen territory,
> > there's not a whole lot i can tell you.
>
> Indeed. Fortunately the integrated hardware is unlikely to change between
> boots.

  that was sarcasm, wasn't it? :-)

> But more interesting is if you can pin down the regressing commit.

  working on that now.  here's Xorg.0.log for the current system:

[40.877]
X.Org X Server 1.9.0
Release Date: 2010-08-20
[40.877] X Protocol Version 11, Revision 0
[40.877] Build Operating System: Linux 2.6.24-28-server x86_64 Ubuntu
[40.877] Current Operating System: Linux lynx 2.6.38-rc2+ #15 SMP Thu Jan 
27 06:24:55 EST 2011 x86_64
[40.877] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.38-rc2+ 
root=/dev/mapper/lynx-root ro quiet splash
[40.877] Build Date: 09 January 2011  12:14:27PM
[40.877] xorg-server 2:1.9.0-0ubuntu7.3 (For technical support please see 
http://www.ubuntu.com/support)
[40.877] Current version of pixman: 0.18.4
[40.877]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[40.877] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[40.877] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 27 06:39:06 
2011
[40.955] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[41.012] (==) No Layout section.  Using the first Screen section.
[41.013] (==) No screen section available. Using defaults.
[41.013] (**) |-->Screen "Default Screen Section" (0)
[41.013] (**) |   |-->Monitor ""
[41.013] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[41.013] (==) Automatically adding devices
[41.013] (==) Automatically enabling devices
[41.039] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[41.039]Entry deleted from font path.
[41.086] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[41.086] (==) ModulePath set to 
"/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[41.086] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[41.086] (II) Loader magic: 0x7d17a0
[41.086] (II) Module ABI versions:
[41.086]X.Org ANSI C Emulation: 0.4
[41.086]X.Org Video Driver: 8.0
[41.086]X.Org XInput driver : 11.0
[41.086]X.Org Server Extension : 4.0
[41.087] (--) PCI:*(0:0:2:0) 8086:0046:1025:031c rev 18, Mem @ 
0xd000/4194304, 0xc000/268435456, I/O @ 0x3050/8
[41.087] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or 
directory)
[41.087] (II) LoadModule: "extmod"
[41.160] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[41.167] (II) Module extmod: vendor="X.Org Foundation"
[41.167]compiled for 1.9.0, module version = 1.0.0
[41.167]Module class: X.Org Server Extension
[41.167]ABI class: X.Org Server Extension, version 4.0
[41.167] (II) Loading extension MIT-SCREEN-SAVER
[41.167] (II) Loading extension XFree86-VidModeExtension
[41.167] (II) Loading extension XFree86-DGA
[41.167] (II) Loading extension DPMS
[41.167] (II) Loading extension XVideo
[41.167] (II) Loading extension XVideo-MotionCompensation
[41.167] (II) Loading extension X-Resource
[41.167] (II) LoadModule: "dbe"
[41.168] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[41.173] (II) Module dbe: vendor="X.Org Foundation"
[41.173]compiled for 1.9.0, module version = 1.0.0
[41.174]Module class: X.Org Server Extension
[41.174]ABI class: X.Org Server Extension, version 4.0
[41.174] (II) Loading extension DOUBLE-BUFFER
[41.174] (II) LoadModule: "glx"
[41.174] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[41.190] (II) Module glx: vendor="X.Org Foundation"
[41.190]compiled f

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Thu, 27 Jan 2011 06:47:23 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >   also, i just verified that i have a properly booting kernel based on
> > this commit:
> >
> > commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
> > Author: Alex Deucher 
> > Date:   Mon Jan 24 17:14:26 2011 -0500
> >
> > drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
> >
> > Needed for timer queries in the 3D driver.
> >
> > Signed-off-by: Alex Deucher 
> > Signed-off-by: Dave Airlie 
> >
> >
> > i chose that commit since, right after that, there are a couple
> > commits that are heavily i915-related:
> >
> > abb72c828878a2c69b2cfb33ac30007c8ecd735e
> > 5e82ea99827f6aa122fbb08f8659e76226ce107b
> >
> > and those would be the next things i check.  is there any other info
> > you'd like to see?
>
> The only missing detail is what connector is used for the display.
> Xorg.log or xrandr --verbose are the easiest.

  i can supply those for the currently *successful* boot, is that
what you're asking?  because once we're into black screen territory,
there's not a whole lot i can tell you.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Wed, 26 Jan 2011 06:37:20 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >
> >   after suffering through the i915 "black screen" issue for a while,
> > it was a relief that it finally seemed to be resolved with 2.6.37 or
> > something in tha vicinity.  but i just built and booted a 2.6.38-rc2+
> > kernel on my ubuntu 10.10 system and it once again boots to a black
> > screen.
> >
> >   is this a new known issue?  has anyone else seen this?
>
> It all depends. There is a new ACPI backlight issue causing grief, aside
> from that and lingering issues with the legacy backlight combination mode,
> I don't think there was a new i915 KMS regression. (We had regressions
> elsewhere and finally fixed up a few old regressions for UMS and DRI1 and
> various other OOPS-on-boot. And suspend is a bit hit and miss.)
>
> For extra fun, it appears that sched_autocgroup can trigger a leak of
> pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.
>
> Without knowing your chipset and seeing a dmesg, I can only guess which
> problem you are most likely to have hit.

  here's a little more info if it's helpful.  from "lspci -v":

00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 031c
Flags: bus master, fast devsel, latency 0, IRQ 41
Memory at d000 (64-bit, non-prefetchable) [size=4M]
Memory at c000 (64-bit, prefetchable) [size=256M]
I/O ports at 3050 [size=8]
Expansion ROM at  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915


  also, i just verified that i have a properly booting kernel based on
this commit:

commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
Author: Alex Deucher 
Date:   Mon Jan 24 17:14:26 2011 -0500

drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq

Needed for timer queries in the 3D driver.

Signed-off-by: Alex Deucher 
Signed-off-by: Dave Airlie 


i chose that commit since, right after that, there are a couple
commits that are heavily i915-related:

abb72c828878a2c69b2cfb33ac30007c8ecd735e
5e82ea99827f6aa122fbb08f8659e76226ce107b

and those would be the next things i check.  is there any other info
you'd like to see?

rday

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

> On Wed, 26 Jan 2011 06:37:20 -0500 (EST), "Robert P. J. Day"  crashcourse.ca> wrote:
> >
> >   after suffering through the i915 "black screen" issue for a while,
> > it was a relief that it finally seemed to be resolved with 2.6.37 or
> > something in tha vicinity.  but i just built and booted a 2.6.38-rc2+
> > kernel on my ubuntu 10.10 system and it once again boots to a black
> > screen.
> >
> >   is this a new known issue?  has anyone else seen this?
>
> It all depends. There is a new ACPI backlight issue causing grief,
> aside from that and lingering issues with the legacy backlight
> combination mode, I don't think there was a new i915 KMS regression.
> (We had regressions elsewhere and finally fixed up a few old
> regressions for UMS and DRI1 and various other OOPS-on-boot. And
> suspend is a bit hit and miss.)
>
> For extra fun, it appears that sched_autocgroup can trigger a leak of
> pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.
>
> Without knowing your chipset and seeing a dmesg, I can only guess which
> problem you are most likely to have hit.

  if i have time today, i'll try to bisect.  i've built a 2.6.38-rc2
kernel and that seems to work fine.  more in a bit while i track this
down.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Wed, 26 Jan 2011 06:37:20 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
 
after suffering through the i915 black screen issue for a while,
  it was a relief that it finally seemed to be resolved with 2.6.37 or
  something in tha vicinity.  but i just built and booted a 2.6.38-rc2+
  kernel on my ubuntu 10.10 system and it once again boots to a black
  screen.
 
is this a new known issue?  has anyone else seen this?

 It all depends. There is a new ACPI backlight issue causing grief,
 aside from that and lingering issues with the legacy backlight
 combination mode, I don't think there was a new i915 KMS regression.
 (We had regressions elsewhere and finally fixed up a few old
 regressions for UMS and DRI1 and various other OOPS-on-boot. And
 suspend is a bit hit and miss.)

 For extra fun, it appears that sched_autocgroup can trigger a leak of
 pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.

 Without knowing your chipset and seeing a dmesg, I can only guess which
 problem you are most likely to have hit.

  if i have time today, i'll try to bisect.  i've built a 2.6.38-rc2
kernel and that seems to work fine.  more in a bit while i track this
down.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Wed, 26 Jan 2011 06:37:20 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
 
after suffering through the i915 black screen issue for a while,
  it was a relief that it finally seemed to be resolved with 2.6.37 or
  something in tha vicinity.  but i just built and booted a 2.6.38-rc2+
  kernel on my ubuntu 10.10 system and it once again boots to a black
  screen.
 
is this a new known issue?  has anyone else seen this?

 It all depends. There is a new ACPI backlight issue causing grief, aside
 from that and lingering issues with the legacy backlight combination mode,
 I don't think there was a new i915 KMS regression. (We had regressions
 elsewhere and finally fixed up a few old regressions for UMS and DRI1 and
 various other OOPS-on-boot. And suspend is a bit hit and miss.)

 For extra fun, it appears that sched_autocgroup can trigger a leak of
 pinned bo eventually hitting a BUG. That's one I'm keen to reproduce.

 Without knowing your chipset and seeing a dmesg, I can only guess which
 problem you are most likely to have hit.

  here's a little more info if it's helpful.  from lspci -v:

00:02.0 VGA compatible controller: Intel Corporation Core Processor
Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 031c
Flags: bus master, fast devsel, latency 0, IRQ 41
Memory at d000 (64-bit, non-prefetchable) [size=4M]
Memory at c000 (64-bit, prefetchable) [size=256M]
I/O ports at 3050 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915
Kernel modules: i915


  also, i just verified that i have a properly booting kernel based on
this commit:

commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
Author: Alex Deucher alexdeuc...@gmail.com
Date:   Mon Jan 24 17:14:26 2011 -0500

drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq

Needed for timer queries in the 3D driver.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@gmail.com


i chose that commit since, right after that, there are a couple
commits that are heavily i915-related:

abb72c828878a2c69b2cfb33ac30007c8ecd735e
5e82ea99827f6aa122fbb08f8659e76226ce107b

and those would be the next things i check.  is there any other info
you'd like to see?

rday
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 06:47:23 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
also, i just verified that i have a properly booting kernel based on
  this commit:
 
  commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
  Author: Alex Deucher alexdeuc...@gmail.com
  Date:   Mon Jan 24 17:14:26 2011 -0500
 
  drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
 
  Needed for timer queries in the 3D driver.
 
  Signed-off-by: Alex Deucher alexdeuc...@gmail.com
  Signed-off-by: Dave Airlie airl...@gmail.com
 
 
  i chose that commit since, right after that, there are a couple
  commits that are heavily i915-related:
 
  abb72c828878a2c69b2cfb33ac30007c8ecd735e
  5e82ea99827f6aa122fbb08f8659e76226ce107b
 
  and those would be the next things i check.  is there any other info
  you'd like to see?

 The only missing detail is what connector is used for the display.
 Xorg.log or xrandr --verbose are the easiest.

  i can supply those for the currently *successful* boot, is that
what you're asking?  because once we're into black screen territory,
there's not a whole lot i can tell you.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 07:12:03 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  On Thu, 27 Jan 2011, Chris Wilson wrote:
 
   The only missing detail is what connector is used for the display.
   Xorg.log or xrandr --verbose are the easiest.
 
i can supply those for the currently *successful* boot, is that
  what you're asking?  because once we're into black screen territory,
  there's not a whole lot i can tell you.

 Indeed. Fortunately the integrated hardware is unlikely to change between
 boots.

  that was sarcasm, wasn't it? :-)

 But more interesting is if you can pin down the regressing commit.

  working on that now.  here's Xorg.0.log for the current system:

[40.877]
X.Org X Server 1.9.0
Release Date: 2010-08-20
[40.877] X Protocol Version 11, Revision 0
[40.877] Build Operating System: Linux 2.6.24-28-server x86_64 Ubuntu
[40.877] Current Operating System: Linux lynx 2.6.38-rc2+ #15 SMP Thu Jan 
27 06:24:55 EST 2011 x86_64
[40.877] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.38-rc2+ 
root=/dev/mapper/lynx-root ro quiet splash
[40.877] Build Date: 09 January 2011  12:14:27PM
[40.877] xorg-server 2:1.9.0-0ubuntu7.3 (For technical support please see 
http://www.ubuntu.com/support)
[40.877] Current version of pixman: 0.18.4
[40.877]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[40.877] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[40.877] (==) Log file: /var/log/Xorg.0.log, Time: Thu Jan 27 06:39:06 
2011
[40.955] (==) Using system config directory /usr/share/X11/xorg.conf.d
[41.012] (==) No Layout section.  Using the first Screen section.
[41.013] (==) No screen section available. Using defaults.
[41.013] (**) |--Screen Default Screen Section (0)
[41.013] (**) |   |--Monitor default monitor
[41.013] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[41.013] (==) Automatically adding devices
[41.013] (==) Automatically enabling devices
[41.039] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[41.039]Entry deleted from font path.
[41.086] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[41.086] (==) ModulePath set to 
/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules
[41.086] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[41.086] (II) Loader magic: 0x7d17a0
[41.086] (II) Module ABI versions:
[41.086]X.Org ANSI C Emulation: 0.4
[41.086]X.Org Video Driver: 8.0
[41.086]X.Org XInput driver : 11.0
[41.086]X.Org Server Extension : 4.0
[41.087] (--) PCI:*(0:0:2:0) 8086:0046:1025:031c rev 18, Mem @ 
0xd000/4194304, 0xc000/268435456, I/O @ 0x3050/8
[41.087] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or 
directory)
[41.087] (II) LoadModule: extmod
[41.160] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[41.167] (II) Module extmod: vendor=X.Org Foundation
[41.167]compiled for 1.9.0, module version = 1.0.0
[41.167]Module class: X.Org Server Extension
[41.167]ABI class: X.Org Server Extension, version 4.0
[41.167] (II) Loading extension MIT-SCREEN-SAVER
[41.167] (II) Loading extension XFree86-VidModeExtension
[41.167] (II) Loading extension XFree86-DGA
[41.167] (II) Loading extension DPMS
[41.167] (II) Loading extension XVideo
[41.167] (II) Loading extension XVideo-MotionCompensation
[41.167] (II) Loading extension X-Resource
[41.167] (II) LoadModule: dbe
[41.168] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[41.173] (II) Module dbe: vendor=X.Org Foundation
[41.173]compiled for 1.9.0, module version = 1.0.0
[41.174]Module class: X.Org Server Extension
[41.174]ABI class: X.Org Server Extension, version 4.0
[41.174] (II) Loading extension DOUBLE-BUFFER
[41.174] (II) LoadModule: glx
[41.174] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[41.190] (II) Module glx: vendor=X.Org Foundation
[41.190]compiled for 1.9.0, module version = 1.0.0
[41.190]ABI class: X.Org Server Extension, version 4.0
[41.190] (==) AIGLX enabled
[41.190] (II) Loading extension GLX
[41.191] (II) LoadModule: record
[41.191] (II) Loading /usr/lib/xorg

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 07:12:03 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  On Thu, 27 Jan 2011, Chris Wilson wrote:
 
   The only missing detail is what connector is used for the display.
   Xorg.log or xrandr --verbose are the easiest.
 
i can supply those for the currently *successful* boot, is that
  what you're asking?  because once we're into black screen territory,
  there's not a whole lot i can tell you.

 Indeed. Fortunately the integrated hardware is unlikely to change between
 boots. But more interesting is if you can pin down the regressing commit.

  this commit seems to be fine:

commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
Merge: 58bbf01 8e934db
Author: Dave Airlie airl...@gmail.com
Date:   Tue Jan 25 08:41:58 2011 +1000

Merge branch 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/ke

* 'drm-intel-fixes-2' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ic
  drm/i915: Prevent uninitialised reads during error state capture
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
  drm/i915: Handle the no-interrupts case for UMS by polling
  drm/i915: Disable high-precision vblank timestamping for UMS
  drm/i915: Increase the amount of defense before computing vblank timestamp
  drm/i915,agp/intel: Do not clear stolen entries
  Remove MAYBE_BUILD_BUG_ON
  BUILD_BUG_ON: make it handle more cases
  module: fix missing semicolons in MODULE macro usage
  param: add null statement to compiled-in module params
  module: fix linker error for MODULE_VERSION when !MODULE and CONFIG_SYSFS=
  module: show version information for built-in modules in sysfs
  selinux: return -ENOMEM when memory allocation fails
  tpm: fix panic caused by tpm: Autodetect itpm devices
  TPM: Long default timeout fix
  trusted keys: Fix a memory leak in trusted_update().
  keys: add trusted and encrypted maintainers
  encrypted-keys: rename encrypted_defined files to encrypted
  trusted-keys: rename trusted_defined files to trusted
  drm/i915: Recognise non-VGA display devices
  ...


so moving on to the very next one, which logic suggests would be the
culprit.  back shortly if time permits.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 07:12:03 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  On Thu, 27 Jan 2011, Chris Wilson wrote:
 
   The only missing detail is what connector is used for the display.
   Xorg.log or xrandr --verbose are the easiest.
 
i can supply those for the currently *successful* boot, is that
  what you're asking?  because once we're into black screen territory,
  there's not a whole lot i can tell you.

 Indeed. Fortunately the integrated hardware is unlikely to change between
 boots. But more interesting is if you can pin down the regressing commit.

  for me, this appears to be the offending commit:

commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
Merge: ec30f34 abb72c8
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Tue Jan 25 10:46:14 2011 +1000

Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ai

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2
  drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq
  drm/i915: Prevent uninitialised reads during error state capture
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
  drm/i915: Handle the no-interrupts case for UMS by polling
  drm/i915: Disable high-precision vblank timestamping for UMS
  drm/i915: Increase the amount of defense before computing vblank timestamp
  drm/i915,agp/intel: Do not clear stolen entries
  drm/radeon/kms: simplify atom adjust pll setup
  drm/radeon/kms: match r6xx/r7xx/evergreen asic_reset with previous asics
  drm/radeon/kms: make the mac rv630 quirk generic
  drm/radeon/kms: fix a spelling error in an error message
  drm/radeon/kms: Initialize pageflip spinlocks.
  drm/i915: Recognise non-VGA display devices
  drm/i915: Fix use of invalid array size for ring-sync_seqno
  drm/i915/ringbuffer: Fix use of stale HEAD position whilst polling for spa
  drm/i915: Don't kick-off hangcheck after a DRI interrupt
  drm/i915: Add dependency on CONFIG_TMPFS
  drm/i915: Initialise ring vfuncs for old DRI paths
  drm/i915: make the blitter report buffer modifications to the FBC unit
  drm/i915: set more FBC chicken bits


  anything you want me to try?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 08:42:19 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
 
for me, this appears to be the offending commit:
 
  commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
  Merge: ec30f34 abb72c8
  Author: Linus Torvalds torva...@linux-foundation.org
  Date:   Tue Jan 25 10:46:14 2011 +1000
 
  Merge branch 'drm-fixes' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/ai

 Let's just test the other parent ec30f343d to be sure it came in with the
 drm merge.

  so that's something you want me to test?  checking out that commit
ec30f343d and trying it?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 08:55:24 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  On Thu, 27 Jan 2011, Chris Wilson wrote:
 
   On Thu, 27 Jan 2011 08:42:19 -0500 (EST), Robert P. J. Day 
   rpj...@crashcourse.ca wrote:
   
  for me, this appears to be the offending commit:
   
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
Merge: ec30f34 abb72c8
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Tue Jan 25 10:46:14 2011 +1000
   
Merge branch 'drm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ai
  
   Let's just test the other parent ec30f343d to be sure it came in with the
   drm merge.
 
so that's something you want me to test?  checking out that commit
  ec30f343d and trying it?

 Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault
 (since the merge looks clean), verifying that the bug was introduced
 between abb72c828 and ec30f34.

  ok, i'll try to get to that ASAP.  so what i'm *expecting* is for
ec30f34 to fail, then.  i'll keep you posted.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 08:55:24 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  On Thu, 27 Jan 2011, Chris Wilson wrote:
 
   On Thu, 27 Jan 2011 08:42:19 -0500 (EST), Robert P. J. Day 
   rpj...@crashcourse.ca wrote:
   
  for me, this appears to be the offending commit:
   
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
Merge: ec30f34 abb72c8
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Tue Jan 25 10:46:14 2011 +1000
   
Merge branch 'drm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ai
  
   Let's just test the other parent ec30f343d to be sure it came in with the
   drm merge.
 
so that's something you want me to test?  checking out that commit
  ec30f343d and trying it?

 Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault
 (since the merge looks clean), verifying that the bug was introduced
 between abb72c828 and ec30f34.

  well, now i'm confused since it *appears* that, when i went to
double-check the results, the earlier commit abb72c8 *doesn't* work,
and i could swear that it did.  so i'll just redo *all* of the
relevant commits and report back.  grr ...

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

On Thu, 27 Jan 2011, Chris Wilson wrote:

 On Thu, 27 Jan 2011 08:55:24 -0500 (EST), Robert P. J. Day 
 rpj...@crashcourse.ca wrote:
  On Thu, 27 Jan 2011, Chris Wilson wrote:
 
   On Thu, 27 Jan 2011 08:42:19 -0500 (EST), Robert P. J. Day 
   rpj...@crashcourse.ca wrote:
   
  for me, this appears to be the offending commit:
   
commit 5e82ea99827f6aa122fbb08f8659e76226ce107b (now testing)
Merge: ec30f34 abb72c8
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Tue Jan 25 10:46:14 2011 +1000
   
Merge branch 'drm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ai
  
   Let's just test the other parent ec30f343d to be sure it came in with the
   drm merge.
 
so that's something you want me to test?  checking out that commit
  ec30f343d and trying it?

 Yes. If abb72c8 works and 5e82ea9 does not, then ec30f34 must be at fault
 (since the merge looks clean), verifying that the bug was introduced
 between abb72c828 and ec30f34.

  ok, i'm getting different results from this morning, not sure why,
but i'm fairly confident i've isolated it to this extent.  here's the
salient part of the git log i'm looking at:

= git log =

commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
Merge: 58bbf01 8e934db
Author: Dave Airlie airl...@gmail.com
Date:   Tue Jan 25 08:41:58 2011 +1000

Merge branch 'drm-intel-fixes-2' of 
ssh://master.kernel.org/pub/scm/linux/kernel/g

* 'drm-intel-fixes-2' of 
ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr
  drm/i915: Prevent uninitialised reads during error state capture
  drm/i915: Use consistent mappings for OpRegion between ACPI and i915
  drm/i915: Handle the no-interrupts case for UMS by polling
  drm/i915: Disable high-precision vblank timestamping for UMS
  drm/i915: Increase the amount of defense before computing vblank 
timestamps
  drm/i915,agp/intel: Do not clear stolen entries
  Remove MAYBE_BUILD_BUG_ON
  BUILD_BUG_ON: make it handle more cases
  module: fix missing semicolons in MODULE macro usage
  param: add null statement to compiled-in module params
  module: fix linker error for MODULE_VERSION when !MODULE and 
CONFIG_SYSFS=n
  module: show version information for built-in modules in sysfs
  selinux: return -ENOMEM when memory allocation fails
  tpm: fix panic caused by tpm: Autodetect itpm devices
  TPM: Long default timeout fix
  trusted keys: Fix a memory leak in trusted_update().
  keys: add trusted and encrypted maintainers
  encrypted-keys: rename encrypted_defined files to encrypted
  trusted-keys: rename trusted_defined files to trusted
  drm/i915: Recognise non-VGA display devices
  ...

commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
Author: Alex Deucher alexdeuc...@gmail.com
Date:   Mon Jan 24 17:14:26 2011 -0500

drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq

Needed for timer queries in the 3D driver.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@gmail.com

= git log =

now:

  * commit 58bbf018 appears to be fine, boots reliably
  * commit 8e934dbf causes black screen issue

as you can see, rather than test the *merge* above, i decided to back
up one level and test the commit that was part of that merge, and it
failed.  is this helpful?  here's the log entry:

commit 8e934dbf264418afe4d1dff34ce074ecc14280db
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Mon Jan 24 12:34:00 2011 +

drm/i915: Prevent uninitialised reads during error state capture

error_bo and pinned_bo could be used uninitialised if there were no
active buffers.

Caught by kmemcheck.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk


  i'm going to go on and test the merge itself, abb72c82, since i
thought that was working fine earlier today.  but you can see which
commit now seems to fail.  does this make any sense?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: has the i915 black screen boot issue returned?

[Robert P. J. Day]

  one more observation which should nail things down:

On Thu, 27 Jan 2011, Robert P. J. Day wrote:

   ok, i'm getting different results from this morning, not sure why,
 but i'm fairly confident i've isolated it to this extent.  here's the
 salient part of the git log i'm looking at:

 = git log =

 commit abb72c828878a2c69b2cfb33ac30007c8ecd735e
 Merge: 58bbf01 8e934db
 Author: Dave Airlie airl...@gmail.com
 Date:   Tue Jan 25 08:41:58 2011 +1000

 Merge branch 'drm-intel-fixes-2' of 
 ssh://master.kernel.org/pub/scm/linux/kernel/g

 * 'drm-intel-fixes-2' of 
 ssh://master.kernel.org/pub/scm/linux/kernel/git/ickle/dr
   drm/i915: Prevent uninitialised reads during error state capture
   drm/i915: Use consistent mappings for OpRegion between ACPI and i915
   drm/i915: Handle the no-interrupts case for UMS by polling
   drm/i915: Disable high-precision vblank timestamping for UMS
   drm/i915: Increase the amount of defense before computing vblank 
 timestamps
   drm/i915,agp/intel: Do not clear stolen entries
   Remove MAYBE_BUILD_BUG_ON
   BUILD_BUG_ON: make it handle more cases
   module: fix missing semicolons in MODULE macro usage
   param: add null statement to compiled-in module params
   module: fix linker error for MODULE_VERSION when !MODULE and 
 CONFIG_SYSFS=n
   module: show version information for built-in modules in sysfs
   selinux: return -ENOMEM when memory allocation fails
   tpm: fix panic caused by tpm: Autodetect itpm devices
   TPM: Long default timeout fix
   trusted keys: Fix a memory leak in trusted_update().
   keys: add trusted and encrypted maintainers
   encrypted-keys: rename encrypted_defined files to encrypted
   trusted-keys: rename trusted_defined files to trusted
   drm/i915: Recognise non-VGA display devices
   ...

 commit 58bbf018a70c562437eeae121a5d021ba7fe56a5
 Author: Alex Deucher alexdeuc...@gmail.com
 Date:   Mon Jan 24 17:14:26 2011 -0500

 drm/radeon/kms: add new radeon_info ioctl query for clock crystal freq

 Needed for timer queries in the 3D driver.

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Signed-off-by: Dave Airlie airl...@gmail.com

 = git log =

 now:

   * commit 58bbf018 appears to be fine, boots reliably
   * commit 8e934dbf causes black screen issue

 as you can see, rather than test the *merge* above, i decided to back
 up one level and test the commit that was part of that merge, and it
 failed.  is this helpful?  here's the log entry:

 commit 8e934dbf264418afe4d1dff34ce074ecc14280db
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Mon Jan 24 12:34:00 2011 +

 drm/i915: Prevent uninitialised reads during error state capture

 error_bo and pinned_bo could be used uninitialised if there were no
 active buffers.

 Caught by kmemcheck.

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk


   i'm going to go on and test the merge itself, abb72c82, since i
 thought that was working fine earlier today.  but you can see which
 commit now seems to fail.  does this make any sense?

  i did indeed test commit abb72c82 (the merge of the above), and it
failed.  not sure why i posted earlier today that it worked, i must
have built something incorrectly.  so, in conclusion:

  * commit 58bbf018 appears to be fine, boots reliably
  * commit 8e934dbf causes black screen issue
  * commit abb72c82 also causes black screen issue

and on that note, signing off for the evening.

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

has the i915 "black screen" boot issue returned?

[Robert P. J. Day]

  after suffering through the i915 "black screen" issue for a while,
it was a relief that it finally seemed to be resolved with 2.6.37 or
something in tha vicinity.  but i just built and booted a 2.6.38-rc2+
kernel on my ubuntu 10.10 system and it once again boots to a black
screen.

  is this a new known issue?  has anyone else seen this?

rday

-- 

========
Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

has the i915 black screen boot issue returned?

[Robert P. J. Day]

  after suffering through the i915 black screen issue for a while,
it was a relief that it finally seemed to be resolved with 2.6.37 or
something in tha vicinity.  but i just built and booted a 2.6.38-rc2+
kernel on my ubuntu 10.10 system and it once again boots to a black
screen.

  is this a new known issue?  has anyone else seen this?

rday

-- 


Robert P. J. Day   Waterloo, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel