On Monday, August 30, 2010, Jonathan Corbet wrote:
> On Mon, 30 Aug 2010 00:36:36 +0200 (CEST)
> "Rafael J. Wysocki" wrote:
>
> > The following bug entry is on the current list of known regressions
> > from 2.6.35. Please verify if it still should be listed and let the
> > tracking team
> > kno
On Monday, August 30, 2010, Jonathan Corbet wrote:
> On Mon, 30 Aug 2010 00:36:36 +0200 (CEST)
> "Rafael J. Wysocki" wrote:
>
> > The following bug entry is on the current list of known regressions
> > from 2.6.35. Please verify if it still should be listed and let the
> > tracking team
> > kno
On poniedzia?ek, 23 sierpnia 2010 o 19:01:45 Jonathan Corbet wrote:
> So I decided to fire up -rc2 today to see what would happen...the
> results are best described by the attached images. Something is
> clearly scrambled between my hardware and the i915 driver. Display with X
> is hosed, but thi
On poniedziałek, 23 sierpnia 2010 o 19:01:45 Jonathan Corbet wrote:
> So I decided to fire up -rc2 today to see what would happen...the
> results are best described by the attached images. Something is
> clearly scrambled between my hardware and the i915 driver. Display with X
> is hosed, but thi
On Tue, 24 Aug 2010 07:16:26 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:55:54 +0100
> Chris Wilson wrote:
>
> > In threes. Hmm, one for primary, cursor and self-refresh. drm.debug=0xe
> > would be interesting to see what the pixel clock is.
> >
> > Can you grab one before the bad co
On Tue, 24 Aug 2010 00:55:54 +0100
Chris Wilson wrote:
> In threes. Hmm, one for primary, cursor and self-refresh. drm.debug=0xe
> would be interesting to see what the pixel clock is.
>
> Can you grab one before the bad commit and one after? If there is a change
> that may help pin-point the mis
On Tue, 24 Aug 2010 07:16:26 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:55:54 +0100
> Chris Wilson wrote:
>
> > In threes. Hmm, one for primary, cursor and self-refresh. drm.debug=0xe
> > would be interesting to see what the pixel clock is.
> >
> > Can you grab one before the bad co
On Mon, 23 Aug 2010 17:46:41 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:37:52 +0100
> Chris Wilson wrote:
>
> > drm.debug=0x4 should print the right information for this bug.
>
> That doesn't seem to give me any output at all.
>
> One thing I noticed, though, is that I occasionally
On Mon, 23 Aug 2010 17:32:25 -0600, Jonathan Corbet wrote:
> On Mon, 23 Aug 2010 23:36:55 +0100
> Chris Wilson wrote:
>
> > Taking the patch at face value, the cause should be a mistake in error
> > handling. So the first step would be to identify which i2c_transfer()
> > failed.
>
> OK, I trie
On Mon, 23 Aug 2010 15:17:08 -0600, Jonathan Corbet wrote:
> I went ahead and bisected the problem, which was added between -rc1 and
> -rc2. The end result is this:
Taking the patch at face value, the cause should be a mistake in error
handling. So the first step would be to identify which i2c_t
On Tue, 24 Aug 2010 00:37:52 +0100
Chris Wilson wrote:
> drm.debug=0x4 should print the right information for this bug.
That doesn't seem to give me any output at all.
One thing I noticed, though, is that I occasionally get something like:
Aug 23 17:43:14 bike kernel: [ 142.920185] [drm:intel
On Mon, 23 Aug 2010 23:36:55 +0100
Chris Wilson wrote:
> Taking the patch at face value, the cause should be a mistake in error
> handling. So the first step would be to identify which i2c_transfer()
> failed.
OK, I tried it, but neither warning triggers.
Don't know if it helps or not, but I tr
On Mon, 23 Aug 2010 17:46:41 -0600, Jonathan Corbet wrote:
> On Tue, 24 Aug 2010 00:37:52 +0100
> Chris Wilson wrote:
>
> > drm.debug=0x4 should print the right information for this bug.
>
> That doesn't seem to give me any output at all.
>
> One thing I noticed, though, is that I occasionally
On Tue, 24 Aug 2010 00:37:52 +0100
Chris Wilson wrote:
> drm.debug=0x4 should print the right information for this bug.
That doesn't seem to give me any output at all.
One thing I noticed, though, is that I occasionally get something like:
Aug 23 17:43:14 bike kernel: [ 142.920185] [drm:intel
On Mon, 23 Aug 2010 17:32:25 -0600, Jonathan Corbet wrote:
> On Mon, 23 Aug 2010 23:36:55 +0100
> Chris Wilson wrote:
>
> > Taking the patch at face value, the cause should be a mistake in error
> > handling. So the first step would be to identify which i2c_transfer()
> > failed.
>
> OK, I trie
On Mon, 23 Aug 2010 23:36:55 +0100
Chris Wilson wrote:
> Taking the patch at face value, the cause should be a mistake in error
> handling. So the first step would be to identify which i2c_transfer()
> failed.
OK, I tried it, but neither warning triggers.
Don't know if it helps or not, but I tr
On Mon, 23 Aug 2010 15:17:08 -0600, Jonathan Corbet wrote:
> I went ahead and bisected the problem, which was added between -rc1 and
> -rc2. The end result is this:
Taking the patch at face value, the cause should be a mistake in error
handling. So the first step would be to identify which i2c_t
On Mon, 23 Aug 2010 11:01:45 -0600
Jonathan Corbet wrote:
> So I decided to fire up -rc2 today to see what would happen...the
> results are best described by the attached images. Something is
> clearly scrambled between my hardware and the i915 driver. Display with X
> is hosed, but things go w
On Mon, 23 Aug 2010 11:01:45 -0600
Jonathan Corbet wrote:
> So I decided to fire up -rc2 today to see what would happen...the
> results are best described by the attached images. Something is
> clearly scrambled between my hardware and the i915 driver. Display with X
> is hosed, but things go w
So I decided to fire up -rc2 today to see what would happen...the
results are best described by the attached images. Something is
clearly scrambled between my hardware and the i915 driver. Display with X
is hosed, but things go weird before X gets a chance to run (it is worth
noting that the init
20 matches
Mail list logo
