Linux 3.4-rc4

[Nick Bowler]

On 2012-05-04 10:20 +0100, Dave Airlie wrote:
> >>
> >> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
> >> are no such checksum errors in the log. ?It's just missing.
> >>
> >> > Just a crazy thought, but didn't we change some timings related to
> >> > EDID retrieval? To make it faster.
> >>
> >> OK, this time bisecting started off relatively smoothly (doing the same
> >> "backwards" bisect on the branch-o-reverts as last time), but then my
> >> disk died halfway through...
> > [...]
> >
> > OK, system is back online and I finished the bisection. ?The commit that
> > broke it for me is the following, and reverting it on top of 3.3.4 + the
> > "make VGA work at all" patch fixes this particular issue for me.
> >
> Can you test with the attached patch? its a revert mostly of Ben's patch, and
> he says with the i2c core change stuff is working for him again.

Yup, this one seems to work on top of Linus' master.

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
> On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> > Hi Luca, Maarten,
> > 
> > On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis  > > gmail.com> wrote:
> > > > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > > >
> > > >  wrote:
> > > >> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > > >>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > > >>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  > > >>> > elliptictech.com> wrote:
> > > >>> > > Unfortunately, that's not the end of my VGA-related
> > > >>> > > regressions. :(
> > > >>> > >
> > > >>> > > While tracking down the black screen issue, I've been having
> > > >>> > > the monitor directly connected to the video card the whole
> > > >>> > > time, but now when I'm connected through my KVM switch (an
> > > >>> > > IOGear GCS1804), it appears that something's going wrong with
> > > >>> > > reading the EDID, because the available modes are all screwed
> > > >>> > > up (both console and X decide they want to drive the display
> > > >>> > > at 1024x768).  Here's the output of xrandr on 3.2.15:
> > > >>> > >
> > > >>> > >  % xrandr
> > > >>> > >  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
> > > >>> > > 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
> > > >>> > > inverted right x axis y axis) 352mm x 264mm
> > > >>> > > 1600x1200  75.0*+   70.0 65.0 60.0
> > > >>> > > 1280x1024  85.0 +   75.0 60.0
> > > >>> > > 1920x1440  60.0
> > > >>> > > 1856x1392  60.0
> > > >>> > > 1792x1344  60.0
> > > >>> > > 1920x1200  74.9 59.9
> > > >>> > > 1680x1050  84.9 74.9 60.0
> > > >>> > > 1400x1050  85.0 74.9 60.0
> > > >>> > > 1440x900   84.8 75.0 59.9
> > > >>> > > 1280x960   85.0 60.0
> > > >>> > > 1360x768   60.0
> > > >>> > > 1280x800   84.9 74.9 59.8
> > > >>> > > 1152x864   75.0
> > > >>> > > 1280x768   84.8 74.9 59.9
> > > >>> > > 1024x768   85.0 75.1 75.0 70.1 60.0 
> > > >>> > > 43.5 43.5
> > > >>> > > 832x62474.6
> > > >>> > > 800x60085.1 72.2 75.0 60.3 56.2
> > > >>> > > 848x48060.0
> > > >>> > > 640x48085.0 75.0 72.8 72.8 66.7 
> > > >>> > > 60.0 59.9
> > > >>> > > 720x40085.0 87.8 70.1
> > > >>> > > 640x40085.1
> > > >>> > > 640x35085.1
> > > >>> > > 320x200   165.1
> > > >>> > >
> > > >>> > > And on 3.4-rc4+ (with your patch cherry-picked):
> > > >>> > >
> > > >>> > >  % xrandr
> > > >>> > >  Screen 1: minimum 320 x 200, current 1024 x 768, maximum
> > > >>> > > 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
> > > >>> > > inverted right x axis y axis) 0mm x 0mm
> > > >>> > > 1024x768   60.0*
> > > >>> > > 800x60060.3 56.2
> > > >>> > > 848x48060.0
> > > >>> > > 640x48059.9
> > > >>> > > 320x200   165.1
> > > >>> > >
> > > >>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black
> > > >>> > > for a second when it does not on 3.2.15.  It also causes
> > > >>> > > several messages of the form
> > > >>> > >
> > > >>> > >  [drm] nouveau :01:00.0: Load detected on output B
> > > >>> > >
> > > >>> > > to be logged.  Also, looking at
> > > >>> > > /sys/class/drm/card0-VGA-1/edid I see that it is empty on
> > > >>> > > 3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
> > > >>> > > when the KVM is not involved.
> > > >>> >
> > > >>> > Were you ever able to fetch a EDID with the KVM involved?  KVMs
> > > >>> > are notorious for not connecting the ddc pins.
> > > >>>
> > > >>> Yes, it works on 3.2.15 as described above.
> > > >>
> > > >> I have the same (or similar) KVM (not in the office at the moment)
> > > >> and I can confirm that with newer kernels EDID fecthing in flaky.
> > > >> It's 50/50 if EDED retrieval succeeds or if it fails with:
> > > >>
> > > >> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
> > > >> [drm:drm_edid_block_valid] *ERROR* EDID 

Linux 3.4-rc4

[Dave Airlie]

>>
>> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
>> are no such checksum errors in the log. ?It's just missing.
>>
>> > Just a crazy thought, but didn't we change some timings related to
>> > EDID retrieval? To make it faster.
>>
>> OK, this time bisecting started off relatively smoothly (doing the same
>> "backwards" bisect on the branch-o-reverts as last time), but then my
>> disk died halfway through...
> [...]
>
> OK, system is back online and I finished the bisection. ?The commit that
> broke it for me is the following, and reverting it on top of 3.3.4 + the
> "make VGA work at all" patch fixes this particular issue for me.
>
Can you test with the attached patch? its a revert mostly of Ben's patch, and
he says with the i2c core change stuff is working for him again.

Dave.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-nouveau-i2c-resume-use-of-i2c-algo-bit-rather-th.patch
Type: application/octet-stream
Size: 6614 bytes
Desc: not available
URL: 

Re: Linux 3.4-rc4

[Dave Airlie]

 FWIW, for me EDID failure on new kernels is 100% reproducible, and there
 are no such checksum errors in the log.  It's just missing.

  Just a crazy thought, but didn't we change some timings related to
  EDID retrieval? To make it faster.

 OK, this time bisecting started off relatively smoothly (doing the same
 backwards bisect on the branch-o-reverts as last time), but then my
 disk died halfway through...
 [...]

 OK, system is back online and I finished the bisection.  The commit that
 broke it for me is the following, and reverting it on top of 3.3.4 + the
 make VGA work at all patch fixes this particular issue for me.

Can you test with the attached patch? its a revert mostly of Ben's patch, and
he says with the i2c core change stuff is working for him again.

Dave.


0001-drm-nouveau-i2c-resume-use-of-i2c-algo-bit-rather-th.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
 On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
  Hi Luca, Maarten,
  
  On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
   On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis madman2...@gmail.com 
   wrote:
On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
   
dmitry.torok...@gmail.com wrote:
On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
On 2012-04-28 02:19 -0400, Alex Deucher wrote:
 On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler 
 nbow...@elliptictech.com wrote:
  Unfortunately, that's not the end of my VGA-related
  regressions. :(
 
  While tracking down the black screen issue, I've been having
  the monitor directly connected to the video card the whole
  time, but now when I'm connected through my KVM switch (an
  IOGear GCS1804), it appears that something's going wrong with
  reading the EDID, because the available modes are all screwed
  up (both console and X decide they want to drive the display
  at 1024x768).  Here's the output of xrandr on 3.2.15:
 
   % xrandr
   Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
  4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
  inverted right x axis y axis) 352mm x 264mm
  1600x1200  75.0*+   70.0 65.0 60.0
  1280x1024  85.0 +   75.0 60.0
  1920x1440  60.0
  1856x1392  60.0
  1792x1344  60.0
  1920x1200  74.9 59.9
  1680x1050  84.9 74.9 60.0
  1400x1050  85.0 74.9 60.0
  1440x900   84.8 75.0 59.9
  1280x960   85.0 60.0
  1360x768   60.0
  1280x800   84.9 74.9 59.8
  1152x864   75.0
  1280x768   84.8 74.9 59.9
  1024x768   85.0 75.1 75.0 70.1 60.0 
  43.5 43.5
  832x62474.6
  800x60085.1 72.2 75.0 60.3 56.2
  848x48060.0
  640x48085.0 75.0 72.8 72.8 66.7 
  60.0 59.9
  720x40085.0 87.8 70.1
  640x40085.1
  640x35085.1
  320x200   165.1
 
  And on 3.4-rc4+ (with your patch cherry-picked):
 
   % xrandr
   Screen 1: minimum 320 x 200, current 1024 x 768, maximum
  4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
  inverted right x axis y axis) 0mm x 0mm
  1024x768   60.0*
  800x60060.3 56.2
  848x48060.0
  640x48059.9
  320x200   165.1
 
  Running xrandr on 3.4-rc4+ also causes the screen to go black
  for a second when it does not on 3.2.15.  It also causes
  several messages of the form
 
   [drm] nouveau :01:00.0: Load detected on output B
 
  to be logged.  Also, looking at
  /sys/class/drm/card0-VGA-1/edid I see that it is empty on
  3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
  when the KVM is not involved.

 Were you ever able to fetch a EDID with the KVM involved?  KVMs
 are notorious for not connecting the ddc pins.
   
Yes, it works on 3.2.15 as described above.
   
I have the same (or similar) KVM (not in the office at the moment)
and I can confirm that with newer kernels EDID fecthing in flaky.
It's 50/50 if EDED retrieval succeeds or if it fails with:
   
Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 208
   
Earlier kernels were able to retrieve EDEDs reliably.
   
This is with:
   
[1.678392] [drm] nouveau :01:00.0: Detected an NV50
generation card (0x086b00a2)

Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> Hi Luca, Maarten,
> 
> On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis  > gmail.com> wrote:
> > > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > >
> > >  wrote:
> > >> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > >>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > >>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  > >>> > elliptictech.com> wrote:
> > >>> > > Unfortunately, that's not the end of my VGA-related
> > >>> > > regressions. :(
> > >>> > >
> > >>> > > While tracking down the black screen issue, I've been having
> > >>> > > the monitor directly connected to the video card the whole
> > >>> > > time, but now when I'm connected through my KVM switch (an
> > >>> > > IOGear GCS1804), it appears that something's going wrong with
> > >>> > > reading the EDID, because the available modes are all screwed
> > >>> > > up (both console and X decide they want to drive the display
> > >>> > > at 1024x768).  Here's the output of xrandr on 3.2.15:
> > >>> > >
> > >>> > >  % xrandr
> > >>> > >  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
> > >>> > > 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
> > >>> > > inverted right x axis y axis) 352mm x 264mm
> > >>> > > 1600x1200  75.0*+   70.0 65.0 60.0
> > >>> > > 1280x1024  85.0 +   75.0 60.0
> > >>> > > 1920x1440  60.0
> > >>> > > 1856x1392  60.0
> > >>> > > 1792x1344  60.0
> > >>> > > 1920x1200  74.9 59.9
> > >>> > > 1680x1050  84.9 74.9 60.0
> > >>> > > 1400x1050  85.0 74.9 60.0
> > >>> > > 1440x900   84.8 75.0 59.9
> > >>> > > 1280x960   85.0 60.0
> > >>> > > 1360x768   60.0
> > >>> > > 1280x800   84.9 74.9 59.8
> > >>> > > 1152x864   75.0
> > >>> > > 1280x768   84.8 74.9 59.9
> > >>> > > 1024x768   85.0 75.1 75.0 70.1 60.0 
> > >>> > > 43.5 43.5
> > >>> > > 832x62474.6
> > >>> > > 800x60085.1 72.2 75.0 60.3 56.2
> > >>> > > 848x48060.0
> > >>> > > 640x48085.0 75.0 72.8 72.8 66.7 
> > >>> > > 60.0 59.9
> > >>> > > 720x40085.0 87.8 70.1
> > >>> > > 640x40085.1
> > >>> > > 640x35085.1
> > >>> > > 320x200   165.1
> > >>> > >
> > >>> > > And on 3.4-rc4+ (with your patch cherry-picked):
> > >>> > >
> > >>> > >  % xrandr
> > >>> > >  Screen 1: minimum 320 x 200, current 1024 x 768, maximum
> > >>> > > 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
> > >>> > > inverted right x axis y axis) 0mm x 0mm
> > >>> > > 1024x768   60.0*
> > >>> > > 800x60060.3 56.2
> > >>> > > 848x48060.0
> > >>> > > 640x48059.9
> > >>> > > 320x200   165.1
> > >>> > >
> > >>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black
> > >>> > > for a second when it does not on 3.2.15.  It also causes
> > >>> > > several messages of the form
> > >>> > >
> > >>> > >  [drm] nouveau :01:00.0: Load detected on output B
> > >>> > >
> > >>> > > to be logged.  Also, looking at
> > >>> > > /sys/class/drm/card0-VGA-1/edid I see that it is empty on
> > >>> > > 3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
> > >>> > > when the KVM is not involved.
> > >>> >
> > >>> > Were you ever able to fetch a EDID with the KVM involved?  KVMs
> > >>> > are notorious for not connecting the ddc pins.
> > >>>
> > >>> Yes, it works on 3.2.15 as described above.
> > >>
> > >> I have the same (or similar) KVM (not in the office at the moment)
> > >> and I can confirm that with newer kernels EDID fecthing in flaky.
> > >> It's 50/50 if EDED retrieval succeeds or if it fails with:
> > >>
> > >> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
> > >> 

Linux 3.4-rc4

[Jean Delvare]

Hi Luca, Maarten,

On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis  
> wrote:
> > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> >
> >  wrote:
> >> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> >>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> >>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  >>> > elliptictech.com> wrote:
> >>> > > Unfortunately, that's not the end of my VGA-related
> >>> > > regressions. :(
> >>> > >
> >>> > > While tracking down the black screen issue, I've been having
> >>> > > the monitor directly connected to the video card the whole
> >>> > > time, but now when I'm connected through my KVM switch (an
> >>> > > IOGear GCS1804), it appears that something's going wrong with
> >>> > > reading the EDID, because the available modes are all screwed
> >>> > > up (both console and X decide they want to drive the display
> >>> > > at 1024x768).  Here's the output of xrandr on 3.2.15:
> >>> > >
> >>> > >  % xrandr
> >>> > >  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
> >>> > > 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
> >>> > > inverted right x axis y axis) 352mm x 264mm
> >>> > > 1600x1200  75.0*+   70.0 65.0 60.0
> >>> > > 1280x1024  85.0 +   75.0 60.0
> >>> > > 1920x1440  60.0
> >>> > > 1856x1392  60.0
> >>> > > 1792x1344  60.0
> >>> > > 1920x1200  74.9 59.9
> >>> > > 1680x1050  84.9 74.9 60.0
> >>> > > 1400x1050  85.0 74.9 60.0
> >>> > > 1440x900   84.8 75.0 59.9
> >>> > > 1280x960   85.0 60.0
> >>> > > 1360x768   60.0
> >>> > > 1280x800   84.9 74.9 59.8
> >>> > > 1152x864   75.0
> >>> > > 1280x768   84.8 74.9 59.9
> >>> > > 1024x768   85.0 75.1 75.0 70.1 60.0 43.5  
> >>> > >43.5
> >>> > > 832x62474.6
> >>> > > 800x60085.1 72.2 75.0 60.3 56.2
> >>> > > 848x48060.0
> >>> > > 640x48085.0 75.0 72.8 72.8 66.7 60.0  
> >>> > >59.9
> >>> > > 720x40085.0 87.8 70.1
> >>> > > 640x40085.1
> >>> > > 640x35085.1
> >>> > > 320x200   165.1
> >>> > >
> >>> > > And on 3.4-rc4+ (with your patch cherry-picked):
> >>> > >
> >>> > >  % xrandr
> >>> > >  Screen 1: minimum 320 x 200, current 1024 x 768, maximum
> >>> > > 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
> >>> > > inverted right x axis y axis) 0mm x 0mm
> >>> > > 1024x768   60.0*
> >>> > > 800x60060.3 56.2
> >>> > > 848x48060.0
> >>> > > 640x48059.9
> >>> > > 320x200   165.1
> >>> > >
> >>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black
> >>> > > for a second when it does not on 3.2.15.  It also causes
> >>> > > several messages of the form
> >>> > >
> >>> > >  [drm] nouveau :01:00.0: Load detected on output B
> >>> > >
> >>> > > to be logged.  Also, looking at
> >>> > > /sys/class/drm/card0-VGA-1/edid I see that it is empty on
> >>> > > 3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
> >>> > > when the KVM is not involved.
> >>> >
> >>> > Were you ever able to fetch a EDID with the KVM involved?  KVMs
> >>> > are notorious for not connecting the ddc pins.
> >>>
> >>> Yes, it works on 3.2.15 as described above.
> >>
> >> I have the same (or similar) KVM (not in the office at the moment)
> >> and I can confirm that with newer kernels EDID fecthing in flaky.
> >> It's 50/50 if EDED retrieval succeeds or if it fails with:
> >>
> >> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208
> >>
> >> Earlier kernels were able to retrieve EDEDs 

Re: Linux 3.4-rc4

[Jean Delvare]

Hi Luca, Maarten,

On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
 On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis madman2...@gmail.com 
 wrote:
  On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
 
  dmitry.torok...@gmail.com wrote:
  On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
  On 2012-04-28 02:19 -0400, Alex Deucher wrote:
   On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com 
   wrote:
Unfortunately, that's not the end of my VGA-related
regressions. :(
   
While tracking down the black screen issue, I've been having
the monitor directly connected to the video card the whole
time, but now when I'm connected through my KVM switch (an
IOGear GCS1804), it appears that something's going wrong with
reading the EDID, because the available modes are all screwed
up (both console and X decide they want to drive the display
at 1024x768).  Here's the output of xrandr on 3.2.15:
   
 % xrandr
 Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
inverted right x axis y axis) 352mm x 264mm
1600x1200  75.0*+   70.0 65.0 60.0
1280x1024  85.0 +   75.0 60.0
1920x1440  60.0
1856x1392  60.0
1792x1344  60.0
1920x1200  74.9 59.9
1680x1050  84.9 74.9 60.0
1400x1050  85.0 74.9 60.0
1440x900   84.8 75.0 59.9
1280x960   85.0 60.0
1360x768   60.0
1280x800   84.9 74.9 59.8
1152x864   75.0
1280x768   84.8 74.9 59.9
1024x768   85.0 75.1 75.0 70.1 60.0 43.5  
   43.5
832x62474.6
800x60085.1 72.2 75.0 60.3 56.2
848x48060.0
640x48085.0 75.0 72.8 72.8 66.7 60.0  
   59.9
720x40085.0 87.8 70.1
640x40085.1
640x35085.1
320x200   165.1
   
And on 3.4-rc4+ (with your patch cherry-picked):
   
 % xrandr
 Screen 1: minimum 320 x 200, current 1024 x 768, maximum
4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
inverted right x axis y axis) 0mm x 0mm
1024x768   60.0*
800x60060.3 56.2
848x48060.0
640x48059.9
320x200   165.1
   
Running xrandr on 3.4-rc4+ also causes the screen to go black
for a second when it does not on 3.2.15.  It also causes
several messages of the form
   
 [drm] nouveau :01:00.0: Load detected on output B
   
to be logged.  Also, looking at
/sys/class/drm/card0-VGA-1/edid I see that it is empty on
3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
when the KVM is not involved.
  
   Were you ever able to fetch a EDID with the KVM involved?  KVMs
   are notorious for not connecting the ddc pins.
 
  Yes, it works on 3.2.15 as described above.
 
  I have the same (or similar) KVM (not in the office at the moment)
  and I can confirm that with newer kernels EDID fecthing in flaky.
  It's 50/50 if EDED retrieval succeeds or if it fails with:
 
  Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
  [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
  remainder is 208
 
  Earlier kernels were able to retrieve EDEDs reliably.
 
  This is with:
 
  [1.678392] [drm] nouveau :01:00.0: Detected an NV50
  generation card (0x086b00a2)
 
  Just a crazy thought, but didn't we change some timings related to
  EDID retrieval? To make it faster.
 
 Hum, this commit:
 
 commit 1849ecb22fb3b5d57b65e7369a3957adf9f26f39
 Author: Jean Delvare jdelv...@suse.de
 Date:   Sat Jan 28 11:07:09 2012 +0100
 
 drm/kms: Make i2c buses faster
 
 doubled the data rate but only 

Re: Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
 Hi Luca, Maarten,
 
 On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
  On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis madman2...@gmail.com 
  wrote:
   On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
  
   dmitry.torok...@gmail.com wrote:
   On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
   On 2012-04-28 02:19 -0400, Alex Deucher wrote:
On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler 
nbow...@elliptictech.com wrote:
 Unfortunately, that's not the end of my VGA-related
 regressions. :(

 While tracking down the black screen issue, I've been having
 the monitor directly connected to the video card the whole
 time, but now when I'm connected through my KVM switch (an
 IOGear GCS1804), it appears that something's going wrong with
 reading the EDID, because the available modes are all screwed
 up (both console and X decide they want to drive the display
 at 1024x768).  Here's the output of xrandr on 3.2.15:

  % xrandr
  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum
 4096 x 4096 VGA-1 connected 1600x1200+0+0 (normal left
 inverted right x axis y axis) 352mm x 264mm
 1600x1200  75.0*+   70.0 65.0 60.0
 1280x1024  85.0 +   75.0 60.0
 1920x1440  60.0
 1856x1392  60.0
 1792x1344  60.0
 1920x1200  74.9 59.9
 1680x1050  84.9 74.9 60.0
 1400x1050  85.0 74.9 60.0
 1440x900   84.8 75.0 59.9
 1280x960   85.0 60.0
 1360x768   60.0
 1280x800   84.9 74.9 59.8
 1152x864   75.0
 1280x768   84.8 74.9 59.9
 1024x768   85.0 75.1 75.0 70.1 60.0 
 43.5 43.5
 832x62474.6
 800x60085.1 72.2 75.0 60.3 56.2
 848x48060.0
 640x48085.0 75.0 72.8 72.8 66.7 
 60.0 59.9
 720x40085.0 87.8 70.1
 640x40085.1
 640x35085.1
 320x200   165.1

 And on 3.4-rc4+ (with your patch cherry-picked):

  % xrandr
  Screen 1: minimum 320 x 200, current 1024 x 768, maximum
 4096 x 4096 VGA-1 connected 1024x768+0+0 (normal left
 inverted right x axis y axis) 0mm x 0mm
 1024x768   60.0*
 800x60060.3 56.2
 848x48060.0
 640x48059.9
 320x200   165.1

 Running xrandr on 3.4-rc4+ also causes the screen to go black
 for a second when it does not on 3.2.15.  It also causes
 several messages of the form

  [drm] nouveau :01:00.0: Load detected on output B

 to be logged.  Also, looking at
 /sys/class/drm/card0-VGA-1/edid I see that it is empty on
 3.4-rc4+ and it is correct on 3.2.15.  Things seem to work OK
 when the KVM is not involved.
   
Were you ever able to fetch a EDID with the KVM involved?  KVMs
are notorious for not connecting the ddc pins.
  
   Yes, it works on 3.2.15 as described above.
  
   I have the same (or similar) KVM (not in the office at the moment)
   and I can confirm that with newer kernels EDID fecthing in flaky.
   It's 50/50 if EDED retrieval succeeds or if it fails with:
  
   Apr 26 13:06:57 dtor-d630 kernel: [13464.936336]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063]
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
   remainder is 208
  
   Earlier kernels were able to retrieve EDEDs reliably.
  
   This is with:
  
   [1.678392] [drm] nouveau :01:00.0: Detected an NV50
   generation card (0x086b00a2)
  
   Just a crazy thought, but didn't we change some timings related to
   EDID retrieval? To make it faster.
  
  Hum, this commit:
  
  commit 

Linux 3.4-rc4

[Nick Bowler]

(re-adding Ben to the Cc because he was apparently dropped somewhere in
this thread)

On 2012-05-01 09:23 -0400, Nick Bowler wrote:
> On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> >  wrote:
> > > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> > >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  > >> > elliptictech.com> wrote:
> > >> > > While tracking down the black screen issue, I've been having the 
> > >> > > monitor
> > >> > > directly connected to the video card the whole time, but now when I'm
> > >> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> > >> > > something's going wrong with reading the EDID, because the available
> > >> > > modes are all screwed up (both console and X decide they want to 
> > >> > > drive
> > >> > > the display at 1024x768).
> [...]
> > >> > > Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
> > >> > > is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
> > >> > > to work OK when the KVM is not involved.
> > >> >
> > >> > Were you ever able to fetch a EDID with the KVM involved? ?KVMs are
> > >> > notorious for not connecting the ddc pins.
> > >>
> > >> Yes, it works on 3.2.15 as described above.
> > >
> > > I have the same (or similar) KVM (not in the office at the moment) and I
> > > can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> > > if EDED retrieval succeeds or if it fails with:
> > >
> > > Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] 
> > > [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 
> > > 208
> [...]
> > > Earlier kernels were able to retrieve EDEDs reliably.
> 
> FWIW, for me EDID failure on new kernels is 100% reproducible, and there
> are no such checksum errors in the log.  It's just missing.
> 
> > Just a crazy thought, but didn't we change some timings related to
> > EDID retrieval? To make it faster.
> 
> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through...
[...]

OK, system is back online and I finished the bisection.  The commit that
broke it for me is the following, and reverting it on top of 3.3.4 + the
"make VGA work at all" patch fixes this particular issue for me.

commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
Author: Ben Skeggs 
Date:   Wed Dec 21 18:09:12 2011 +1000

drm/nouveau/i2c: handle bit-banging ourselves

i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.

The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it.  However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.

So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.

Signed-off-by: Ben Skeggs 

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Alan Cox]

On Tue, 1 May 2012 11:31:23 -0400
Nick Bowler  wrote:

> On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > > OK, this time bisecting started off relatively smoothly (doing the same
> > > "backwards" bisect on the branch-o-reverts as last time), but then my
> > > disk died halfway through...  So I'll post the partial bisection results
> > > now (11 commits left to test), but I clearly have other things to fix
> > > before I can get back to this issue.
> > 
> > You may get stupid answers because of
> > 
> > commit eeefa4bea1af34207c5299f989fffe03628ea164
> > commit 8353e6c632aeaea1470a286b83e68ca233073068
> > 
> > Been there, trying to chase down a GMA500 problemt that was muddled in
> > with the broken edid.h patch as well as a driver bug.
> 
> I'm afraid I don't understand.  These commits do not appear to be in

Ok they only got as far as the DRM tree - thats good, so you ought to get
a sane answer.

Alan

Linux 3.4-rc4

[Alan Cox]

> OK, this time bisecting started off relatively smoothly (doing the same
> "backwards" bisect on the branch-o-reverts as last time), but then my
> disk died halfway through...  So I'll post the partial bisection results
> now (11 commits left to test), but I clearly have other things to fix
> before I can get back to this issue.

You may get stupid answers because of

commit eeefa4bea1af34207c5299f989fffe03628ea164
commit 8353e6c632aeaea1470a286b83e68ca233073068

Been there, trying to chase down a GMA500 problemt that was muddled in
with the broken edid.h patch as well as a driver bug.

Alan

Linux 3.4-rc4

[Nick Bowler]

On 2012-05-01 16:09 +0100, Alan Cox wrote:
> > OK, this time bisecting started off relatively smoothly (doing the same
> > "backwards" bisect on the branch-o-reverts as last time), but then my
> > disk died halfway through...  So I'll post the partial bisection results
> > now (11 commits left to test), but I clearly have other things to fix
> > before I can get back to this issue.
> 
> You may get stupid answers because of
> 
> commit eeefa4bea1af34207c5299f989fffe03628ea164
> commit 8353e6c632aeaea1470a286b83e68ca233073068
> 
> Been there, trying to chase down a GMA500 problemt that was muddled in
> with the broken edid.h patch as well as a driver bug.

I'm afraid I don't understand.  These commits do not appear to be in
Linus' tree?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Nick Bowler]

On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
>  wrote:
> > On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> >> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> >> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  >> > elliptictech.com> wrote:
> >> > > While tracking down the black screen issue, I've been having the 
> >> > > monitor
> >> > > directly connected to the video card the whole time, but now when I'm
> >> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> >> > > something's going wrong with reading the EDID, because the available
> >> > > modes are all screwed up (both console and X decide they want to drive
> >> > > the display at 1024x768).
[...]
> >> > > Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
> >> > > is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
> >> > > to work OK when the KVM is not involved.
> >> >
> >> > Were you ever able to fetch a EDID with the KVM involved? ?KVMs are
> >> > notorious for not connecting the ddc pins.
> >>
> >> Yes, it works on 3.2.15 as described above.
> >
> > I have the same (or similar) KVM (not in the office at the moment) and I
> > can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> > if EDED retrieval succeeds or if it fails with:
> >
> > Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
> > *ERROR* EDID checksum is invalid, remainder is 208
[...]
> > Earlier kernels were able to retrieve EDEDs reliably.

FWIW, for me EDID failure on new kernels is 100% reproducible, and there
are no such checksum errors in the log.  It's just missing.

> Just a crazy thought, but didn't we change some timings related to
> EDID retrieval? To make it faster.

OK, this time bisecting started off relatively smoothly (doing the same
"backwards" bisect on the branch-o-reverts as last time), but then my
disk died halfway through...  So I'll post the partial bisection results
now (11 commits left to test), but I clearly have other things to fix
before I can get back to this issue.

  git bisect start 'drivers/gpu/drm'
  # good: [9232969e19ae7251a93ab72e405cf71e5109ec05] drm/nv40/pm: implement 
first type of pwm fanspeed funcs
  git bisect good 9232969e19ae7251a93ab72e405cf71e5109ec05
  # bad: [dea7e0ac45fd28f90bbc38ff226d36a9f788efbf] ttm: fix agp since ttm tt 
rework
  git bisect bad dea7e0ac45fd28f90bbc38ff226d36a9f788efbf
  # good: [d2491567cdbcb87b2682e0948a69d73c4dd8987e] drm/nv50/pm: only touch 
0x611200 on nv92-
  git bisect good d2491567cdbcb87b2682e0948a69d73c4dd8987e
  # good: [f9f9f536312d4c3ca39502ccf6a3af60cfe38ff4] drm/nouveau/bios: pass 
drm_device to ROMPTR, rather than nvbios
  git bisect good f9f9f536312d4c3ca39502ccf6a3af60cfe38ff4
  # bad: [d4c2c99bdc8385a0e51ce4ef2df124d14b6b9c9d] drm/nouveau/dp: remove 
broken display depth function, use the improved one
  git bisect bad d4c2c99bdc8385a0e51ce4ef2df124d14b6b9c9d

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
 On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:
  On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
  On 2012-04-28 02:19 -0400, Alex Deucher wrote:
   On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com 
   wrote:
While tracking down the black screen issue, I've been having the 
monitor
directly connected to the video card the whole time, but now when I'm
connected through my KVM switch (an IOGear GCS1804), it appears that
something's going wrong with reading the EDID, because the available
modes are all screwed up (both console and X decide they want to drive
the display at 1024x768).
[...]
Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
to work OK when the KVM is not involved.
  
   Were you ever able to fetch a EDID with the KVM involved?  KVMs are
   notorious for not connecting the ddc pins.
 
  Yes, it works on 3.2.15 as described above.
 
  I have the same (or similar) KVM (not in the office at the moment) and I
  can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
  if EDED retrieval succeeds or if it fails with:
 
  Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
  *ERROR* EDID checksum is invalid, remainder is 208
[...]
  Earlier kernels were able to retrieve EDEDs reliably.

FWIW, for me EDID failure on new kernels is 100% reproducible, and there
are no such checksum errors in the log.  It's just missing.

 Just a crazy thought, but didn't we change some timings related to
 EDID retrieval? To make it faster.

OK, this time bisecting started off relatively smoothly (doing the same
backwards bisect on the branch-o-reverts as last time), but then my
disk died halfway through...  So I'll post the partial bisection results
now (11 commits left to test), but I clearly have other things to fix
before I can get back to this issue.

  git bisect start 'drivers/gpu/drm'
  # good: [9232969e19ae7251a93ab72e405cf71e5109ec05] drm/nv40/pm: implement 
first type of pwm fanspeed funcs
  git bisect good 9232969e19ae7251a93ab72e405cf71e5109ec05
  # bad: [dea7e0ac45fd28f90bbc38ff226d36a9f788efbf] ttm: fix agp since ttm tt 
rework
  git bisect bad dea7e0ac45fd28f90bbc38ff226d36a9f788efbf
  # good: [d2491567cdbcb87b2682e0948a69d73c4dd8987e] drm/nv50/pm: only touch 
0x611200 on nv92-
  git bisect good d2491567cdbcb87b2682e0948a69d73c4dd8987e
  # good: [f9f9f536312d4c3ca39502ccf6a3af60cfe38ff4] drm/nouveau/bios: pass 
drm_device to ROMPTR, rather than nvbios
  git bisect good f9f9f536312d4c3ca39502ccf6a3af60cfe38ff4
  # bad: [d4c2c99bdc8385a0e51ce4ef2df124d14b6b9c9d] drm/nouveau/dp: remove 
broken display depth function, use the improved one
  git bisect bad d4c2c99bdc8385a0e51ce4ef2df124d14b6b9c9d

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

[Alan Cox]

 OK, this time bisecting started off relatively smoothly (doing the same
 backwards bisect on the branch-o-reverts as last time), but then my
 disk died halfway through...  So I'll post the partial bisection results
 now (11 commits left to test), but I clearly have other things to fix
 before I can get back to this issue.

You may get stupid answers because of

commit eeefa4bea1af34207c5299f989fffe03628ea164
commit 8353e6c632aeaea1470a286b83e68ca233073068

Been there, trying to chase down a GMA500 problemt that was muddled in
with the broken edid.h patch as well as a driver bug.

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

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-05-01 16:09 +0100, Alan Cox wrote:
  OK, this time bisecting started off relatively smoothly (doing the same
  backwards bisect on the branch-o-reverts as last time), but then my
  disk died halfway through...  So I'll post the partial bisection results
  now (11 commits left to test), but I clearly have other things to fix
  before I can get back to this issue.
 
 You may get stupid answers because of
 
 commit eeefa4bea1af34207c5299f989fffe03628ea164
 commit 8353e6c632aeaea1470a286b83e68ca233073068
 
 Been there, trying to chase down a GMA500 problemt that was muddled in
 with the broken edid.h patch as well as a driver bug.

I'm afraid I don't understand.  These commits do not appear to be in
Linus' tree?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

[Alan Cox]

On Tue, 1 May 2012 11:31:23 -0400
Nick Bowler nbow...@elliptictech.com wrote:

 On 2012-05-01 16:09 +0100, Alan Cox wrote:
   OK, this time bisecting started off relatively smoothly (doing the same
   backwards bisect on the branch-o-reverts as last time), but then my
   disk died halfway through...  So I'll post the partial bisection results
   now (11 commits left to test), but I clearly have other things to fix
   before I can get back to this issue.
  
  You may get stupid answers because of
  
  commit eeefa4bea1af34207c5299f989fffe03628ea164
  commit 8353e6c632aeaea1470a286b83e68ca233073068
  
  Been there, trying to chase down a GMA500 problemt that was muddled in
  with the broken edid.h patch as well as a driver bug.
 
 I'm afraid I don't understand.  These commits do not appear to be in

Ok they only got as far as the DRM tree - thats good, so you ought to get
a sane answer.

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

Re: Linux 3.4-rc4

[Nick Bowler]

(re-adding Ben to the Cc because he was apparently dropped somewhere in
this thread)

On 2012-05-01 09:23 -0400, Nick Bowler wrote:
 On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
  On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
  dmitry.torok...@gmail.com wrote:
   On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
   On 2012-04-28 02:19 -0400, Alex Deucher wrote:
On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler 
nbow...@elliptictech.com wrote:
 While tracking down the black screen issue, I've been having the 
 monitor
 directly connected to the video card the whole time, but now when I'm
 connected through my KVM switch (an IOGear GCS1804), it appears that
 something's going wrong with reading the EDID, because the available
 modes are all screwed up (both console and X decide they want to 
 drive
 the display at 1024x768).
 [...]
 Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it
 is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
 to work OK when the KVM is not involved.
   
Were you ever able to fetch a EDID with the KVM involved?  KVMs are
notorious for not connecting the ddc pins.
  
   Yes, it works on 3.2.15 as described above.
  
   I have the same (or similar) KVM (not in the office at the moment) and I
   can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
   if EDED retrieval succeeds or if it fails with:
  
   Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] 
   [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 
   208
 [...]
   Earlier kernels were able to retrieve EDEDs reliably.
 
 FWIW, for me EDID failure on new kernels is 100% reproducible, and there
 are no such checksum errors in the log.  It's just missing.
 
  Just a crazy thought, but didn't we change some timings related to
  EDID retrieval? To make it faster.
 
 OK, this time bisecting started off relatively smoothly (doing the same
 backwards bisect on the branch-o-reverts as last time), but then my
 disk died halfway through...
[...]

OK, system is back online and I finished the bisection.  The commit that
broke it for me is the following, and reverting it on top of 3.3.4 + the
make VGA work at all patch fixes this particular issue for me.

commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d
Author: Ben Skeggs bske...@redhat.com
Date:   Wed Dec 21 18:09:12 2011 +1000

drm/nouveau/i2c: handle bit-banging ourselves

i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.

The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it.  However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.

So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.

Signed-off-by: Ben Skeggs bske...@redhat.com

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Linux 3.4-rc4

[Luca Tettamanti]

On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis  
wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
>  wrote:
>> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler >> > elliptictech.com> wrote:
>>> > > Hi Ben,
>>> > >
>>> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>>> > >> Does this patch help you at all?
>>> > >>
>>> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>>> > >
>>> > > Yes. ?I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
>>> > > this appears to solve the "black screen on VGA" problem described in the
>>> > > original report. ?Thanks!
>>> > >
>>> > > Unfortunately, that's not the end of my VGA-related regressions. :(
>>> > >
>>> > > While tracking down the black screen issue, I've been having the monitor
>>> > > directly connected to the video card the whole time, but now when I'm
>>> > > connected through my KVM switch (an IOGear GCS1804), it appears that
>>> > > something's going wrong with reading the EDID, because the available
>>> > > modes are all screwed up (both console and X decide they want to drive
>>> > > the display at 1024x768). ?Here's the output of xrandr on 3.2.15:
>>> > >
>>> > > ?% xrandr
>>> > > ?Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
>>> > > ?VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y 
>>> > > axis) 352mm x 264mm
>>> > > ? ? 1600x1200 ? ? ?75.0*+ ? 70.0 ? ? 65.0 ? ? 60.0
>>> > > ? ? 1280x1024 ? ? ?85.0 + ? 75.0 ? ? 60.0
>>> > > ? ? 1920x1440 ? ? ?60.0
>>> > > ? ? 1856x1392 ? ? ?60.0
>>> > > ? ? 1792x1344 ? ? ?60.0
>>> > > ? ? 1920x1200 ? ? ?74.9 ? ? 59.9
>>> > > ? ? 1680x1050 ? ? ?84.9 ? ? 74.9 ? ? 60.0
>>> > > ? ? 1400x1050 ? ? ?85.0 ? ? 74.9 ? ? 60.0
>>> > > ? ? 1440x900 ? ? ? 84.8 ? ? 75.0 ? ? 59.9
>>> > > ? ? 1280x960 ? ? ? 85.0 ? ? 60.0
>>> > > ? ? 1360x768 ? ? ? 60.0
>>> > > ? ? 1280x800 ? ? ? 84.9 ? ? 74.9 ? ? 59.8
>>> > > ? ? 1152x864 ? ? ? 75.0
>>> > > ? ? 1280x768 ? ? ? 84.8 ? ? 74.9 ? ? 59.9
>>> > > ? ? 1024x768 ? ? ? 85.0 ? ? 75.1 ? ? 75.0 ? ? 70.1 ? ? 60.0 ? ? 43.5 ? 
>>> > > ? 43.5
>>> > > ? ? 832x624 ? ? ? ?74.6
>>> > > ? ? 800x600 ? ? ? ?85.1 ? ? 72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
>>> > > ? ? 848x480 ? ? ? ?60.0
>>> > > ? ? 640x480 ? ? ? ?85.0 ? ? 75.0 ? ? 72.8 ? ? 72.8 ? ? 66.7 ? ? 60.0 ? 
>>> > > ? 59.9
>>> > > ? ? 720x400 ? ? ? ?85.0 ? ? 87.8 ? ? 70.1
>>> > > ? ? 640x400 ? ? ? ?85.1
>>> > > ? ? 640x350 ? ? ? ?85.1
>>> > > ? ? 320x200 ? ? ? 165.1
>>> > >
>>> > > And on 3.4-rc4+ (with your patch cherry-picked):
>>> > >
>>> > > ?% xrandr
>>> > > ?Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
>>> > > ?VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y 
>>> > > axis) 0mm x 0mm
>>> > > ? ? 1024x768 ? ? ? 60.0*
>>> > > ? ? 800x600 ? ? ? ?60.3 ? ? 56.2
>>> > > ? ? 848x480 ? ? ? ?60.0
>>> > > ? ? 640x480 ? ? ? ?59.9
>>> > > ? ? 320x200 ? ? ? 165.1
>>> > >
>>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
>>> > > second when it does not on 3.2.15. ?It also causes several messages of
>>> > > the form
>>> > >
>>> > > ?[drm] nouveau :01:00.0: Load detected on output B
>>> > >
>>> > > to be logged. ?Also, looking at /sys/class/drm/card0-VGA-1/edid I see
>>> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
>>> > > to work OK when the KVM is not involved.
>>> >
>>> > Were you ever able to fetch a EDID with the KVM involved? ?KVMs are
>>> > notorious for not connecting the ddc pins.
>>>
>>> Yes, it works on 3.2.15 as described above.
>>
>> I have the same (or similar) KVM (not in the office at the moment) and I
>> can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
>> if EDED retrieval succeeds or if it fails with:
>>
>> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
>> *ERROR* EDID checksum is invalid, remainder is 208
>> Apr 27 09:13:03 dtor-d630 kernel: 

Linux 3.4-rc4

[Maarten Maathuis]

On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
 wrote:
> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  
>> > wrote:
>> > > Hi Ben,
>> > >
>> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>> > >> Does this patch help you at all?
>> > >>
>> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>> > >
>> > > Yes. ?I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
>> > > this appears to solve the "black screen on VGA" problem described in the
>> > > original report. ?Thanks!
>> > >
>> > > Unfortunately, that's not the end of my VGA-related regressions. :(
>> > >
>> > > While tracking down the black screen issue, I've been having the monitor
>> > > directly connected to the video card the whole time, but now when I'm
>> > > connected through my KVM switch (an IOGear GCS1804), it appears that
>> > > something's going wrong with reading the EDID, because the available
>> > > modes are all screwed up (both console and X decide they want to drive
>> > > the display at 1024x768). ?Here's the output of xrandr on 3.2.15:
>> > >
>> > > ?% xrandr
>> > > ?Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
>> > > ?VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y 
>> > > axis) 352mm x 264mm
>> > > ? ? 1600x1200 ? ? ?75.0*+ ? 70.0 ? ? 65.0 ? ? 60.0
>> > > ? ? 1280x1024 ? ? ?85.0 + ? 75.0 ? ? 60.0
>> > > ? ? 1920x1440 ? ? ?60.0
>> > > ? ? 1856x1392 ? ? ?60.0
>> > > ? ? 1792x1344 ? ? ?60.0
>> > > ? ? 1920x1200 ? ? ?74.9 ? ? 59.9
>> > > ? ? 1680x1050 ? ? ?84.9 ? ? 74.9 ? ? 60.0
>> > > ? ? 1400x1050 ? ? ?85.0 ? ? 74.9 ? ? 60.0
>> > > ? ? 1440x900 ? ? ? 84.8 ? ? 75.0 ? ? 59.9
>> > > ? ? 1280x960 ? ? ? 85.0 ? ? 60.0
>> > > ? ? 1360x768 ? ? ? 60.0
>> > > ? ? 1280x800 ? ? ? 84.9 ? ? 74.9 ? ? 59.8
>> > > ? ? 1152x864 ? ? ? 75.0
>> > > ? ? 1280x768 ? ? ? 84.8 ? ? 74.9 ? ? 59.9
>> > > ? ? 1024x768 ? ? ? 85.0 ? ? 75.1 ? ? 75.0 ? ? 70.1 ? ? 60.0 ? ? 43.5 ? ? 
>> > > 43.5
>> > > ? ? 832x624 ? ? ? ?74.6
>> > > ? ? 800x600 ? ? ? ?85.1 ? ? 72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
>> > > ? ? 848x480 ? ? ? ?60.0
>> > > ? ? 640x480 ? ? ? ?85.0 ? ? 75.0 ? ? 72.8 ? ? 72.8 ? ? 66.7 ? ? 60.0 ? ? 
>> > > 59.9
>> > > ? ? 720x400 ? ? ? ?85.0 ? ? 87.8 ? ? 70.1
>> > > ? ? 640x400 ? ? ? ?85.1
>> > > ? ? 640x350 ? ? ? ?85.1
>> > > ? ? 320x200 ? ? ? 165.1
>> > >
>> > > And on 3.4-rc4+ (with your patch cherry-picked):
>> > >
>> > > ?% xrandr
>> > > ?Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
>> > > ?VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
>> > > 0mm x 0mm
>> > > ? ? 1024x768 ? ? ? 60.0*
>> > > ? ? 800x600 ? ? ? ?60.3 ? ? 56.2
>> > > ? ? 848x480 ? ? ? ?60.0
>> > > ? ? 640x480 ? ? ? ?59.9
>> > > ? ? 320x200 ? ? ? 165.1
>> > >
>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
>> > > second when it does not on 3.2.15. ?It also causes several messages of
>> > > the form
>> > >
>> > > ?[drm] nouveau :01:00.0: Load detected on output B
>> > >
>> > > to be logged. ?Also, looking at /sys/class/drm/card0-VGA-1/edid I see
>> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
>> > > to work OK when the KVM is not involved.
>> >
>> > Were you ever able to fetch a EDID with the KVM involved? ?KVMs are
>> > notorious for not connecting the ddc pins.
>>
>> Yes, it works on 3.2.15 as described above.
>
> I have the same (or similar) KVM (not in the office at the moment) and I
> can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> if EDED retrieval succeeds or if it fails with:
>
> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
>
> Earlier kernels were able to retrieve EDEDs reliably.
>
> This is with:
>
> [ ? 

Re: Linux 3.4-rc4

[Dmitry Torokhov]

On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
 On 2012-04-28 02:19 -0400, Alex Deucher wrote:
  On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com 
  wrote:
   Hi Ben,
  
   On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
   Does this patch help you at all?
  
   http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
  
   Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
   this appears to solve the black screen on VGA problem described in the
   original report.  Thanks!
  
   Unfortunately, that's not the end of my VGA-related regressions. :(
  
   While tracking down the black screen issue, I've been having the monitor
   directly connected to the video card the whole time, but now when I'm
   connected through my KVM switch (an IOGear GCS1804), it appears that
   something's going wrong with reading the EDID, because the available
   modes are all screwed up (both console and X decide they want to drive
   the display at 1024x768).  Here's the output of xrandr on 3.2.15:
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
    VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
   352mm x 264mm
       1600x1200      75.0*+   70.0     65.0     60.0
       1280x1024      85.0 +   75.0     60.0
       1920x1440      60.0
       1856x1392      60.0
       1792x1344      60.0
       1920x1200      74.9     59.9
       1680x1050      84.9     74.9     60.0
       1400x1050      85.0     74.9     60.0
       1440x900       84.8     75.0     59.9
       1280x960       85.0     60.0
       1360x768       60.0
       1280x800       84.9     74.9     59.8
       1152x864       75.0
       1280x768       84.8     74.9     59.9
       1024x768       85.0     75.1     75.0     70.1     60.0     43.5     
   43.5
       832x624        74.6
       800x600        85.1     72.2     75.0     60.3     56.2
       848x480        60.0
       640x480        85.0     75.0     72.8     72.8     66.7     60.0     
   59.9
       720x400        85.0     87.8     70.1
       640x400        85.1
       640x350        85.1
       320x200       165.1
  
   And on 3.4-rc4+ (with your patch cherry-picked):
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
    VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
   0mm x 0mm
       1024x768       60.0*
       800x600        60.3     56.2
       848x480        60.0
       640x480        59.9
       320x200       165.1
  
   Running xrandr on 3.4-rc4+ also causes the screen to go black for a
   second when it does not on 3.2.15.  It also causes several messages of
   the form
  
    [drm] nouveau :01:00.0: Load detected on output B
  
   to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
   that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
   to work OK when the KVM is not involved.
  
  Were you ever able to fetch a EDID with the KVM involved?  KVMs are
  notorious for not connecting the ddc pins.
 
 Yes, it works on 3.2.15 as described above.

I have the same (or similar) KVM (not in the office at the moment) and I
can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
if EDED retrieval succeeds or if it fails with:

Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208

Earlier kernels were able to retrieve EDEDs reliably.

This is with:

[1.678392] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x086b00a2)

Thanks.

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

Re: Linux 3.4-rc4

[Maarten Maathuis]

On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
 On 2012-04-28 02:19 -0400, Alex Deucher wrote:
  On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com 
  wrote:
   Hi Ben,
  
   On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
   Does this patch help you at all?
  
   http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
  
   Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
   this appears to solve the black screen on VGA problem described in the
   original report.  Thanks!
  
   Unfortunately, that's not the end of my VGA-related regressions. :(
  
   While tracking down the black screen issue, I've been having the monitor
   directly connected to the video card the whole time, but now when I'm
   connected through my KVM switch (an IOGear GCS1804), it appears that
   something's going wrong with reading the EDID, because the available
   modes are all screwed up (both console and X decide they want to drive
   the display at 1024x768).  Here's the output of xrandr on 3.2.15:
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
    VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y 
   axis) 352mm x 264mm
       1600x1200      75.0*+   70.0     65.0     60.0
       1280x1024      85.0 +   75.0     60.0
       1920x1440      60.0
       1856x1392      60.0
       1792x1344      60.0
       1920x1200      74.9     59.9
       1680x1050      84.9     74.9     60.0
       1400x1050      85.0     74.9     60.0
       1440x900       84.8     75.0     59.9
       1280x960       85.0     60.0
       1360x768       60.0
       1280x800       84.9     74.9     59.8
       1152x864       75.0
       1280x768       84.8     74.9     59.9
       1024x768       85.0     75.1     75.0     70.1     60.0     43.5     
   43.5
       832x624        74.6
       800x600        85.1     72.2     75.0     60.3     56.2
       848x480        60.0
       640x480        85.0     75.0     72.8     72.8     66.7     60.0     
   59.9
       720x400        85.0     87.8     70.1
       640x400        85.1
       640x350        85.1
       320x200       165.1
  
   And on 3.4-rc4+ (with your patch cherry-picked):
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
    VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
   0mm x 0mm
       1024x768       60.0*
       800x600        60.3     56.2
       848x480        60.0
       640x480        59.9
       320x200       165.1
  
   Running xrandr on 3.4-rc4+ also causes the screen to go black for a
   second when it does not on 3.2.15.  It also causes several messages of
   the form
  
    [drm] nouveau :01:00.0: Load detected on output B
  
   to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
   that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
   to work OK when the KVM is not involved.
 
  Were you ever able to fetch a EDID with the KVM involved?  KVMs are
  notorious for not connecting the ddc pins.

 Yes, it works on 3.2.15 as described above.

 I have the same (or similar) KVM (not in the office at the moment) and I
 can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
 if EDED retrieval succeeds or if it fails with:

 Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208

 Earlier kernels were able to retrieve EDEDs reliably.

 This is with:

 [    1.678392] [drm] nouveau :01:00.0: Detected an NV50 generation card 
 (0x086b00a2)

 Thanks.

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


Just a crazy thought, 

Re: Linux 3.4-rc4

[Luca Tettamanti]

On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis madman2...@gmail.com wrote:
 On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:
 On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
 On 2012-04-28 02:19 -0400, Alex Deucher wrote:
  On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com 
  wrote:
   Hi Ben,
  
   On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
   Does this patch help you at all?
  
   http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
  
   Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
   this appears to solve the black screen on VGA problem described in the
   original report.  Thanks!
  
   Unfortunately, that's not the end of my VGA-related regressions. :(
  
   While tracking down the black screen issue, I've been having the monitor
   directly connected to the video card the whole time, but now when I'm
   connected through my KVM switch (an IOGear GCS1804), it appears that
   something's going wrong with reading the EDID, because the available
   modes are all screwed up (both console and X decide they want to drive
   the display at 1024x768).  Here's the output of xrandr on 3.2.15:
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
    VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y 
   axis) 352mm x 264mm
       1600x1200      75.0*+   70.0     65.0     60.0
       1280x1024      85.0 +   75.0     60.0
       1920x1440      60.0
       1856x1392      60.0
       1792x1344      60.0
       1920x1200      74.9     59.9
       1680x1050      84.9     74.9     60.0
       1400x1050      85.0     74.9     60.0
       1440x900       84.8     75.0     59.9
       1280x960       85.0     60.0
       1360x768       60.0
       1280x800       84.9     74.9     59.8
       1152x864       75.0
       1280x768       84.8     74.9     59.9
       1024x768       85.0     75.1     75.0     70.1     60.0     43.5    
43.5
       832x624        74.6
       800x600        85.1     72.2     75.0     60.3     56.2
       848x480        60.0
       640x480        85.0     75.0     72.8     72.8     66.7     60.0    
59.9
       720x400        85.0     87.8     70.1
       640x400        85.1
       640x350        85.1
       320x200       165.1
  
   And on 3.4-rc4+ (with your patch cherry-picked):
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
    VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y 
   axis) 0mm x 0mm
       1024x768       60.0*
       800x600        60.3     56.2
       848x480        60.0
       640x480        59.9
       320x200       165.1
  
   Running xrandr on 3.4-rc4+ also causes the screen to go black for a
   second when it does not on 3.2.15.  It also causes several messages of
   the form
  
    [drm] nouveau :01:00.0: Load detected on output B
  
   to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
   that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
   to work OK when the KVM is not involved.
 
  Were you ever able to fetch a EDID with the KVM involved?  KVMs are
  notorious for not connecting the ddc pins.

 Yes, it works on 3.2.15 as described above.

 I have the same (or similar) KVM (not in the office at the moment) and I
 can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
 if EDED retrieval succeeds or if it fails with:

 Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208

 Earlier kernels were able to retrieve EDEDs reliably.

 This is with:

 [    1.678392] [drm] nouveau :01:00.0: Detected an NV50 generation card 
 (0x086b00a2)

 Just a crazy thought, but didn't we change some timings related to
 EDID retrieval? To make it faster.

Hum, this commit:

Linux 3.4-rc4

[Dmitry Torokhov]

On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  
> > wrote:
> > > Hi Ben,
> > >
> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
> > >> Does this patch help you at all?
> > >>
> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
> > >
> > > Yes. ?I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
> > > this appears to solve the "black screen on VGA" problem described in the
> > > original report. ?Thanks!
> > >
> > > Unfortunately, that's not the end of my VGA-related regressions. :(
> > >
> > > While tracking down the black screen issue, I've been having the monitor
> > > directly connected to the video card the whole time, but now when I'm
> > > connected through my KVM switch (an IOGear GCS1804), it appears that
> > > something's going wrong with reading the EDID, because the available
> > > modes are all screwed up (both console and X decide they want to drive
> > > the display at 1024x768). ?Here's the output of xrandr on 3.2.15:
> > >
> > > ?% xrandr
> > > ?Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
> > > ?VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
> > > 352mm x 264mm
> > > ? ? 1600x1200 ? ? ?75.0*+ ? 70.0 ? ? 65.0 ? ? 60.0
> > > ? ? 1280x1024 ? ? ?85.0 + ? 75.0 ? ? 60.0
> > > ? ? 1920x1440 ? ? ?60.0
> > > ? ? 1856x1392 ? ? ?60.0
> > > ? ? 1792x1344 ? ? ?60.0
> > > ? ? 1920x1200 ? ? ?74.9 ? ? 59.9
> > > ? ? 1680x1050 ? ? ?84.9 ? ? 74.9 ? ? 60.0
> > > ? ? 1400x1050 ? ? ?85.0 ? ? 74.9 ? ? 60.0
> > > ? ? 1440x900 ? ? ? 84.8 ? ? 75.0 ? ? 59.9
> > > ? ? 1280x960 ? ? ? 85.0 ? ? 60.0
> > > ? ? 1360x768 ? ? ? 60.0
> > > ? ? 1280x800 ? ? ? 84.9 ? ? 74.9 ? ? 59.8
> > > ? ? 1152x864 ? ? ? 75.0
> > > ? ? 1280x768 ? ? ? 84.8 ? ? 74.9 ? ? 59.9
> > > ? ? 1024x768 ? ? ? 85.0 ? ? 75.1 ? ? 75.0 ? ? 70.1 ? ? 60.0 ? ? 43.5 ? ? 
> > > 43.5
> > > ? ? 832x624 ? ? ? ?74.6
> > > ? ? 800x600 ? ? ? ?85.1 ? ? 72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
> > > ? ? 848x480 ? ? ? ?60.0
> > > ? ? 640x480 ? ? ? ?85.0 ? ? 75.0 ? ? 72.8 ? ? 72.8 ? ? 66.7 ? ? 60.0 ? ? 
> > > 59.9
> > > ? ? 720x400 ? ? ? ?85.0 ? ? 87.8 ? ? 70.1
> > > ? ? 640x400 ? ? ? ?85.1
> > > ? ? 640x350 ? ? ? ?85.1
> > > ? ? 320x200 ? ? ? 165.1
> > >
> > > And on 3.4-rc4+ (with your patch cherry-picked):
> > >
> > > ?% xrandr
> > > ?Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> > > ?VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
> > > 0mm x 0mm
> > > ? ? 1024x768 ? ? ? 60.0*
> > > ? ? 800x600 ? ? ? ?60.3 ? ? 56.2
> > > ? ? 848x480 ? ? ? ?60.0
> > > ? ? 640x480 ? ? ? ?59.9
> > > ? ? 320x200 ? ? ? 165.1
> > >
> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
> > > second when it does not on 3.2.15. ?It also causes several messages of
> > > the form
> > >
> > > ?[drm] nouveau :01:00.0: Load detected on output B
> > >
> > > to be logged. ?Also, looking at /sys/class/drm/card0-VGA-1/edid I see
> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
> > > to work OK when the KVM is not involved.
> > 
> > Were you ever able to fetch a EDID with the KVM involved?  KVMs are
> > notorious for not connecting the ddc pins.
> 
> Yes, it works on 3.2.15 as described above.

I have the same (or similar) KVM (not in the office at the moment) and I
can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
if EDED retrieval succeeds or if it fails with:

Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208
Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
*ERROR* EDID checksum is invalid, remainder is 208

Earlier kernels were able to retrieve EDEDs reliably.

This is with:

[1.678392] [drm] nouveau :01:00.0: Detected an NV50 generation card 
(0x086b00a2)

Thanks.

-- 
Dmitry

Linux 3.4-rc4

[Nick Bowler]

On 2012-04-28 02:19 -0400, Alex Deucher wrote:
> On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  
> wrote:
> > Hi Ben,
> >
> > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
> >> Does this patch help you at all?
> >>
> >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
> >
> > Yes. ?I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
> > this appears to solve the "black screen on VGA" problem described in the
> > original report. ?Thanks!
> >
> > Unfortunately, that's not the end of my VGA-related regressions. :(
> >
> > While tracking down the black screen issue, I've been having the monitor
> > directly connected to the video card the whole time, but now when I'm
> > connected through my KVM switch (an IOGear GCS1804), it appears that
> > something's going wrong with reading the EDID, because the available
> > modes are all screwed up (both console and X decide they want to drive
> > the display at 1024x768). ?Here's the output of xrandr on 3.2.15:
> >
> > ?% xrandr
> > ?Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
> > ?VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
> > 352mm x 264mm
> > ? ? 1600x1200 ? ? ?75.0*+ ? 70.0 ? ? 65.0 ? ? 60.0
> > ? ? 1280x1024 ? ? ?85.0 + ? 75.0 ? ? 60.0
> > ? ? 1920x1440 ? ? ?60.0
> > ? ? 1856x1392 ? ? ?60.0
> > ? ? 1792x1344 ? ? ?60.0
> > ? ? 1920x1200 ? ? ?74.9 ? ? 59.9
> > ? ? 1680x1050 ? ? ?84.9 ? ? 74.9 ? ? 60.0
> > ? ? 1400x1050 ? ? ?85.0 ? ? 74.9 ? ? 60.0
> > ? ? 1440x900 ? ? ? 84.8 ? ? 75.0 ? ? 59.9
> > ? ? 1280x960 ? ? ? 85.0 ? ? 60.0
> > ? ? 1360x768 ? ? ? 60.0
> > ? ? 1280x800 ? ? ? 84.9 ? ? 74.9 ? ? 59.8
> > ? ? 1152x864 ? ? ? 75.0
> > ? ? 1280x768 ? ? ? 84.8 ? ? 74.9 ? ? 59.9
> > ? ? 1024x768 ? ? ? 85.0 ? ? 75.1 ? ? 75.0 ? ? 70.1 ? ? 60.0 ? ? 43.5 ? ? 
> > 43.5
> > ? ? 832x624 ? ? ? ?74.6
> > ? ? 800x600 ? ? ? ?85.1 ? ? 72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
> > ? ? 848x480 ? ? ? ?60.0
> > ? ? 640x480 ? ? ? ?85.0 ? ? 75.0 ? ? 72.8 ? ? 72.8 ? ? 66.7 ? ? 60.0 ? ? 
> > 59.9
> > ? ? 720x400 ? ? ? ?85.0 ? ? 87.8 ? ? 70.1
> > ? ? 640x400 ? ? ? ?85.1
> > ? ? 640x350 ? ? ? ?85.1
> > ? ? 320x200 ? ? ? 165.1
> >
> > And on 3.4-rc4+ (with your patch cherry-picked):
> >
> > ?% xrandr
> > ?Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> > ?VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
> > 0mm x 0mm
> > ? ? 1024x768 ? ? ? 60.0*
> > ? ? 800x600 ? ? ? ?60.3 ? ? 56.2
> > ? ? 848x480 ? ? ? ?60.0
> > ? ? 640x480 ? ? ? ?59.9
> > ? ? 320x200 ? ? ? 165.1
> >
> > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
> > second when it does not on 3.2.15. ?It also causes several messages of
> > the form
> >
> > ?[drm] nouveau :01:00.0: Load detected on output B
> >
> > to be logged. ?Also, looking at /sys/class/drm/card0-VGA-1/edid I see
> > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
> > to work OK when the KVM is not involved.
> 
> Were you ever able to fetch a EDID with the KVM involved?  KVMs are
> notorious for not connecting the ddc pins.

Yes, it works on 3.2.15 as described above.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Alex Deucher]

On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  
wrote:
> Hi Ben,
>
> On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>> Does this patch help you at all?
>>
>> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>
> Yes. ?I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
> this appears to solve the "black screen on VGA" problem described in the
> original report. ?Thanks!
>
> Unfortunately, that's not the end of my VGA-related regressions. :(
>
> While tracking down the black screen issue, I've been having the monitor
> directly connected to the video card the whole time, but now when I'm
> connected through my KVM switch (an IOGear GCS1804), it appears that
> something's going wrong with reading the EDID, because the available
> modes are all screwed up (both console and X decide they want to drive
> the display at 1024x768). ?Here's the output of xrandr on 3.2.15:
>
> ?% xrandr
> ?Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
> ?VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
> 352mm x 264mm
> ? ? 1600x1200 ? ? ?75.0*+ ? 70.0 ? ? 65.0 ? ? 60.0
> ? ? 1280x1024 ? ? ?85.0 + ? 75.0 ? ? 60.0
> ? ? 1920x1440 ? ? ?60.0
> ? ? 1856x1392 ? ? ?60.0
> ? ? 1792x1344 ? ? ?60.0
> ? ? 1920x1200 ? ? ?74.9 ? ? 59.9
> ? ? 1680x1050 ? ? ?84.9 ? ? 74.9 ? ? 60.0
> ? ? 1400x1050 ? ? ?85.0 ? ? 74.9 ? ? 60.0
> ? ? 1440x900 ? ? ? 84.8 ? ? 75.0 ? ? 59.9
> ? ? 1280x960 ? ? ? 85.0 ? ? 60.0
> ? ? 1360x768 ? ? ? 60.0
> ? ? 1280x800 ? ? ? 84.9 ? ? 74.9 ? ? 59.8
> ? ? 1152x864 ? ? ? 75.0
> ? ? 1280x768 ? ? ? 84.8 ? ? 74.9 ? ? 59.9
> ? ? 1024x768 ? ? ? 85.0 ? ? 75.1 ? ? 75.0 ? ? 70.1 ? ? 60.0 ? ? 43.5 ? ? 43.5
> ? ? 832x624 ? ? ? ?74.6
> ? ? 800x600 ? ? ? ?85.1 ? ? 72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
> ? ? 848x480 ? ? ? ?60.0
> ? ? 640x480 ? ? ? ?85.0 ? ? 75.0 ? ? 72.8 ? ? 72.8 ? ? 66.7 ? ? 60.0 ? ? 59.9
> ? ? 720x400 ? ? ? ?85.0 ? ? 87.8 ? ? 70.1
> ? ? 640x400 ? ? ? ?85.1
> ? ? 640x350 ? ? ? ?85.1
> ? ? 320x200 ? ? ? 165.1
>
> And on 3.4-rc4+ (with your patch cherry-picked):
>
> ?% xrandr
> ?Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
> ?VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm 
> x 0mm
> ? ? 1024x768 ? ? ? 60.0*
> ? ? 800x600 ? ? ? ?60.3 ? ? 56.2
> ? ? 848x480 ? ? ? ?60.0
> ? ? 640x480 ? ? ? ?59.9
> ? ? 320x200 ? ? ? 165.1
>
> Running xrandr on 3.4-rc4+ also causes the screen to go black for a
> second when it does not on 3.2.15. ?It also causes several messages of
> the form
>
> ?[drm] nouveau :01:00.0: Load detected on output B
>
> to be logged. ?Also, looking at /sys/class/drm/card0-VGA-1/edid I see
> that it is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
> to work OK when the KVM is not involved.

Were you ever able to fetch a EDID with the KVM involved?  KVMs are
notorious for not connecting the ddc pins.

Alex

Re: Linux 3.4-rc4

[Alex Deucher]

On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com wrote:
 Hi Ben,

 On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
 Does this patch help you at all?

 http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305

 Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
 this appears to solve the black screen on VGA problem described in the
 original report.  Thanks!

 Unfortunately, that's not the end of my VGA-related regressions. :(

 While tracking down the black screen issue, I've been having the monitor
 directly connected to the video card the whole time, but now when I'm
 connected through my KVM switch (an IOGear GCS1804), it appears that
 something's going wrong with reading the EDID, because the available
 modes are all screwed up (both console and X decide they want to drive
 the display at 1024x768).  Here's the output of xrandr on 3.2.15:

  % xrandr
  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
  VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
 352mm x 264mm
     1600x1200      75.0*+   70.0     65.0     60.0
     1280x1024      85.0 +   75.0     60.0
     1920x1440      60.0
     1856x1392      60.0
     1792x1344      60.0
     1920x1200      74.9     59.9
     1680x1050      84.9     74.9     60.0
     1400x1050      85.0     74.9     60.0
     1440x900       84.8     75.0     59.9
     1280x960       85.0     60.0
     1360x768       60.0
     1280x800       84.9     74.9     59.8
     1152x864       75.0
     1280x768       84.8     74.9     59.9
     1024x768       85.0     75.1     75.0     70.1     60.0     43.5     43.5
     832x624        74.6
     800x600        85.1     72.2     75.0     60.3     56.2
     848x480        60.0
     640x480        85.0     75.0     72.8     72.8     66.7     60.0     59.9
     720x400        85.0     87.8     70.1
     640x400        85.1
     640x350        85.1
     320x200       165.1

 And on 3.4-rc4+ (with your patch cherry-picked):

  % xrandr
  Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
  VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm 
 x 0mm
     1024x768       60.0*
     800x600        60.3     56.2
     848x480        60.0
     640x480        59.9
     320x200       165.1

 Running xrandr on 3.4-rc4+ also causes the screen to go black for a
 second when it does not on 3.2.15.  It also causes several messages of
 the form

  [drm] nouveau :01:00.0: Load detected on output B

 to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
 that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
 to work OK when the KVM is not involved.

Were you ever able to fetch a EDID with the KVM involved?  KVMs are
notorious for not connecting the ddc pins.

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

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-28 02:19 -0400, Alex Deucher wrote:
 On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com wrote:
  Hi Ben,
 
  On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
  Does this patch help you at all?
 
  http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
 
  Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
  this appears to solve the black screen on VGA problem described in the
  original report.  Thanks!
 
  Unfortunately, that's not the end of my VGA-related regressions. :(
 
  While tracking down the black screen issue, I've been having the monitor
  directly connected to the video card the whole time, but now when I'm
  connected through my KVM switch (an IOGear GCS1804), it appears that
  something's going wrong with reading the EDID, because the available
  modes are all screwed up (both console and X decide they want to drive
  the display at 1024x768).  Here's the output of xrandr on 3.2.15:
 
   % xrandr
   Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
   VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
  352mm x 264mm
      1600x1200      75.0*+   70.0     65.0     60.0
      1280x1024      85.0 +   75.0     60.0
      1920x1440      60.0
      1856x1392      60.0
      1792x1344      60.0
      1920x1200      74.9     59.9
      1680x1050      84.9     74.9     60.0
      1400x1050      85.0     74.9     60.0
      1440x900       84.8     75.0     59.9
      1280x960       85.0     60.0
      1360x768       60.0
      1280x800       84.9     74.9     59.8
      1152x864       75.0
      1280x768       84.8     74.9     59.9
      1024x768       85.0     75.1     75.0     70.1     60.0     43.5     
  43.5
      832x624        74.6
      800x600        85.1     72.2     75.0     60.3     56.2
      848x480        60.0
      640x480        85.0     75.0     72.8     72.8     66.7     60.0     
  59.9
      720x400        85.0     87.8     70.1
      640x400        85.1
      640x350        85.1
      320x200       165.1
 
  And on 3.4-rc4+ (with your patch cherry-picked):
 
   % xrandr
   Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
   VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
  0mm x 0mm
      1024x768       60.0*
      800x600        60.3     56.2
      848x480        60.0
      640x480        59.9
      320x200       165.1
 
  Running xrandr on 3.4-rc4+ also causes the screen to go black for a
  second when it does not on 3.2.15.  It also causes several messages of
  the form
 
   [drm] nouveau :01:00.0: Load detected on output B
 
  to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
  that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
  to work OK when the KVM is not involved.
 
 Were you ever able to fetch a EDID with the KVM involved?  KVMs are
 notorious for not connecting the ddc pins.

Yes, it works on 3.2.15 as described above.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Linux 3.4-rc4

[Nick Bowler]

Hi Ben,

On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
> Does this patch help you at all?
> 
> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305

Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
this appears to solve the "black screen on VGA" problem described in the
original report.  Thanks!

Unfortunately, that's not the end of my VGA-related regressions. :(

While tracking down the black screen issue, I've been having the monitor
directly connected to the video card the whole time, but now when I'm
connected through my KVM switch (an IOGear GCS1804), it appears that
something's going wrong with reading the EDID, because the available
modes are all screwed up (both console and X decide they want to drive
the display at 1024x768).  Here's the output of xrandr on 3.2.15:

  % xrandr
  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
  VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
352mm x 264mm
 1600x1200  75.0*+   70.0 65.0 60.0
 1280x1024  85.0 +   75.0 60.0
 1920x1440  60.0
 1856x1392  60.0
 1792x1344  60.0
 1920x1200  74.9 59.9
 1680x1050  84.9 74.9 60.0
 1400x1050  85.0 74.9 60.0
 1440x900   84.8 75.0 59.9
 1280x960   85.0 60.0
 1360x768   60.0
 1280x800   84.9 74.9 59.8
 1152x864   75.0
 1280x768   84.8 74.9 59.9
 1024x768   85.0 75.1 75.0 70.1 60.0 43.5 43.5
 832x62474.6
 800x60085.1 72.2 75.0 60.3 56.2
 848x48060.0
 640x48085.0 75.0 72.8 72.8 66.7 60.0 59.9
 720x40085.0 87.8 70.1
 640x40085.1
 640x35085.1
 320x200   165.1

And on 3.4-rc4+ (with your patch cherry-picked):

  % xrandr
  Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
  VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
 1024x768   60.0*
 800x60060.3 56.2
 848x48060.0
 640x48059.9
 320x200   165.1

Running xrandr on 3.4-rc4+ also causes the screen to go black for a
second when it does not on 3.2.15.  It also causes several messages of
the form

  [drm] nouveau :01:00.0: Load detected on output B

to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
to work OK when the KVM is not involved.

This is probably caused by a different commit than the black screen
because I also saw this problem on the 3.3.3+reverts kernel; I just
haven't noticed it until now because, well, the VGA wasn't working at
all until now.

Anyway, I can try to track down what causes this one next week...

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-04-25 at 12:56 +1000, Ben Skeggs wrote:
> On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
> > On 2012-04-23 21:03 -0400, Nick Bowler wrote:
> > > On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > > > Following up on the above, the commit which introduces the panics 
> > > > > during
> > > > > boot is this one:
> > > > >
> > > > > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > > > > Author: Jerome Glisse 
> > > > > Date:   Wed Nov 9 17:15:26 2011 -0500
> > > > > 
> > > > > drm/ttm: isolate dma data from ttm_tt V4
> > [...]
> > > > dea7e0a ttm: fix agp since ttm tt rework
> > > > 
> > > > fixed that.
> > > 
> > > Yes, I just tested this commit and the one immediately before it.  The
> > > one before crashes in the usual way, and dea7e0a boots (with the VGA
> > > output black as in the original report).  So this fixed the crash.
> > 
> > OK, here's what I did:
> > 
> >  - Since dea7e0a is the first commit that both (a) boots and (b) has
> >broken VGA, I checked it out on a new branch:
> > 
> >  git checkout -b crazy dea7e0a
> > 
> >  - Next, I reverted *all* (well, I missed one by accident) the remaining
> >nouveau-specific commits between 3230cfc34 ("drm/nouveau: enable the
> >ttm dma pool when swiotlb is active V3") (i.e., the last commit that
> >(a) boots and (b) has non-broken VGA) and dea7e0a:
> > 
> >  git revert --no-edit 0c101461e267..f7b24c42da1a
> > 
> >  - Amazingly, the resulting kernel booted and had working VGA, so I did
> >a "backwards" bisect on this branch of reverts.  In a strange twist
> >of fate, this actually managed to produce bootable kernels the entire
> >time.  The bisection pinpointed the following commit as the culprit:
> > 
> > commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
> > Author: Ben Skeggs 
> > Date:   Mon Nov 21 16:41:48 2011 +1000
> > 
> > drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of 
> > issues
> > 
> > - moves out of nouveau_bios.c and demagics the logical state definitions
> > - simplifies chipset-specific driver interface
> > - makes most of gpio irq handling common, will use for nv4x hpd later
> > - api extended to allow both direct gpio access, and access using the
> >   logical function states
> > - api extended to allow for future use of gpio extender chips
> > - pre-nv50 was handled very badly, the main issue being that all GPIOs
> >   were being treated as output-only.
> > - fixes nvd0 so gpio changes actually stick, magic reg needs bashing
> > 
> > Signed-off-by: Ben Skeggs 
> Excellent!  That makes things possible.
> 
> Are you able to mount debugfs, and email /debugfs/dri/0/vbios.rom for me
> (privately if you wish) and I'll attempt to track down what broke for
> you.
Does this patch help you at all?

http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305

Cheers,
Ben.
> 
> Thanks!
> Ben.
> 
> > 
> > Unfortunately, there are a number of seemingly non-trivial conflicts
> > trying to revert just this one gigantic commit.  So to avoid any
> > conflicts, I reverted all of the following (in this order) on top of
> > 3.3.3 (there are even more conflicts trying to revert on top of Linus'
> > master):
> > 
> >   7df898b1a70b ("drm/nouveau/disp: check that panel power gpio is enabled 
> > at init time")
> >   52c4d767437b ("drm/nouveau: move hpd enable/disable to common code")
> >   47e5d5cb83d4 ("drm/nv40/disp: implement support for hotplug irq")
> >   a0b25635515e ("drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a 
> > number of issues")
> > 
> > and my VGA is working again!
> > 
> > Cheers,
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Nick Bowler]

Hi Ben,

On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
 Does this patch help you at all?
 
 http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305

Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
this appears to solve the black screen on VGA problem described in the
original report.  Thanks!

Unfortunately, that's not the end of my VGA-related regressions. :(

While tracking down the black screen issue, I've been having the monitor
directly connected to the video card the whole time, but now when I'm
connected through my KVM switch (an IOGear GCS1804), it appears that
something's going wrong with reading the EDID, because the available
modes are all screwed up (both console and X decide they want to drive
the display at 1024x768).  Here's the output of xrandr on 3.2.15:

  % xrandr
  Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
  VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 
352mm x 264mm
 1600x1200  75.0*+   70.0 65.0 60.0
 1280x1024  85.0 +   75.0 60.0
 1920x1440  60.0
 1856x1392  60.0
 1792x1344  60.0
 1920x1200  74.9 59.9
 1680x1050  84.9 74.9 60.0
 1400x1050  85.0 74.9 60.0
 1440x900   84.8 75.0 59.9
 1280x960   85.0 60.0
 1360x768   60.0
 1280x800   84.9 74.9 59.8
 1152x864   75.0
 1280x768   84.8 74.9 59.9
 1024x768   85.0 75.1 75.0 70.1 60.0 43.5 43.5
 832x62474.6
 800x60085.1 72.2 75.0 60.3 56.2
 848x48060.0
 640x48085.0 75.0 72.8 72.8 66.7 60.0 59.9
 720x40085.0 87.8 70.1
 640x40085.1
 640x35085.1
 320x200   165.1

And on 3.4-rc4+ (with your patch cherry-picked):

  % xrandr
  Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
  VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
 1024x768   60.0*
 800x60060.3 56.2
 848x48060.0
 640x48059.9
 320x200   165.1

Running xrandr on 3.4-rc4+ also causes the screen to go black for a
second when it does not on 3.2.15.  It also causes several messages of
the form

  [drm] nouveau :01:00.0: Load detected on output B

to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
to work OK when the KVM is not involved.

This is probably caused by a different commit than the black screen
because I also saw this problem on the 3.3.3+reverts kernel; I just
haven't noticed it until now because, well, the VGA wasn't working at
all until now.

Anyway, I can try to track down what causes this one next week...

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

[Ben Skeggs]

On Wed, 2012-04-25 at 12:56 +1000, Ben Skeggs wrote:
 On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
  On 2012-04-23 21:03 -0400, Nick Bowler wrote:
   On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
 Following up on the above, the commit which introduces the panics 
 during
 boot is this one:

 commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
 Author: Jerome Glisse jgli...@redhat.com
 Date:   Wed Nov 9 17:15:26 2011 -0500
 
 drm/ttm: isolate dma data from ttm_tt V4
  [...]
dea7e0a ttm: fix agp since ttm tt rework

fixed that.
   
   Yes, I just tested this commit and the one immediately before it.  The
   one before crashes in the usual way, and dea7e0a boots (with the VGA
   output black as in the original report).  So this fixed the crash.
  
  OK, here's what I did:
  
   - Since dea7e0a is the first commit that both (a) boots and (b) has
 broken VGA, I checked it out on a new branch:
  
   git checkout -b crazy dea7e0a
  
   - Next, I reverted *all* (well, I missed one by accident) the remaining
 nouveau-specific commits between 3230cfc34 (drm/nouveau: enable the
 ttm dma pool when swiotlb is active V3) (i.e., the last commit that
 (a) boots and (b) has non-broken VGA) and dea7e0a:
  
   git revert --no-edit 0c101461e267..f7b24c42da1a
  
   - Amazingly, the resulting kernel booted and had working VGA, so I did
 a backwards bisect on this branch of reverts.  In a strange twist
 of fate, this actually managed to produce bootable kernels the entire
 time.  The bisection pinpointed the following commit as the culprit:
  
  commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
  Author: Ben Skeggs bske...@redhat.com
  Date:   Mon Nov 21 16:41:48 2011 +1000
  
  drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of 
  issues
  
  - moves out of nouveau_bios.c and demagics the logical state definitions
  - simplifies chipset-specific driver interface
  - makes most of gpio irq handling common, will use for nv4x hpd later
  - api extended to allow both direct gpio access, and access using the
logical function states
  - api extended to allow for future use of gpio extender chips
  - pre-nv50 was handled very badly, the main issue being that all GPIOs
were being treated as output-only.
  - fixes nvd0 so gpio changes actually stick, magic reg needs bashing
  
  Signed-off-by: Ben Skeggs bske...@redhat.com
 Excellent!  That makes things possible.
 
 Are you able to mount debugfs, and email /debugfs/dri/0/vbios.rom for me
 (privately if you wish) and I'll attempt to track down what broke for
 you.
Does this patch help you at all?

http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305

Cheers,
Ben.
 
 Thanks!
 Ben.
 
  
  Unfortunately, there are a number of seemingly non-trivial conflicts
  trying to revert just this one gigantic commit.  So to avoid any
  conflicts, I reverted all of the following (in this order) on top of
  3.3.3 (there are even more conflicts trying to revert on top of Linus'
  master):
  
7df898b1a70b (drm/nouveau/disp: check that panel power gpio is enabled 
  at init time)
52c4d767437b (drm/nouveau: move hpd enable/disable to common code)
47e5d5cb83d4 (drm/nv40/disp: implement support for hotplug irq)
a0b25635515e (drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a 
  number of issues)
  
  and my VGA is working again!
  
  Cheers,
 
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Linux 3.4-rc4

[Konrad Rzeszutek Wilk]

On Mon, Apr 23, 2012 at 09:03:45PM -0400, Nick Bowler wrote:
> On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> > On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > > Following up on the above, the commit which introduces the panics during
> > > boot is this one:
> > >
> > > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > > Author: Jerome Glisse 
> > > Date:   Wed Nov 9 17:15:26 2011 -0500
> > > 
> > > drm/ttm: isolate dma data from ttm_tt V4
> > 
> > I think
> > 
> > dea7e0a ttm: fix agp since ttm tt rework
> > 
> > fixed that.
> 
> Yes, I just tested this commit and the one immediately before it.  The
> one before crashes in the usual way, and dea7e0a boots (with the VGA
> output black as in the original report).  So this fixed the crash.
> 
> Now, returning to the original bisection, I marked that commit as "bad"
> and dropped all the earlier "skip" markings.  Git asks me to test commit
> 2a44e4997c5f ("drm/nouveau/disp: introduce proper init/fini, separate
> from create/destroy").  I cherry picked the aforementioned ttm fix:
> 
>   git cherry-pick -n dea7e0a
> 
> which succeeded.  Howevew, the resulting kernel still crashes early,
> although now in a different way.  I just can't win :(

Perhaps there is a better way. You could do this:

git log --oneline -r v3.2..v3.3 drivers/gpu/drm/nouveau

to get an idea of the set of patches that went in. And use that, so

git bisect start -- drivers/gpu/drm/nouveau [this should only do the bisection 
on those patches]

git bisect good v3.2
git bisect bad v3.3

And keep in mind the dea7e0a might need to be stuck on some of these.

This _should_ limit the bisection to just the nouveau changes, I hope.

Re: Linux 3.4-rc4

[Konrad Rzeszutek Wilk]

On Mon, Apr 23, 2012 at 09:03:45PM -0400, Nick Bowler wrote:
 On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
  On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
   Following up on the above, the commit which introduces the panics during
   boot is this one:
  
   commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
   Author: Jerome Glisse jgli...@redhat.com
   Date:   Wed Nov 9 17:15:26 2011 -0500
   
   drm/ttm: isolate dma data from ttm_tt V4
  
  I think
  
  dea7e0a ttm: fix agp since ttm tt rework
  
  fixed that.
 
 Yes, I just tested this commit and the one immediately before it.  The
 one before crashes in the usual way, and dea7e0a boots (with the VGA
 output black as in the original report).  So this fixed the crash.
 
 Now, returning to the original bisection, I marked that commit as bad
 and dropped all the earlier skip markings.  Git asks me to test commit
 2a44e4997c5f (drm/nouveau/disp: introduce proper init/fini, separate
 from create/destroy).  I cherry picked the aforementioned ttm fix:
 
   git cherry-pick -n dea7e0a
 
 which succeeded.  Howevew, the resulting kernel still crashes early,
 although now in a different way.  I just can't win :(

Perhaps there is a better way. You could do this:

git log --oneline -r v3.2..v3.3 drivers/gpu/drm/nouveau

to get an idea of the set of patches that went in. And use that, so

git bisect start -- drivers/gpu/drm/nouveau [this should only do the bisection 
on those patches]

git bisect good v3.2
git bisect bad v3.3

And keep in mind the dea7e0a might need to be stuck on some of these.

This _should_ limit the bisection to just the nouveau changes, I hope.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-23 21:03 -0400, Nick Bowler wrote:
 On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
  On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
   Following up on the above, the commit which introduces the panics during
   boot is this one:
  
   commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
   Author: Jerome Glisse jgli...@redhat.com
   Date:   Wed Nov 9 17:15:26 2011 -0500
   
   drm/ttm: isolate dma data from ttm_tt V4
[...]
  dea7e0a ttm: fix agp since ttm tt rework
  
  fixed that.
 
 Yes, I just tested this commit and the one immediately before it.  The
 one before crashes in the usual way, and dea7e0a boots (with the VGA
 output black as in the original report).  So this fixed the crash.

OK, here's what I did:

 - Since dea7e0a is the first commit that both (a) boots and (b) has
   broken VGA, I checked it out on a new branch:

 git checkout -b crazy dea7e0a

 - Next, I reverted *all* (well, I missed one by accident) the remaining
   nouveau-specific commits between 3230cfc34 (drm/nouveau: enable the
   ttm dma pool when swiotlb is active V3) (i.e., the last commit that
   (a) boots and (b) has non-broken VGA) and dea7e0a:

 git revert --no-edit 0c101461e267..f7b24c42da1a

 - Amazingly, the resulting kernel booted and had working VGA, so I did
   a backwards bisect on this branch of reverts.  In a strange twist
   of fate, this actually managed to produce bootable kernels the entire
   time.  The bisection pinpointed the following commit as the culprit:

commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
Author: Ben Skeggs bske...@redhat.com
Date:   Mon Nov 21 16:41:48 2011 +1000

drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues

- moves out of nouveau_bios.c and demagics the logical state definitions
- simplifies chipset-specific driver interface
- makes most of gpio irq handling common, will use for nv4x hpd later
- api extended to allow both direct gpio access, and access using the
  logical function states
- api extended to allow for future use of gpio extender chips
- pre-nv50 was handled very badly, the main issue being that all GPIOs
  were being treated as output-only.
- fixes nvd0 so gpio changes actually stick, magic reg needs bashing

Signed-off-by: Ben Skeggs bske...@redhat.com

Unfortunately, there are a number of seemingly non-trivial conflicts
trying to revert just this one gigantic commit.  So to avoid any
conflicts, I reverted all of the following (in this order) on top of
3.3.3 (there are even more conflicts trying to revert on top of Linus'
master):

  7df898b1a70b (drm/nouveau/disp: check that panel power gpio is enabled at 
init time)
  52c4d767437b (drm/nouveau: move hpd enable/disable to common code)
  47e5d5cb83d4 (drm/nv40/disp: implement support for hotplug irq)
  a0b25635515e (drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a 
number of issues)

and my VGA is working again!

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

[Ben Skeggs]

On Tue, 2012-04-24 at 21:35 -0400, Nick Bowler wrote:
 On 2012-04-23 21:03 -0400, Nick Bowler wrote:
  On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
   On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
Following up on the above, the commit which introduces the panics during
boot is this one:
   
commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse jgli...@redhat.com
Date:   Wed Nov 9 17:15:26 2011 -0500

drm/ttm: isolate dma data from ttm_tt V4
 [...]
   dea7e0a ttm: fix agp since ttm tt rework
   
   fixed that.
  
  Yes, I just tested this commit and the one immediately before it.  The
  one before crashes in the usual way, and dea7e0a boots (with the VGA
  output black as in the original report).  So this fixed the crash.
 
 OK, here's what I did:
 
  - Since dea7e0a is the first commit that both (a) boots and (b) has
broken VGA, I checked it out on a new branch:
 
  git checkout -b crazy dea7e0a
 
  - Next, I reverted *all* (well, I missed one by accident) the remaining
nouveau-specific commits between 3230cfc34 (drm/nouveau: enable the
ttm dma pool when swiotlb is active V3) (i.e., the last commit that
(a) boots and (b) has non-broken VGA) and dea7e0a:
 
  git revert --no-edit 0c101461e267..f7b24c42da1a
 
  - Amazingly, the resulting kernel booted and had working VGA, so I did
a backwards bisect on this branch of reverts.  In a strange twist
of fate, this actually managed to produce bootable kernels the entire
time.  The bisection pinpointed the following commit as the culprit:
 
 commit a0b25635515ef5049f93b032a1e37f18b16e0f6f
 Author: Ben Skeggs bske...@redhat.com
 Date:   Mon Nov 21 16:41:48 2011 +1000
 
 drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a number of issues
 
 - moves out of nouveau_bios.c and demagics the logical state definitions
 - simplifies chipset-specific driver interface
 - makes most of gpio irq handling common, will use for nv4x hpd later
 - api extended to allow both direct gpio access, and access using the
   logical function states
 - api extended to allow for future use of gpio extender chips
 - pre-nv50 was handled very badly, the main issue being that all GPIOs
   were being treated as output-only.
 - fixes nvd0 so gpio changes actually stick, magic reg needs bashing
 
 Signed-off-by: Ben Skeggs bske...@redhat.com
Excellent!  That makes things possible.

Are you able to mount debugfs, and email /debugfs/dri/0/vbios.rom for me
(privately if you wish) and I'll attempt to track down what broke for
you.

Thanks!
Ben.

 
 Unfortunately, there are a number of seemingly non-trivial conflicts
 trying to revert just this one gigantic commit.  So to avoid any
 conflicts, I reverted all of the following (in this order) on top of
 3.3.3 (there are even more conflicts trying to revert on top of Linus'
 master):
 
   7df898b1a70b (drm/nouveau/disp: check that panel power gpio is enabled at 
 init time)
   52c4d767437b (drm/nouveau: move hpd enable/disable to common code)
   47e5d5cb83d4 (drm/nv40/disp: implement support for hotplug irq)
   a0b25635515e (drm/nouveau/gpio: reimplement as nouveau_gpio.c, fixing a 
 number of issues)
 
 and my VGA is working again!
 
 Cheers,


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

Linux 3.4-rc4

[Nick Bowler]

On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> > Following up on the above, the commit which introduces the panics during
> > boot is this one:
> >
> > commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> > Author: Jerome Glisse 
> > Date:   Wed Nov 9 17:15:26 2011 -0500
> > 
> > drm/ttm: isolate dma data from ttm_tt V4
> 
> I think
> 
> dea7e0a ttm: fix agp since ttm tt rework
> 
> fixed that.

Yes, I just tested this commit and the one immediately before it.  The
one before crashes in the usual way, and dea7e0a boots (with the VGA
output black as in the original report).  So this fixed the crash.

Now, returning to the original bisection, I marked that commit as "bad"
and dropped all the earlier "skip" markings.  Git asks me to test commit
2a44e4997c5f ("drm/nouveau/disp: introduce proper init/fini, separate
from create/destroy").  I cherry picked the aforementioned ttm fix:

  git cherry-pick -n dea7e0a

which succeeded.  Howevew, the resulting kernel still crashes early,
although now in a different way.  I just can't win :(

Linux version 3.2.0-rc6-bisect-00190-g2a44e49-dirty (nick at artemis) (gcc 
version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #72 PREEMPT Mon Apr 23 
20:23:10 EDT 2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffc (usable)
 BIOS-e820: 7ffc - 7ffd (ACPI data)
 BIOS-e820: 7ffd - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [880ff780] ff780
init_memory_mapping: -7ffc
RAMDISK: 37c9c000 - 37ff
ACPI: RSDP 000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 7ffc0100 0003C (v01 A M I  OEMXSDT  01000618 MSFT 0097)
ACPI: FACP 7ffc0290 000F4 (v03 A M I  OEMFACP  01000618 MSFT 0097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 
0x44A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 7ffc0400 04524 (v01  A0055 A0055003 0003 INTL 02002026)
ACPI: FACS 7ffd 00040
ACPI: APIC 7ffc0390 00068 (v01 A M I  OEMAPIC  01000618 MSFT 0097)
ACPI: OEMB 7ffd0040 00041 (v01 A M I  OEMBIOS  01000618 MSFT 0097)
Zone PFN ranges:
  DMA  0x0010 -> 0x1000
  DMA320x1000 -> 0x0010
  Normal   empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x0010 -> 0x009f
0: 0x0100 -> 0x0007ffc0
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8000 (gap: 8000:7ec0)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 516939
Kernel command line: root=md:name=newroot console=ttyS0,115200n8
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
Node 0: aperture @ f800 size 64 MB
Memory: 2053596k/2096896k available (3122k kernel code, 452k absent, 42848k 
reserved, 3374k data, 496k init)
NR_IRQS:4352 nr_irqs:256 16
Extended CMOS year: 2000
Console: colour VGA+ 80x25
console [ttyS0] enabled
kmemleak: Kernel memory leak detector disabled
Fast TSC calibration using PIT
Detected 2009.519 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 
4019.03 

Linux 3.4-rc4

[Ben Skeggs]

On Sun, 2012-04-22 at 08:26 +0100, Dave Airlie wrote:
> On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
>  wrote:
> > David & co, any ideas?
> 
> I've been asking Ben about this, I might have to use a bit more pressure,
I unfortunately haven't yet had any ideas which could be useful aside
from continuing to try and narrow down the change that caused the issue.

I've been using the VGA output on a lot of different boards (including
of the same generation as the one in the original bug report) with the
latest code without an issue..

Ben.

> 
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.
> 
> Dave.
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-22 22:45 -0400, Konrad Rzeszutek Wilk wrote:
 On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
  Following up on the above, the commit which introduces the panics during
  boot is this one:
 
  commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
  Author: Jerome Glisse jgli...@redhat.com
  Date:   Wed Nov 9 17:15:26 2011 -0500
  
  drm/ttm: isolate dma data from ttm_tt V4
 
 I think
 
 dea7e0a ttm: fix agp since ttm tt rework
 
 fixed that.

Yes, I just tested this commit and the one immediately before it.  The
one before crashes in the usual way, and dea7e0a boots (with the VGA
output black as in the original report).  So this fixed the crash.

Now, returning to the original bisection, I marked that commit as bad
and dropped all the earlier skip markings.  Git asks me to test commit
2a44e4997c5f (drm/nouveau/disp: introduce proper init/fini, separate
from create/destroy).  I cherry picked the aforementioned ttm fix:

  git cherry-pick -n dea7e0a

which succeeded.  Howevew, the resulting kernel still crashes early,
although now in a different way.  I just can't win :(

Linux version 3.2.0-rc6-bisect-00190-g2a44e49-dirty (nick@artemis) (gcc version 
4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #72 PREEMPT Mon Apr 23 20:23:10 EDT 
2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffc (usable)
 BIOS-e820: 7ffc - 7ffd (ACPI data)
 BIOS-e820: 7ffd - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [880ff780] ff780
init_memory_mapping: -7ffc
RAMDISK: 37c9c000 - 37ff
ACPI: RSDP 000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 7ffc0100 0003C (v01 A M I  OEMXSDT  01000618 MSFT 0097)
ACPI: FACP 7ffc0290 000F4 (v03 A M I  OEMFACP  01000618 MSFT 0097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 
0x44A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 7ffc0400 04524 (v01  A0055 A0055003 0003 INTL 02002026)
ACPI: FACS 7ffd 00040
ACPI: APIC 7ffc0390 00068 (v01 A M I  OEMAPIC  01000618 MSFT 0097)
ACPI: OEMB 7ffd0040 00041 (v01 A M I  OEMBIOS  01000618 MSFT 0097)
Zone PFN ranges:
  DMA  0x0010 - 0x1000
  DMA320x1000 - 0x0010
  Normal   empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x0010 - 0x009f
0: 0x0100 - 0x0007ffc0
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8000 (gap: 8000:7ec0)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 516939
Kernel command line: root=md:name=newroot console=ttyS0,115200n8
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
Node 0: aperture @ f800 size 64 MB
Memory: 2053596k/2096896k available (3122k kernel code, 452k absent, 42848k 
reserved, 3374k data, 496k init)
NR_IRQS:4352 nr_irqs:256 16
Extended CMOS year: 2000
Console: colour VGA+ 80x25
console [ttyS0] enabled
kmemleak: Kernel memory leak detector disabled
Fast TSC calibration using PIT
Detected 2009.519 MHz processor.
Calibrating delay loop (skipped), value calculated using timer frequency.. 
4019.03 BogoMIPS (lpj=2009519)

Linux 3.4-rc4

[Konrad Rzeszutek Wilk]

On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
> On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> > On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > > Nick, I realize you had trouble with a bisection already, but it might
> > > really be worth trying again. Do a
> > > 
> > > git bisect visualize
> > > 
> > > and try to pick a good commit (avoding the problems you hit) when you
> > > hit a problem, and then do
> > > 
> > >git reset --hard 
> > > 
> > > to force bisection to try another place. That way you can sometimes
> > > avoid the problem spots, and continue the bisection.
> > 
> > Unfortunately, I think the whole swath of commits bisect wants to test
> > are broken (as in, they panic before I get to see whether or not the VGA
> > is working), because the commit from which most of the drm trees were
> > based appears to be broken.  Nevertheless, I've included the new bisect
> > log (four new commits marked skip as opposed to last time).  I've also
> > included the boot log from a crashing kernel, in case someone recognizes
> > how I can avoid this during bisection.  Note that this crash is *not* a
> > regression that exists in current mainline -- bisecting this issue was
> > the first time I had ever seen it.
> 
> Following up on the above, the commit which introduces the panics during
> boot is this one:

I think

dea7e0a ttm: fix agp since ttm tt rework

fixed that.
> 
> commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
> Author: Jerome Glisse 
> Date:   Wed Nov 9 17:15:26 2011 -0500
> 
> drm/ttm: isolate dma data from ttm_tt V4
> 
> Move dma data to a superset ttm_dma_tt structure which herit
> from ttm_tt. This allow driver that don't use dma functionalities
> to not have to waste memory for it.
> 
> V2 Rebase on top of no memory account changes (where/when is my
>delorean when i need it ?)
> V3 Make sure page list is initialized empty
> V4 typo/syntax fixes
> 
> Signed-off-by: Jerome Glisse 
> Reviewed-by: Thomas Hellstrom 
> 
> and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
> pool when swiotlb is active V3") works properly.
> 
> Sometime this week I suppose I'll try to track down the commit which
> fixed the crashes...
> 
> Cheers,
> -- 
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 3.4-rc4

[Geert Uytterhoeven]

On Sun, Apr 22, 2012 at 18:40, Nick Bowler  wrote:
> (Aside: is there a way to run "git bisect skip" without causing a new
> working tree to be immediately checked out? ?When I'm going to be
> picking the next commit manually anyway, having git bisect checkout a
> new tree arbitrarily, potentially forcing a complete recompile (~30
> minutes) when the commit I picked could have been incrementally compiled
> in ~1 minute is pretty annoying...)

I can recommend using ccache for all your compiles.

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

Linux 3.4-rc4

[Nick Bowler]

On 2012-04-22 12:40 -0400, Nick Bowler wrote:
> On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> > Nick, I realize you had trouble with a bisection already, but it might
> > really be worth trying again. Do a
> > 
> > git bisect visualize
> > 
> > and try to pick a good commit (avoding the problems you hit) when you
> > hit a problem, and then do
> > 
> >git reset --hard 
> > 
> > to force bisection to try another place. That way you can sometimes
> > avoid the problem spots, and continue the bisection.
> 
> Unfortunately, I think the whole swath of commits bisect wants to test
> are broken (as in, they panic before I get to see whether or not the VGA
> is working), because the commit from which most of the drm trees were
> based appears to be broken.  Nevertheless, I've included the new bisect
> log (four new commits marked skip as opposed to last time).  I've also
> included the boot log from a crashing kernel, in case someone recognizes
> how I can avoid this during bisection.  Note that this crash is *not* a
> regression that exists in current mainline -- bisecting this issue was
> the first time I had ever seen it.

Following up on the above, the commit which introduces the panics during
boot is this one:

commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse 
Date:   Wed Nov 9 17:15:26 2011 -0500

drm/ttm: isolate dma data from ttm_tt V4

Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.

V2 Rebase on top of no memory account changes (where/when is my
   delorean when i need it ?)
V3 Make sure page list is initialized empty
V4 typo/syntax fixes

Signed-off-by: Jerome Glisse 
Reviewed-by: Thomas Hellstrom 

and the previous commit (3230cfc34fca: "drm/nouveau: enable the ttm dma
pool when swiotlb is active V3") works properly.

Sometime this week I suppose I'll try to track down the commit which
fixed the crashes...

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Nick Bowler]

On 2012-04-22 08:26 +0100, Dave Airlie wrote:
> I've been asking Ben about this, I might have to use a bit more pressure,
> 
> It would be worth bisecting drivers/gpu/drm only, I doubt its going to
> be outside that area.

Since the original bisection was restricted to drivers/gpu, and there
appears to be exactly 0 commits between v3.2 and v3.3 that touch files
in drivers/gpu outside of drivers/gpu/drm, I think this should make no
difference?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Linux 3.4-rc4

[Nick Bowler]

On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
> Nick, I realize you had trouble with a bisection already, but it might
> really be worth trying again. Do a
> 
> git bisect visualize
> 
> and try to pick a good commit (avoding the problems you hit) when you
> hit a problem, and then do
> 
>git reset --hard 
> 
> to force bisection to try another place. That way you can sometimes
> avoid the problem spots, and continue the bisection.

Unfortunately, I think the whole swath of commits bisect wants to test
are broken (as in, they panic before I get to see whether or not the VGA
is working), because the commit from which most of the drm trees were
based appears to be broken.  Nevertheless, I've included the new bisect
log (four new commits marked skip as opposed to last time).  I've also
included the boot log from a crashing kernel, in case someone recognizes
how I can avoid this during bisection.  Note that this crash is *not* a
regression that exists in current mainline -- bisecting this issue was
the first time I had ever seen it.

(Aside: is there a way to run "git bisect skip" without causing a new
working tree to be immediately checked out?  When I'm going to be
picking the next commit manually anyway, having git bisect checkout a
new tree arbitrarily, potentially forcing a complete recompile (~30
minutes) when the commit I picked could have been incrementally compiled
in ~1 minute is pretty annoying...)

  git bisect start 'drivers/gpu'
  # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
  git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
  # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
  git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
  # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch 
'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into 
drm-core-next
  git bisect skip 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
  # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual 
mapping support
  git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
  # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing exports 
for i810 driver.
  git bisect skip 5c2a5ce689c99037771a6c110374461781a6f042
  # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an MSI 
quirk for Dell RS690
  git bisect skip 44517c44496062180a6376cc704b33129441ce60
  # --- The commits below this point are newly tested ---
  # skip: [f7b24c42da1a7bbb98145d27aa716d8af3cae2a6] drm/nouveau/ttm: fix crash 
as a result of a recent ttm change
  git bisect skip f7b24c42da1a7bbb98145d27aa716d8af3cae2a6
  # skip: [0c101461e267850925218d6a6872c379f2498b16] drm/nv40/pm: parse fan pwm 
divisor from vbios tables
  git bisect skip 0c101461e267850925218d6a6872c379f2498b16
  # skip: [06e4cd64174b48345cbd99179b780a2bf4f96ab6] drm/radeon/kms: don't use 
0 bpc for adjusting hdmi clock
  git bisect skip 06e4cd64174b48345cbd99179b780a2bf4f96ab6
  # skip: [1fbe6f625f69e48c4001051dc1431afc704acfaa] Merge tag 'v3.2-rc6' of 
/home/airlied/devel/kernel/linux-2.6 into drm-core-next
  git bisect skip 1fbe6f625f69e48c4001051dc1431afc704acfaa

Linux version 3.2.0-rc6-bisect-00099-g1fbe6f6 (nick at artemis) (gcc version 
4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #60 PREEMPT Sun Apr 22 12:04:36 EDT 
2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffc (usable)
 BIOS-e820: 7ffc - 7ffd (ACPI data)
 BIOS-e820: 7ffd - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [880ff780] ff780
init_memory_mapping: -7ffc
RAMDISK: 37c9c000 - 37ff
ACPI: RSDP 000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 7ffc0100 0003C (v01 A M I  OEMXSDT  01000618 MSFT 0097)
ACPI: FACP 7ffc0290 000F4 (v03 A M I  OEMFACP  01000618 MSFT 0097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 
0x44A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 7ffc0400 04524 (v01  A0055 A0055003 0003 INTL 02002026)
ACPI: FACS 7ffd 00040
ACPI: APIC 7ffc0390 00068 (v01 A M I  OEMAPIC  

Linux 3.4-rc4

[Dave Airlie]

On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
 wrote:
> David & co, any ideas?

I've been asking Ben about this, I might have to use a bit more pressure,

It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.

Dave.

Re: Linux 3.4-rc4

[Dave Airlie]

On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 David  co, any ideas?

I've been asking Ben about this, I might have to use a bit more pressure,

It would be worth bisecting drivers/gpu/drm only, I doubt its going to
be outside that area.

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

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-22 08:26 +0100, Dave Airlie wrote:
 I've been asking Ben about this, I might have to use a bit more pressure,
 
 It would be worth bisecting drivers/gpu/drm only, I doubt its going to
 be outside that area.

Since the original bisection was restricted to drivers/gpu, and there
appears to be exactly 0 commits between v3.2 and v3.3 that touch files
in drivers/gpu outside of drivers/gpu/drm, I think this should make no
difference?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
 Nick, I realize you had trouble with a bisection already, but it might
 really be worth trying again. Do a
 
 git bisect visualize
 
 and try to pick a good commit (avoding the problems you hit) when you
 hit a problem, and then do
 
git reset --hard that-point
 
 to force bisection to try another place. That way you can sometimes
 avoid the problem spots, and continue the bisection.

Unfortunately, I think the whole swath of commits bisect wants to test
are broken (as in, they panic before I get to see whether or not the VGA
is working), because the commit from which most of the drm trees were
based appears to be broken.  Nevertheless, I've included the new bisect
log (four new commits marked skip as opposed to last time).  I've also
included the boot log from a crashing kernel, in case someone recognizes
how I can avoid this during bisection.  Note that this crash is *not* a
regression that exists in current mainline -- bisecting this issue was
the first time I had ever seen it.

(Aside: is there a way to run git bisect skip without causing a new
working tree to be immediately checked out?  When I'm going to be
picking the next commit manually anyway, having git bisect checkout a
new tree arbitrarily, potentially forcing a complete recompile (~30
minutes) when the commit I picked could have been incrementally compiled
in ~1 minute is pretty annoying...)

  git bisect start 'drivers/gpu'
  # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3
  git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7
  # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
  git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610
  # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch 
'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into 
drm-core-next
  git bisect skip 5d56fe5fd794a98c4f446f8665fd06b82e93ff64
  # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual 
mapping support
  git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e
  # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing exports 
for i810 driver.
  git bisect skip 5c2a5ce689c99037771a6c110374461781a6f042
  # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an MSI 
quirk for Dell RS690
  git bisect skip 44517c44496062180a6376cc704b33129441ce60
  # --- The commits below this point are newly tested ---
  # skip: [f7b24c42da1a7bbb98145d27aa716d8af3cae2a6] drm/nouveau/ttm: fix crash 
as a result of a recent ttm change
  git bisect skip f7b24c42da1a7bbb98145d27aa716d8af3cae2a6
  # skip: [0c101461e267850925218d6a6872c379f2498b16] drm/nv40/pm: parse fan pwm 
divisor from vbios tables
  git bisect skip 0c101461e267850925218d6a6872c379f2498b16
  # skip: [06e4cd64174b48345cbd99179b780a2bf4f96ab6] drm/radeon/kms: don't use 
0 bpc for adjusting hdmi clock
  git bisect skip 06e4cd64174b48345cbd99179b780a2bf4f96ab6
  # skip: [1fbe6f625f69e48c4001051dc1431afc704acfaa] Merge tag 'v3.2-rc6' of 
/home/airlied/devel/kernel/linux-2.6 into drm-core-next
  git bisect skip 1fbe6f625f69e48c4001051dc1431afc704acfaa

Linux version 3.2.0-rc6-bisect-00099-g1fbe6f6 (nick@artemis) (gcc version 4.5.3 
(Gentoo 4.5.3-r2 p1.1, pie-0.4.7) ) #60 PREEMPT Sun Apr 22 12:04:36 EDT 2012
Command line: root=md:name=newroot console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e4000 - 0010 (reserved)
 BIOS-e820: 0010 - 7ffc (usable)
 BIOS-e820: 7ffc - 7ffd (ACPI data)
 BIOS-e820: 7ffd - 8000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ff7c - 0001 (reserved)
NX (Execute Disable) protection: active
DMI 2.3 present.
AGP bridge at 00:00:00
Aperture from AGP @ f800 old size 32 MB
Aperture size 4096 MB (APSIZE 0) is not right, using settings from NB
Aperture from AGP @ f800 size 32 MB (APSIZE 0)
last_pfn = 0x7ffc0 max_arch_pfn = 0x4
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
found SMP MP-table at [880ff780] ff780
init_memory_mapping: -7ffc
RAMDISK: 37c9c000 - 37ff
ACPI: RSDP 000f9cb0 00021 (v02 ACPIAM)
ACPI: XSDT 7ffc0100 0003C (v01 A M I  OEMXSDT  01000618 MSFT 0097)
ACPI: FACP 7ffc0290 000F4 (v03 A M I  OEMFACP  01000618 MSFT 0097)
ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529)
ACPI Warning: Optional field Gpe1Block has zero address or length: 
0x44A0/0x0 (20110623/tbfadt-560)
ACPI: DSDT 7ffc0400 04524 (v01  A0055 A0055003 0003 INTL 02002026)
ACPI: FACS 7ffd 00040
ACPI: APIC 7ffc0390 00068 (v01 A M I  OEMAPIC  01000618 

Re: Linux 3.4-rc4

[Geert Uytterhoeven]

On Sun, Apr 22, 2012 at 18:40, Nick Bowler nbow...@elliptictech.com wrote:
 (Aside: is there a way to run git bisect skip without causing a new
 working tree to be immediately checked out?  When I'm going to be
 picking the next commit manually anyway, having git bisect checkout a
 new tree arbitrarily, potentially forcing a complete recompile (~30
 minutes) when the commit I picked could have been incrementally compiled
 in ~1 minute is pretty annoying...)

I can recommend using ccache for all your compiles.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
                                -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Nick Bowler]

On 2012-04-22 12:40 -0400, Nick Bowler wrote:
 On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
  Nick, I realize you had trouble with a bisection already, but it might
  really be worth trying again. Do a
  
  git bisect visualize
  
  and try to pick a good commit (avoding the problems you hit) when you
  hit a problem, and then do
  
 git reset --hard that-point
  
  to force bisection to try another place. That way you can sometimes
  avoid the problem spots, and continue the bisection.
 
 Unfortunately, I think the whole swath of commits bisect wants to test
 are broken (as in, they panic before I get to see whether or not the VGA
 is working), because the commit from which most of the drm trees were
 based appears to be broken.  Nevertheless, I've included the new bisect
 log (four new commits marked skip as opposed to last time).  I've also
 included the boot log from a crashing kernel, in case someone recognizes
 how I can avoid this during bisection.  Note that this crash is *not* a
 regression that exists in current mainline -- bisecting this issue was
 the first time I had ever seen it.

Following up on the above, the commit which introduces the panics during
boot is this one:

commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
Author: Jerome Glisse jgli...@redhat.com
Date:   Wed Nov 9 17:15:26 2011 -0500

drm/ttm: isolate dma data from ttm_tt V4

Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.

V2 Rebase on top of no memory account changes (where/when is my
   delorean when i need it ?)
V3 Make sure page list is initialized empty
V4 typo/syntax fixes

Signed-off-by: Jerome Glisse jgli...@redhat.com
Reviewed-by: Thomas Hellstrom thellst...@vmware.com

and the previous commit (3230cfc34fca: drm/nouveau: enable the ttm dma
pool when swiotlb is active V3) works properly.

Sometime this week I suppose I'll try to track down the commit which
fixed the crashes...

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

Re: Linux 3.4-rc4

[Konrad Rzeszutek Wilk]

On Sun, Apr 22, 2012 at 08:05:54PM -0400, Nick Bowler wrote:
 On 2012-04-22 12:40 -0400, Nick Bowler wrote:
  On 2012-04-21 21:51 -0700, Linus Torvalds wrote:
   Nick, I realize you had trouble with a bisection already, but it might
   really be worth trying again. Do a
   
   git bisect visualize
   
   and try to pick a good commit (avoding the problems you hit) when you
   hit a problem, and then do
   
  git reset --hard that-point
   
   to force bisection to try another place. That way you can sometimes
   avoid the problem spots, and continue the bisection.
  
  Unfortunately, I think the whole swath of commits bisect wants to test
  are broken (as in, they panic before I get to see whether or not the VGA
  is working), because the commit from which most of the drm trees were
  based appears to be broken.  Nevertheless, I've included the new bisect
  log (four new commits marked skip as opposed to last time).  I've also
  included the boot log from a crashing kernel, in case someone recognizes
  how I can avoid this during bisection.  Note that this crash is *not* a
  regression that exists in current mainline -- bisecting this issue was
  the first time I had ever seen it.
 
 Following up on the above, the commit which introduces the panics during
 boot is this one:

I think

dea7e0a ttm: fix agp since ttm tt rework

fixed that.
 
 commit 8e7e70522d760c4ccd4cd370ebfa0ba69e006c6e
 Author: Jerome Glisse jgli...@redhat.com
 Date:   Wed Nov 9 17:15:26 2011 -0500
 
 drm/ttm: isolate dma data from ttm_tt V4
 
 Move dma data to a superset ttm_dma_tt structure which herit
 from ttm_tt. This allow driver that don't use dma functionalities
 to not have to waste memory for it.
 
 V2 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
 V3 Make sure page list is initialized empty
 V4 typo/syntax fixes
 
 Signed-off-by: Jerome Glisse jgli...@redhat.com
 Reviewed-by: Thomas Hellstrom thellst...@vmware.com
 
 and the previous commit (3230cfc34fca: drm/nouveau: enable the ttm dma
 pool when swiotlb is active V3) works properly.
 
 Sometime this week I suppose I'll try to track down the commit which
 fixed the crashes...
 
 Cheers,
 -- 
 Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc4

[Ben Skeggs]

On Sun, 2012-04-22 at 08:26 +0100, Dave Airlie wrote:
 On Sun, Apr 22, 2012 at 5:51 AM, Linus Torvalds
 torva...@linux-foundation.org wrote:
  David  co, any ideas?
 
 I've been asking Ben about this, I might have to use a bit more pressure,
I unfortunately haven't yet had any ideas which could be useful aside
from continuing to try and narrow down the change that caused the issue.

I've been using the VGA output on a lot of different boards (including
of the same generation as the one in the original bug report) with the
latest code without an issue..

Ben.

 
 It would be worth bisecting drivers/gpu/drm only, I doubt its going to
 be outside that area.
 
 Dave.
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Linux 3.4-rc4

[Linus Torvalds]

David & co, any ideas?

There are other reports of problems with 3.3.x kernels, there's a
report from Tim  which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).

Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. Do a

git bisect visualize

and try to pick a good commit (avoding the problems you hit) when you
hit a problem, and then do

   git reset --hard 

to force bisection to try another place. That way you can sometimes
avoid the problem spots, and continue the bisection.

Linus

On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler  
wrote:
> On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
>> But none of it really looks all that scary. It looks like the 3.4
>> release is all on track, but please do holler if you see regressions.
>
> OK, I'll holler. ?Nouveau is still broken in mainline, as it has been
> since March or so, first reported here:
>
> ?Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3.
> ?http://thread.gmane.org/gmane.linux.kernel/1269631
>
> So far, attempts to elicit a response of any kind from maintainers has
> been about as successful as talking to my doorknob.
>
> Thanks,
> --
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
>

Re: Linux 3.4-rc4

[Linus Torvalds]

David  co, any ideas?

There are other reports of problems with 3.3.x kernels, there's a
report from Tim timlie...@woh.rr.com which may be related (also
apparently working in 3.2, broken black screen in all 3.3.x).

Nick, I realize you had trouble with a bisection already, but it might
really be worth trying again. Do a

git bisect visualize

and try to pick a good commit (avoding the problems you hit) when you
hit a problem, and then do

   git reset --hard that-point

to force bisection to try another place. That way you can sometimes
avoid the problem spots, and continue the bisection.

Linus

On Sat, Apr 21, 2012 at 9:07 PM, Nick Bowler nbow...@elliptictech.com wrote:
 On 2012-04-21 15:43 -0700, Linus Torvalds wrote:
 But none of it really looks all that scary. It looks like the 3.4
 release is all on track, but please do holler if you see regressions.

 OK, I'll holler.  Nouveau is still broken in mainline, as it has been
 since March or so, first reported here:

  Subject: Regression: black screen on VGA w/ nouveau in Linux 3.3.
  http://thread.gmane.org/gmane.linux.kernel/1269631

 So far, attempts to elicit a response of any kind from maintainers has
 been about as successful as talking to my doorknob.

 Thanks,
 --
 Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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