Re: [PATCH] fbdev: Select I/O-memory framebuffer ops for SBus

[Nick Bowler]

On 2024-03-22 06:43, Javier Martinez Canillas wrote:
> Thomas Zimmermann  writes:
> 
>> Framebuffer I/O on the Sparc Sbus requires read/write helpers for
>> I/O memory. Select FB_IOMEM_FOPS accordingly.
>>
>> Reported-by: Nick Bowler 

Applied on top of 6.8 and the build is successful.

Thanks,
  Nick

PROBLEM: 5.8-rc7 no video output with nouveau on NV36 (regression)

[Nick Bowler]

Hi,

After installing Linux 5.8-rc7 I seem to get no video output on my
NV36 card once the nouveau module is loaded.  The display (connected
to the digital output) simply reports "No Signal".

I bisected to the following commit, and reverting this commit on
top of 5.8-rc7 appears to correct the issue.

  fa4f4c213f5f7807360c41f2501a3031a9940f3a is the first bad commit
  commit fa4f4c213f5f7807360c41f2501a3031a9940f3a
  Author: James Jones 
  Date:   Mon Feb 10 15:15:55 2020 -0800
  
  drm/nouveau/kms: Support NVIDIA format modifiers
  
  Allow setting the block layout of a nouveau FB
  object using DRM format modifiers.  When
  specified, the format modifier block layout and
  kind overrides the GEM buffer's implicit layout
  and kind.  The specified format modifier is
  validated against the list of modifiers supported
  by the target display hardware.
  
  v2: Used Tesla family instead of NV50 chipset compare
  v4: Do not cache kind, tile_mode in nouveau_framebuffer
  v5: Resolved against nouveau_framebuffer cleanup
  
  Signed-off-by: James Jones 
  Signed-off-by: Ben Skeggs 
  
   drivers/gpu/drm/nouveau/dispnv50/wndw.c   | 20 ---
   drivers/gpu/drm/nouveau/nouveau_display.c | 89 
++-
   drivers/gpu/drm/nouveau/nouveau_display.h |  4 ++
   3 files changed, 104 insertions(+), 9 deletions(-)

The dmesg output from loading the driver is identical except several
lines are missing in the non-working case, which I have marked with
"XXX" below:

  [  168.222926] PCI Interrupt Link [LNKE] enabled at IRQ 16
  [  168.223199] nouveau :01:00.0: vgaarb: deactivate vga console
  [  168.224379] Console: switching to colour dummy device 80x25
  [  168.224612] nouveau :01:00.0: NVIDIA NV36 (436200a1)
  [  168.324779] nouveau :01:00.0: bios: version 04.36.20.21.00
  [  168.325646] agpgart-amd64 :00:00.0: AGP 3.0 bridge
  [  168.325657] agpgart: modprobe tried to set rate=x12. Setting to AGP3 
x8 mode.
  [  168.325662] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x 
mode
  [  168.325679] nouveau :01:00.0: putting AGP V3 device into 8x mode
  [  168.325908] agpgart-amd64 :00:00.0: AGP 3.0 bridge
  [  168.325914] agpgart: modprobe tried to set rate=x12. Setting to AGP3 
x8 mode.
  [  168.325918] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x 
mode
  [  168.325933] nouveau :01:00.0: putting AGP V3 device into 8x mode
  [  168.325990] nouveau :01:00.0: tmr: unknown input clock freq
  [  168.326732] nouveau :01:00.0: fb: 256 MiB DDR1
  [  168.328174] [TTM] Zone  kernel: Available graphics memory: 1022540 KiB
  [  168.328175] [TTM] Initializing pool allocator
  [  168.328181] [TTM] Initializing DMA pool allocator
  [  168.328200] nouveau :01:00.0: DRM: VRAM: 255 MiB
  [  168.328201] nouveau :01:00.0: DRM: GART: 128 MiB
  [  168.328204] nouveau :01:00.0: DRM: BMP version 5.40
  [  168.328208] nouveau :01:00.0: DRM: DCB version 2.2
  [  168.328210] nouveau :01:00.0: DRM: DCB outp 00: 01000300 9c40
  [  168.328214] nouveau :01:00.0: DRM: DCB outp 01: 02010310 9c40
  [  168.328215] nouveau :01:00.0: DRM: DCB outp 02: 04000302 
  [  168.328217] nouveau :01:00.0: DRM: DCB outp 03: 02020321 0303
  [  168.328495] nouveau :01:00.0: DRM: Loading NV17 power sequencing 
microcode
  [  168.329691] nouveau :01:00.0: DRM: MM: using M2MF for buffer copies
  [  168.330258] nouveau :01:00.0: DRM: Saving VGA fonts
  [  168.389460] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
  [  168.391250] nouveau :01:00.0: DRM: Setting dpms mode 3 on TV 
encoder (output 3)
  XXX [  168.487647] nouveau :01:00.0: DRM: allocated 1920x1080 fb: 0x9000, 
bo ff426de1
  XXX [  168.491835] fbcon: nouveaudrmfb (fb0) is primary device
  XXX [  168.608512] nouveau :01:00.0: DRM: 0xE4FB: Parsing digital output 
script table
  XXX [  168.662451] Console: switching to colour frame buffer device 240x67
  XXX [  168.755987] nouveau :01:00.0: fb0: nouveaudrmfb frame buffer device
  [  168.763736] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 
on minor 0

Let me know if you need any more info.

Cheers,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: 5.8-rc7 no video output with nouveau on NV36 (regression)

[Nick Bowler]

On 2020-07-29, Dave Airlie  wrote:
> On Wed, 29 Jul 2020 at 15:05, Nick Bowler  wrote:
>>
>> Hi,
>>
>> After installing Linux 5.8-rc7 I seem to get no video output on my
>> NV36 card once the nouveau module is loaded.  The display (connected
>> to the digital output) simply reports "No Signal".
>>
>> I bisected to the following commit, and reverting this commit on
>> top of 5.8-rc7 appears to correct the issue.
>
> Can you test the drm fixes pull I just sent to Linus
>
> https://patchwork.freedesktop.org/patch/381225/

Yes, pulling this seems to fix things.

Thanks,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

On 2017-12-04 13:33 -0500, Nick Bowler wrote:
> On 2017-12-04 10:04 +, Jose Abreu wrote:
> > Hmmm, my first thought was that audio is being configured first
> > because of the phy lock wait time, I've seen this happening before.
> >
> > Lets try this:
> > - Disable all alsa clients (e.g. pulseaudio, ...) so that no one
> > tries to configure audio.
> > - Plug out/in the cable until the issue appears
> > - When the issue appears use aplay to play audio through the HDMI
> > output
> > - Repeat several times with different audio rates and with no
> > resample (you can use the plughw interface in aplay).
> 
> OK, I will give it a try later this evening.

Using the above sequence on unpatched 4.15-rc1 it seems there is no
sound when starting audio output after the pink bar is visible.

However I am not confident of the results here, restarting aplay
with different sample rates (or even restarting with the same rate)
is causing some weird effects on my setup so I want to check the test
setup with some different source devices.

Cheers,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

On 2017-12-04 10:04 +, Jose Abreu wrote:
> On 03-12-2017 05:20, Nick Bowler wrote:
> > I brought the original test equipment back to the setup so I can
> > see the video and pink bar again.  The symptoms remain the same
> > (unexpected size, pink bar, and no audio).
> >
>
> Can you tell me which test equipment are you using?

I am using an XRGB-Mini Framemeister as the sink device for testing
which isn't "real" test equipment but does show details of the video
and audio mode (which the monitor I have does not do).

The normal setup of this laptop has a small "audio splitter" as
the sink, which among other things includes HDMI input and output
ports and an S/PDIF audio output.

These devices can be connected together in various ways and the
results seem to be consistent in any configuration.

> > It is very consistent: pink bar <=> no audio.
> >
> > My suspicion is that the audio problem is just the wrong video mode
> > on the sink side messing things up, but I have no way of confirming
> > that (that I know of).
>
> Hmmm, my first thought was that audio is being configured first
> because of the phy lock wait time, I've seen this happening before.
>
> Lets try this:
> - Disable all alsa clients (e.g. pulseaudio, ...) so that no one
> tries to configure audio.
> - Plug out/in the cable until the issue appears
> - When the issue appears use aplay to play audio through the HDMI
> output
> - Repeat several times with different audio rates and with no
> resample (you can use the plughw interface in aplay).

OK, I will give it a try later this evening.

Cheers,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> As you reported that the PLL lock failure message is not printed, the
> failure can only come from either the extra delay introduced by the
> above loop, or from reading the HDMI_PHY_STAT0 register.
> 
> How many iterations of the for loop execute before the condition
> becomes true?

Judging from the log posted elsethread (where I added extra printouts),
it seems to consistently become true on the second iteration.

I will try to rule out read side effects by replacing the polling loop
with an unconditional delay.

Cheers,
-- 
Nick Bowler
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

On 2017-12-04 21:34 +0200, Laurent Pinchart wrote:
> On Monday, 4 December 2017 21:30:01 EET Nick Bowler wrote:
> > On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> > > As you reported that the PLL lock failure message is not printed, the
> > > failure can only come from either the extra delay introduced by the
> > > above loop, or from reading the HDMI_PHY_STAT0 register.
> > > 
> > > How many iterations of the for loop execute before the condition
> > > becomes true?
> > 
> > Judging from the log posted elsethread (where I added extra printouts),
> > it seems to consistently become true on the second iteration.
> > 
> > I will try to rule out read side effects by replacing the polling loop
> > with an unconditional delay.
> 
> You're reading my mind :-)

I did this test by applying the following patch on 4.15-rc1, and the
problem remains.  So it appears the delay is responsible somehow.

Cheers,
  Nick

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..4aec4d5c130e 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1101,8 +1101,6 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
 static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-   unsigned int i;
-   u8 val;

if (phy->gen == 1) {
dw_hdmi_phy_enable_powerdown(hdmi, false);
@@ -1116,21 +1114,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);

-   /* Wait for PHY PLL lock */
-   for (i = 0; i < 5; ++i) {
-   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (val)
-   break;
-
-   usleep_range(1000, 2000);
-   }
-
-   if (!val) {
-   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
-   return -ETIMEDOUT;
-   }
-
-   dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
+   usleep_range(1000, 2000);
return 0;
 }

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

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi Jose,

On 2017-12-02 17:11 +, Jose Abreu wrote:
> On 01-12-2017 00:11, Nick Bowler wrote:
> > Another data point... the following patch appears sufficient to
> > restore working behaviour.
[...]
> I don't think you can do this. The phy pll lock check is
> recommended and can indicate hw failure. Can you please check if
> this untested, uncompiled patch makes it work correctly ?

Your patch changes things.  With this applied on top of 4.15-rc1
it is failing 100% of the time instead of only half of the time.

I brought the original test equipment back to the setup so I can
see the video and pink bar again.  The symptoms remain the same
(unexpected size, pink bar, and no audio).

PS: your patch seems to have been line wrapped which made it a
bit annoying to apply.

> -->8---
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index bf14214..456fc54 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1669,7 +1669,7 @@ static void
> hdmi_disable_overflow_interrupts(struct dw_hdmi *hdmi)
>  
>  static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
> drm_display_mode *mode)
>  {
> -   int ret;
> +   int ret, vsync_len = mode->vsync_end - mode->vsync_start;
>  
> hdmi_disable_overflow_interrupts(hdmi);
>  
> @@ -1722,6 +1722,14 @@ static int dw_hdmi_setup(struct dw_hdmi
> *hdmi, struct drm_display_mode *mode)
> return ret;
> hdmi->phy.enabled = true;
>  
> +   /* Reset all clock domains */
> +   hdmi_writeb(hdmi, 0x00, HDMI_MC_SWRSTZ);
> +
> +   /* Rewrite vsync register to latch previous written values */
> +   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> +   vsync_len /= 2;
> +   hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
> +
> /* HDMI Initialization Step B.3 */
> dw_hdmi_enable_video_path(hdmi);
>  
> -->8---
>
> I would expect this patch to end your wrong image issue but the
> audio part may be a different problem.

It is very consistent: pink bar <=> no audio.

My suspicion is that the audio problem is just the wrong video mode
on the sink side messing things up, but I have no way of confirming
that (that I know of).

Thanks,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

On 2017-11-27 22:30 -0500, Nick Bowler wrote:
> A note about the test setup: I had to remove the test equipment so I
> no longer have any information about the video mode from the sink side
> (like in the photos).  Thus, with the current setup, I am using the
> presense or absense of audio to determine whether the issue is present
> or not.
> 
> The test procedure is: boot up, start music, then hotplug the hdmi four
> times.  If sound is heard after all four connections, PASS; otherwise FAIL.
> 
>  - I retested on 4.15-rc1 to confirm that the issue is still present (it is).
> 
>  - I applied the functional revert from earlier on top of 4.15-rc1 and the
>problem is fixed.
> 
>  - Returning to 4.15-rc1 and applying [Laurent Pinchart's] patch --
>the issue is present again (no change in behaviour compared to
>4.15-rc1).

Another data point... the following patch appears sufficient to restore
working behaviour.

Cheers,
  Nick

---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..3118fbd8433d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1101,8 +1101,6 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
 static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-   unsigned int i;
-   u8 val;
 
if (phy->gen == 1) {
dw_hdmi_phy_enable_powerdown(hdmi, false);
@@ -1116,21 +1114,6 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   /* Wait for PHY PLL lock */
-   for (i = 0; i < 5; ++i) {
-   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (val)
-   break;
-
-   usleep_range(1000, 2000);
-   }
-
-   if (!val) {
-   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
-   return -ETIMEDOUT;
-   }
-
-   dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
return 0;
 }
 
-- 
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

On 2017-11-27 11:00 +0200, Laurent Pinchart wrote:
> On Monday, 27 November 2017 06:05:03 EET Archit Taneja wrote:
> > On 2017-11-05 11:41 -0500, Nick Bowler wrote:
[...]
> > > Bisection implicates the following commit:
> > > 
> > > 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
> > > commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46
> > > Author: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> > > Date:   Mon Mar 6 01:35:57 2017 +0200
> > > 
> > >  drm: bridge: dw-hdmi: Fix the PHY power up sequence
[...]
> > 
> > The two main things the commit below does it to a) correctly wait on the
> > TX_PHY_LOCK bit to be asserted and b) use usleep_range() instead of
> > udelay().
> 
> Another difference is that the PWDN and TMDS signals, in theory needed for 
> Gen1 PHYs only, are not set anymore for Gen2 PHYs. Nick, could you test the 
> following change to see if it makes a difference ?

I do not notice any difference with this change applied on top of Linux
4.15-rc1.

A note about the test setup: I had to remove the test equipment so I
no longer have any information about the video mode from the sink side
(like in the photos).  Thus, with the current setup, I am using the
presense or absense of audio to determine whether the issue is present
or not.

The test procedure is: boot up, start music, then hotplug the hdmi four
times.  If sound is heard after all four connections, PASS; otherwise FAIL.

 - I retested on 4.15-rc1 to confirm that the issue is still present (it is).

 - I applied the functional revert from earlier on top of 4.15-rc1 and the
   problem is fixed.

 - Returning to 4.15-rc1 and applying this next patch -- the issue is
   present again (no change in behaviour compared to 4.15-rc1).

> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/
> bridge/synopsys/dw-hdmi.c
> index b172139502d6..1c18ff1bf24a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1104,14 +1104,14 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
>   unsigned int i;
>   u8 val;
>  
> - if (phy->gen == 1) {
> - dw_hdmi_phy_enable_powerdown(hdmi, false);
> + dw_hdmi_phy_enable_powerdown(hdmi, false);
>  
> - /* Toggle TMDS enable. */
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_tmds(hdmi, 1);
> + /* Toggle TMDS enable. */
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_tmds(hdmi, 1);
> +
> + if (phy->gen == 1)
>   return 0;
> - }
>  
>   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
>   dw_hdmi_phy_gen2_pddq(hdmi, 0);
> 
> > I don't see (b) being a problem. About (a), it's possible that the bit above
> > is interpreted differently on a rockchip SoC versus a renesas chip. Could
> > you print the value of HDMI_PHY_STAT0 that's read back?
[...]
> > As an experiment, could you forcefully return 0 instead of -ETIMEDOUT and
> > see if things return back to normal?

I did both of these tests at once by applying the below patch on top of
4.15-rc1.  There is no change in behaviour compared to 4.15-rc1 (except
for the added printouts).

With this, every time after inserting the cable the following is printed:

  [  128.002965] dwhdmi-rockchip ff98.hdmi: 0: HDMI_PHY_STAT0: f2
  [  128.004614] dwhdmi-rockchip ff98.hdmi: 1: HDMI_PHY_STAT0: f3
  [  128.013752] dwhdmi-rockchip ff98.hdmi: 0: HDMI_PHY_STAT0: f2
  [  128.015605] dwhdmi-rockchip ff98.hdmi: 1: HDMI_PHY_STAT0: f3

And there is no difference in output between working and non-working
cases.  I've attached the full log; I manually logged extra messages
to give context from the test procedure:

  "hdmi (not) working" - after bootup or connecting the cable
 (indicating test pass/fail)
  "hdmi disconnect"- after unplugging the cable.

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..0358f6020fb4 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1118,7 +1118,11 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 
/* Wait for PHY PLL lock */
for (i = 0; i < 5; ++i) {
-   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0);
+
+   dev_info(hdmi->dev, "%u: HDMI_PHY_STAT0: %.2hhx\n", i, val);
+
+   val &= HDMI_PHY_TX_PHY_LOCK;
if (val)
break;
 
@@ -1127,7 +1131,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 
if (!val) 

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

On 11/27/17, Laurent Pinchart  wrote:
> The driver should print a "PHY PLL failed to lock" error message to the
> kernel log in that case. Nick, does that happen on your system ?

I will try to test the other things later today, but after bootup there
were no messages whatsoever printed to the kernel log during the test
procedure.

Cheers,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

Any ideas on this issue?  Are there any additional tests I can perform
to help debug this?

On 2017-11-05 11:41 -0500, Nick Bowler wrote:
> I completed bisecting this issue.  See below.
> 
> On 2017-11-02, Nick Bowler <nbow...@draconx.ca> wrote:
> > ~50% of the time after a hotplug, there is a vertical pink bar on the
> > left of the display area and audio is not working at all.  According to
> > the sink device the display size is 1282x720 which seems pretty wrong
> > (normal and working situation is 1280x720).
> >
> > I posted photos of non-working versus working states here:
> >
> >   https://imgur.com/a/qhAZG
> >
> > Unplugging and plugging the cable again will correct the issue (it seems
> > to, for the most part, alternate between working and not-working states,
> > although not always).  It always works on power up with the cable initially
> > connected.
> >
> > This is a regression from 4.11, where hotplug works perfectly every time.
> 
> Bisection implicates the following commit:
> 
> 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
> commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46
> Author: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> Date:   Mon Mar 6 01:35:57 2017 +0200
> 
> drm: bridge: dw-hdmi: Fix the PHY power up sequence
> 
> When powering the PHY up we need to wait for the PLL to lock. This is
> done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
> (interrupt-based wait could be implemented as well but is likely
> overkill). The bit is asserted when the PLL locks, but the current code
> incorrectly waits for the bit to be deasserted. Fix it, and while at it,
> replace the udelay() with a sleep as the code never runs in
> non-sleepable context.
> 
> To be consistent with the power down implementation move the poll loop
> to the power off function.
> 
> Signed-off-by: Laurent Pinchart 
> <laurent.pinchart+rene...@ideasonboard.com>
> Tested-by: Neil Armstrong <narmstr...@baylibre.com>
> Reviewed-by: Jose Abreu <joab...@synopsys.com>
> Signed-off-by: Archit Taneja <arch...@codeaurora.org>
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+rene...@ideasonboard.com
> 
> :04 04 0defad9d1a61c0355f49c679b18eebae2c4b9495
> 5d260e6db25d6abc1211d61ec3405be99e693a23 Mdrivers
> 
> This commit does not revert cleanly, but on top of latest master (which has
> the problem) I manually changed the relevant code back to its original state
> and the problem is fixed, like this:
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index bf14214fa464..6618aac95a51 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1100,37 +1100,34 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi 
> *hdmi)
> 
>  static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
>  {
> - const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> - unsigned int i;
> - u8 val;
> + u8 val, msec;
> 
> - if (phy->gen == 1) {
> - dw_hdmi_phy_enable_powerdown(hdmi, false);
> + dw_hdmi_phy_enable_powerdown(hdmi, false);
> 
> - /* Toggle TMDS enable. */
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_tmds(hdmi, 1);
> - return 0;
> - }
> + /* toggle TMDS enable */
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_tmds(hdmi, 1);
> 
> + /* gen2 tx power on */
>   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
>   dw_hdmi_phy_gen2_pddq(hdmi, 0);
> 
>   /* Wait for PHY PLL lock */
> - for (i = 0; i < 5; ++i) {
> + msec = 5;
> + do {
>   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> - if (val)
> + if (!val)
>   break;
> 
> - usleep_range(1000, 2000);
> - }
> + if (msec == 0) {
> + dev_err(hdmi->dev, "PHY PLL not locked\n");
> + return -ETIMEDOUT;
> + }
> 
> - if (!val) {
> - dev_err(hdmi->dev, "PHY PLL failed to lock\n");
> - return -ETIMEDOUT;
> - }
> + udelay(1000);
> + msec--;
> + } while (1);
> 
> - dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
>   return 0;
>  }
> 

Thanks,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

I completed bisecting this issue.  See below.

On 2017-11-02, Nick Bowler <nbow...@draconx.ca> wrote:
> ~50% of the time after a hotplug, there is a vertical pink bar on the
> left of the display area and audio is not working at all.  According to
> the sink device the display size is 1282x720 which seems pretty wrong
> (normal and working situation is 1280x720).
>
> I posted photos of non-working versus working states here:
>
>   https://imgur.com/a/qhAZG
>
> Unplugging and plugging the cable again will correct the issue (it seems
> to, for the most part, alternate between working and not-working states,
> although not always).  It always works on power up with the cable initially
> connected.
>
> This is a regression from 4.11, where hotplug works perfectly every time.

Bisection implicates the following commit:

181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46
Author: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Date:   Mon Mar 6 01:35:57 2017 +0200

drm: bridge: dw-hdmi: Fix the PHY power up sequence

When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the bit to be deasserted. Fix it, and while at it,
replace the udelay() with a sleep as the code never runs in
non-sleepable context.

To be consistent with the power down implementation move the poll loop
to the power off function.

Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Tested-by: Neil Armstrong <narmstr...@baylibre.com>
Reviewed-by: Jose Abreu <joab...@synopsys.com>
Signed-off-by: Archit Taneja <arch...@codeaurora.org>
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+rene...@ideasonboard.com

:04 04 0defad9d1a61c0355f49c679b18eebae2c4b9495
5d260e6db25d6abc1211d61ec3405be99e693a23 M  drivers

This commit does not revert cleanly, but on top of latest master (which has
the problem) I manually changed the relevant code back to its original state
and the problem is fixed, like this:

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..6618aac95a51 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1100,37 +1100,34 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)

 static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 {
-   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-   unsigned int i;
-   u8 val;
+   u8 val, msec;

-   if (phy->gen == 1) {
-   dw_hdmi_phy_enable_powerdown(hdmi, false);
+   dw_hdmi_phy_enable_powerdown(hdmi, false);

-   /* Toggle TMDS enable. */
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 1);
-   return 0;
-   }
+   /* toggle TMDS enable */
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_tmds(hdmi, 1);

+   /* gen2 tx power on */
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);

/* Wait for PHY PLL lock */
-   for (i = 0; i < 5; ++i) {
+   msec = 5;
+   do {
val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (val)
+   if (!val)
break;

-   usleep_range(1000, 2000);
-   }
+   if (msec == 0) {
+   dev_err(hdmi->dev, "PHY PLL not locked\n");
+   return -ETIMEDOUT;
+   }

-   if (!val) {
-   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
-   return -ETIMEDOUT;
-   }
+   udelay(1000);
+   msec--;
+   } while (1);

-   dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
return 0;
 }

Cheers,
  Nick
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

On my Asus C201 laptop (rk3288) the HDMI has been behaving weirdly after
Linux upgrade.

~50% of the time after a hotplug, there is a vertical pink bar on the
left of the display area and audio is not working at all.  According to
the sink device the display size is 1282x720 which seems pretty wrong
(normal and working situation is 1280x720).

I posted photos of non-working versus working states here:

  https://imgur.com/a/qhAZG

Unplugging and plugging the cable again will correct the issue (it seems
to, for the most part, alternate between working and not-working states,
although not always).  It always works on power up with the cable initially
connected.

This is a regression from 4.11, where hotplug works perfectly every time.

I attached dmesg output (gzipped) from 4.14-rc7 (I booted up and
re-plugged the cable twice, which triggered non-working state and then
back to working state -- although seems no messages are logged from
these hotplugs).

I am working to bisect this, might take a while.  Partial progress
follows...

Let me know of anything else I should try.

Thanks,
  Nick

git bisect start
# bad: [0b07194bb55ed836c2cc7c22e866b87a14681984] Linux 4.14-rc7
git bisect bad 0b07194bb55ed836c2cc7c22e866b87a14681984
# bad: [fa394784e74b918f44fca1e6a1f826cf818350d2] Linux 4.12.14
git bisect bad fa394784e74b918f44fca1e6a1f826cf818350d2
# good: [bd1a9eb6a755e1cb342725a11242251d2bfad567] Linux 4.11.12
git bisect good bd1a9eb6a755e1cb342725a11242251d2bfad567
# good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
git bisect good a351e9b9fc24e982ec2f0e76379a49826036da12
# bad: [8f28472a739e8e39adc6e64ee5b460df039f0e4f] Merge tag
'usb-4.12-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
git bisect bad 8f28472a739e8e39adc6e64ee5b460df039f0e4f


aidos-4.14-rc7.log.gz
Description: GNU Zip compressed data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

On 2/9/16, Ville Syrjälä  wrote:
> BTW I'm not at all convinced about the current live status bit defines
> we have for g4x. Supposedly someone tested them and found that they
> don't match the spec, but IIRC when I tried them on one g4x machine
> here, they did match the spec (well, at least for the ports present
> on that particular board).
>
> So something like this may or may not help:
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 188ad5de020f..80c08016e522 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3302,9 +3302,9 @@ enum skl_disp_power_wells {
>   * Please check the detailed lore in the commit message for for
> experimental
>   * evidence.
>   */
> -#define   PORTD_HOTPLUG_LIVE_STATUS_G4X  (1 << 29)
> +#define   PORTD_HOTPLUG_LIVE_STATUS_G4X  (1 << 27)
>  #define   PORTC_HOTPLUG_LIVE_STATUS_G4X  (1 << 28)
> -#define   PORTB_HOTPLUG_LIVE_STATUS_G4X  (1 << 27)
> +#define   PORTB_HOTPLUG_LIVE_STATUS_G4X  (1 << 29)
>  /* VLV DP/HDMI bits again match Bspec */
>  #define   PORTD_HOTPLUG_LIVE_STATUS_VLV  (1 << 27)
>  #define   PORTC_HOTPLUG_LIVE_STATUS_VLV  (1 << 28)

Well, I applied this on 4.5-rc3 and it seems to fix things.

Thanks,
  Nick

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

On 1/28/16, Nick Bowler  wrote:
> On 2016-01-21, Nick Bowler  wrote:
>> On 2016-01-21, Jindal, Sonika  wrote:
>>> On 1/21/2016 8:59 AM, Nick Bowler wrote:
>>>> On 1/20/16, Nick Bowler  wrote:
>>>>> On 2016-01-20, Jindal, Sonika  wrote:
>> [...]
>>>>>> Does the same system works with any other monitor?
>>>>> I'll see if I can find another to try.
>>>> I tried another monitor, and the same problem occurs.
>>> Which make are these monitors?
>>
>>  - LG Flatron W2253V
>>  - Dell E228WFPc
>>
>>> Do you have any other system other than G45?
>>
>> Nothing else with Linux 4.4, unfortunately.
>
> Anything else you want me to try?
>
> This issue is still present in 4.5-rc1.

Ping?

HDMI is still broken on my system in 4.5-rc3.

Cheers,
  Nick

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

On 2016-01-21, Nick Bowler  wrote:
> On 2016-01-21, Jindal, Sonika  wrote:
>> On 1/21/2016 8:59 AM, Nick Bowler wrote:
>>> On 1/20/16, Nick Bowler  wrote:
>>>> On 2016-01-20, Jindal, Sonika  wrote:
> [...]
>>>>> Does the same system works with any other monitor?
>>>> I'll see if I can find another to try.
>>> I tried another monitor, and the same problem occurs.
>> Which make are these monitors?
>
>  - LG Flatron W2253V
>  - Dell E228WFPc
>
>> Do you have any other system other than G45?
>
> Nothing else with Linux 4.4, unfortunately.

Anything else you want me to try?

This issue is still present in 4.5-rc1.

Cheers,
  Nick

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

On 2016-01-21, Jindal, Sonika  wrote:
> On 1/21/2016 8:59 AM, Nick Bowler wrote:
>> On 1/20/16, Nick Bowler  wrote:
>>> On 2016-01-20, Jindal, Sonika  wrote:
[...]
>>>> Does the same system works with any other monitor?
>>> I'll see if I can find another to try.
>> I tried another monitor, and the same problem occurs.
> Which make are these monitors?

 - LG Flatron W2253V
 - Dell E228WFPc

> Do you have any other system other than G45?

Nothing else with Linux 4.4, unfortunately.

Thanks,
  Nick

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

On 1/20/16, Nick Bowler  wrote:
> Hi,
>
> On 2016-01-20, Jindal, Sonika  wrote:
>> Can you please check if you have following patch:
>> "commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
>> Author: Gary Wang 
>> Date:   Wed Dec 23 16:11:35 2015 +0800
>>
>> drm/i915: increase the tries for HDMI hotplug live status checking"
>
> Yes, that patch seems to be present in 4.4.
>
>> Does the same system works with any other monitor?
>
> I'll see if I can find another to try.

I tried another monitor, and the same problem occurs.

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

Hi,

On 2016-01-20, Jindal, Sonika  wrote:
> Can you please check if you have following patch:
> "commit 3d8acd1f667b45c531401c8f0c2033072e32a05d
> Author: Gary Wang 
> Date:   Wed Dec 23 16:11:35 2015 +0800
>
> drm/i915: increase the tries for HDMI hotplug live status checking"

Yes, that patch seems to be present in 4.4.

> Does the same system works with any other monitor?

I'll see if I can find another to try.

Thanks,
  Nick

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

[Nick Bowler]

Hi,

Upgrading from 4.3 to 4.4 breaks my HDMI output on my G45 machine.

As soon as the intel driver is loaded, the monitor shuts off
(standby mode).  Inspecting /sys/class/drm/card0-HDMI-A-1/status
reports "disconnected".  When it is working, this attribute says
"connected".

There is nothing unusual printed to dmesg.

Bisection pinpoints the following:

  237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit
  commit 237ed86c693d8a8e4db476976aeb30df4deac74b
  Author: Sonika Jindal 
  Date:   Tue Sep 15 09:44:20 2015 +0530

  drm/i915: Check live status before reading edid
  [...]
  Signed-off-by: Shashank Sharma 
  Signed-off-by: Sonika Jindal 
  Reviewed-by: Rodrigo Vivi 
  Signed-off-by: Daniel Vetter 

The commit does not revert cleanly, but this patch resolves the issue:

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e6c035b0fc1c..8cefb9105f26 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1393,7 +1393,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)

intel_hdmi_unset_edid(connector);

-   if (intel_hdmi_set_edid(connector, live_status)) {
+   if (intel_hdmi_set_edid(connector, true)) {
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);

hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;

Let me know if you need any more info.

Thanks,
  Nick

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

[Nick Bowler]

On 10/7/15, Ville Syrjälä  wrote:
> On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
>> On 10/7/15, Ville Syrjälä  wrote:
>> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>> >> On 9/24/15, Nick Bowler  wrote:
>> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>> >> > not working.  Specifically, the display is continuously powering on
>> >> > and off -- at no point is any image visible on the screen (I am
>> >> > expecting to see the console output).  The display connected to the
>> >> > HDMI output is working fine.
>> [...]
> I've attached two potential patches that might help. Can you give a try
> to just patch 1, and if that alone doesn't help then both patches
> together?

Patch #1: no change.
Patch #1+#2: this works.

Regards,
  Nick

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

[Nick Bowler]

On 10/7/15, Nick Bowler  wrote:
> On 10/7/15, Ville Syrjälä  wrote:
>> On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
>>> On 10/7/15, Ville Syrjälä  wrote:
>>> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>>> >> On 9/24/15, Nick Bowler  wrote:
>>> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>>> >> > not working.  Specifically, the display is continuously powering on
>>> >> > and off -- at no point is any image visible on the screen (I am
>>> >> > expecting to see the console output).  The display connected to the
>>> >> > HDMI output is working fine.
>>> [...]
>> Hmm. You said VGA has the problem, but HDMI does not. Was the problem
>> happening even when you have both displays enabled at the same time, or
>> just when VGA was enabled alone?
>
> When I boot with HDMI cable disconnected, there is no change in behaviour
> for the VGA output.

Clarification: normally both displays are connected.  So the original issue is
that only one of two displays are working.

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

[Nick Bowler]

On 10/7/15, Ville Syrjälä  wrote:
> On Wed, Oct 07, 2015 at 10:29:22AM -0400, Nick Bowler wrote:
>> On 10/7/15, Ville Syrjälä  wrote:
>> > On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>> >> On 9/24/15, Nick Bowler  wrote:
>> >> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>> >> > not working.  Specifically, the display is continuously powering on
>> >> > and off -- at no point is any image visible on the screen (I am
>> >> > expecting to see the console output).  The display connected to the
>> >> > HDMI output is working fine.
>> [...]
> Hmm. You said VGA has the problem, but HDMI does not. Was the problem
> happening even when you have both displays enabled at the same time, or
> just when VGA was enabled alone?

When I boot with HDMI cable disconnected, there is no change in behaviour
for the VGA output.

> I've attached two potential patches that might help. Can you give a try
> to just patch 1, and if that alone doesn't help then both patches
> together?

I will try.

Cheers,
  Nick

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

[Nick Bowler]

On 10/7/15, Ville Syrjälä  wrote:
> On Tue, Oct 06, 2015 at 11:42:33AM -0400, Nick Bowler wrote:
>> On 9/24/15, Nick Bowler  wrote:
>> > Testing out 4.3-rc2, first thing I notice is that the VGA output is
>> > not working.  Specifically, the display is continuously powering on
>> > and off -- at no point is any image visible on the screen (I am
>> > expecting to see the console output).  The display connected to the
>> > HDMI output is working fine.
[...]
>>   b8afb9113c519a8bd742f7df8c424b0af69a75cd is the first bad commit
>>   commit b8afb9113c519a8bd742f7df8c424b0af69a75cd
>>   Author: Ville Syrjälä 
>>   Date:   Mon Jun 29 15:25:48 2015 +0300
>>
>>   drm/i915: Keep GMCH DPLL VGA mode always disabled
[...]
> @@ -1790,13 +1790,13 @@ static void i9xx_disable_pll(struct intel_crtc
> *crtc)
> /* Make sure the pipe isn't still relying on us */
> assert_pipe_disabled(dev_priv, pipe);
>
> -   I915_WRITE(DPLL(pipe), 0);
> +   I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
> POSTING_READ(DPLL(pipe));
>  }
>
>
> That hunk is the only relevant part for your machine. Can you try to revert
> just that manually?
>
> But I'm really surprised that would have any effect since we only used
> to enable "VGA mode" when the DPLL is off. And when the DPLL is off,
> there's nothing on the screen anyway.

Nevertheless, manually reverting just that hunk seems to fix it.

Thanks,
  Nick

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

[Nick Bowler]

Hi,

This issue is still present in 4.3-rc4.

On 9/24/15, Nick Bowler  wrote:
> Testing out 4.3-rc2, first thing I notice is that the VGA output is
> not working.  Specifically, the display is continuously powering on
> and off -- at no point is any image visible on the screen (I am expecting
> to see the console output).  The display connected to the HDMI output is
> working fine.
>
> Linux 4.2 did not suffer from this problem.
>
> In dmesg I see the following messages, which I do not see on a working
> kernel.  Full dmesg from 4.3-rc2 is attached (gzipped).
>
>   [0.115339] [drm:drm_calc_timestamping_constants] *ERROR* crtc
> 21: Can't calculate constants, dotclock = 0!
>   [0.117582] [drm:intel_opregion_init] *ERROR* No ACPI video bus found
>
> This is an older machine with Intel G45 graphics.

I was able to identify the commit which fixed my boot crashes, so I
cherry-picked 80aa93128653 ("drm/i915: disable_shared_pll doesn't
work on pre-gen5") on top of all otherwise untestable commits.  This
allowed bisection to proceed:

  b8afb9113c519a8bd742f7df8c424b0af69a75cd is the first bad commit
  commit b8afb9113c519a8bd742f7df8c424b0af69a75cd
  Author: Ville Syrjälä 
  Date:   Mon Jun 29 15:25:48 2015 +0300

  drm/i915: Keep GMCH DPLL VGA mode always disabled

  We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
  again when disabling the DPLL. Having VGA mode enabled even in unused
  DPLLs can cause problems for CHV, so it seems wiser to always keep it
  disabled. And let's just do that on all GMCH platforms to keep things
  as similar as possible between them.

  Signed-off-by: Ville Syrjälä 
  Reviewed-by: Sivakumar Thulasimani 
  Signed-off-by: Daniel Vetter 

  :04 04 7797d596e73ecf75723375028decd25fbe332ee0
9f90a92eec483919853d68563bbb09a71a305532 M  drivers

Unfortunately it does not revert cleanly on master.

Regards,
  Nick

PROBLEM: Intel VGA output busticated on 4.3-rc2 (regression)

[Nick Bowler]

Hi,

Testing out 4.3-rc2, first thing I notice is that the VGA output is
not working.  Specifically, the display is continuously powering on
and off -- at no point is any image visible on the screen (I am expecting
to see the console output).  The display connected to the HDMI output is
working fine.

Linux 4.2 did not suffer from this problem.

In dmesg I see the following messages, which I do not see on a working
kernel.  Full dmesg from 4.3-rc2 is attached (gzipped).

  [0.115339] [drm:drm_calc_timestamping_constants] *ERROR* crtc
21: Can't calculate constants, dotclock = 0!
  [0.117582] [drm:intel_opregion_init] *ERROR* No ACPI video bus found

This is an older machine with Intel G45 graphics.

Unfortunately bisection is proving difficult, because the commits it
wants me to test have a different problem: neither display comes up at
all (both remain in standby).  Partial results follow.

Thanks,
  Nick

  git bisect start 'drivers/gpu/drm/i915'
  # bad: [1f93e4a96c9109378204c147b3eec0d0e8100fde] Linux 4.3-rc2
  git bisect bad 1f93e4a96c9109378204c147b3eec0d0e8100fde
  # good: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
  git bisect good 64291f7db5bd8150a74ad2036f1037e6a0428df2
  # skip: [a7a6c498927ea42c9a3b26e0caa5c854a980d58c] drm/i915:
POSTING_READ() in intel_set_memory_cxsr()
  git bisect skip a7a6c498927ea42c9a3b26e0caa5c854a980d58c
  # skip: [031b698a77a70a6c394568034437b5486a44e868] drm/i915:
Unconditionally do fb tracking invalidate in set_domain
  git bisect skip 031b698a77a70a6c394568034437b5486a44e868
  # skip: [adeca76d8e2b34b5c739a36f4191aed63080da40] drm/i915:
Simplify i915_gem_execbuffer_retire_commands() parameters
  git bisect skip adeca76d8e2b34b5c739a36f4191aed63080da40
  # good: [369712e89404089fa559235bb1ee8fc40d976e6b] drm/i915: reduce
duplicate conditions in i9xx_hpd_irq_handler
  git bisect good 369712e89404089fa559235bb1ee8fc40d976e6b
  # skip: [6eb1a6817246f1a67de4d6959a84d09efead5329] drm/i915: Read wm
values from hardware at init on CHV
  git bisect skip 6eb1a6817246f1a67de4d6959a84d09efead5329
  # bad: [d14e7b6d1d8747826cb900db852351c550e00fdd] drm/i915: Check DP
link status on long hpd too
  git bisect bad d14e7b6d1d8747826cb900db852351c550e00fdd
  # skip: [fe36f55d4d4447679923fc74564786ae423ca4bd] drm/i915/gtt:
Cleanup page directory encoding
  git bisect skip fe36f55d4d4447679923fc74564786ae423ca4bd
-- next part --
A non-text attachment was scrubbed...
Name: i915-novga-dmesg.log.gz
Type: application/x-gzip
Size: 12717 bytes
Desc: not available
URL: 

Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

Ping?

On 2013-03-07 10:06 -0500, Nick Bowler wrote:
> Yesterday I upgraded one of my machines to 3.8.2 from 3.6.6.  This
> machine has an old NV36 AGP board.  With the new kernel, as soon as
> nouveau takes over the console the display connected via DVI goes dark
> (the monitor goes into standby mode).  The display connected via VGA
> continues to work fine.
> 
> Starting Xorg does not correct the problem.  Nouveau seems to know
> that the display is connected:
> 
>   % cat /sys/class/drm/card0-DVI-I-1/status
>   connected
> 
> I don't see anything unusual in the log either (full log attached):
> 
>   % dmesg -t | grep -iE 'drm|nouveau'
>   [drm] Initialized drm 1.1.0 20060810
>   nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x436200a1
>   nouveau  [  DEVICE][:01:00.0] Chipset: NV36 (NV36)
>   nouveau  [  DEVICE][:01:00.0] Family : NV30
>   nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
>   nouveau  [   VBIOS][:01:00.0] ... appears to be valid
>   nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
>   nouveau  [   VBIOS][:01:00.0] BMP version 5.28
>   nouveau  [   VBIOS][:01:00.0] version 04.36.20.21
>   nouveau W[  PTIMER][:01:00.0] unknown input clock freq
>   nouveau  [ PFB][:01:00.0] RAM type: DDR1
>   nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
>   nouveau :01:00.0: putting AGP V3 device into 8x mode
>   nouveau  [ DRM] VRAM: 255 MiB
>   nouveau  [ DRM] GART: 64 MiB
>   nouveau  [ DRM] BMP BIOS found
>   nouveau  [ DRM] BMP version 5.40
>   nouveau  [ DRM] Bios version 04.36.20.21
>   nouveau  [ DRM] DCB version 2.2
>   nouveau  [ DRM] DCB outp 00: 01000300 9c40
>   nouveau  [ DRM] DCB outp 01: 02010310 9c40
>   nouveau  [ DRM] DCB outp 02: 04000302 
>   nouveau  [ DRM] DCB outp 03: 02020321 0303
>   nouveau  [ DRM] Loading NV17 power sequencing microcode
>   nouveau  [ DRM] Saving VGA fonts
>   [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>   [drm] No driver support for vblank timestamp query.
>   nouveau  [ DRM] 0xE51A: Parsing digital output script table
>   nouveau  [ DRM] 0 available performance level(s)
>   nouveau  [ DRM] c: core 425MHz memory 501MHz voltage 1350mV
>   nouveau  [ DRM] MM: using M2MF for buffer copies
>   nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 0)
>   nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 1)
>   nouveau  [ DRM] Setting dpms mode 3 on tmds encoder (output 2)
>   nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 3)
>   nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo 88007b6ae000
>   fbcon: nouveaufb (fb0) is primary device
>   nouveau  [ DRM] 0xE51A: Parsing digital output script table
>   nouveau  [ DRM] Setting dpms mode 0 on tmds encoder (output 2)
>   nouveau  [ DRM] Output DVI-I-1 is running on CRTC 0 using output C
>   nouveau  [ DRM] Setting dpms mode 0 on vga encoder (output 1)
>   nouveau  [ DRM] Output VGA-1 is running on CRTC 1 using output B
>   fb0: nouveaufb frame buffer device
>   drm: registered panic notifier
>   [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 0
> 
> I started a bisection... here's the first steps so far.  I will try to
> finish the procedure over the next couple days but I'm reporting this
> now in case someone needs me to get some other info.
[...]

On 2013-03-08 09:28 -0500, Nick Bowler wrote:
> I carried this on a bit further, but it seems that most of the remaining
> commits bisect wants to test do not compile, so there is a huge number
> of skipped commits.  Not exactly a lot of fun...
> 
> git bisect start 'drivers/gpu/drm'
> # good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
> git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
> # bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
> git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
> # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
> git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
> # bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and 
> PCH transcoders on lpt_pch_enable
> git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
> # good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add 
> busmaster enable, regression fix
> git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
> # bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 
> 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
> git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727
> # bad: [b9f10852fcb1f09369d931dcbfbaad89ad1da4ad] drm/nv98/crypt: fix fuc 
> bui

Re: Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

Ping?

On 2013-03-07 10:06 -0500, Nick Bowler wrote:
 Yesterday I upgraded one of my machines to 3.8.2 from 3.6.6.  This
 machine has an old NV36 AGP board.  With the new kernel, as soon as
 nouveau takes over the console the display connected via DVI goes dark
 (the monitor goes into standby mode).  The display connected via VGA
 continues to work fine.
 
 Starting Xorg does not correct the problem.  Nouveau seems to know
 that the display is connected:
 
   % cat /sys/class/drm/card0-DVI-I-1/status
   connected
 
 I don't see anything unusual in the log either (full log attached):
 
   % dmesg -t | grep -iE 'drm|nouveau'
   [drm] Initialized drm 1.1.0 20060810
   nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x436200a1
   nouveau  [  DEVICE][:01:00.0] Chipset: NV36 (NV36)
   nouveau  [  DEVICE][:01:00.0] Family : NV30
   nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
   nouveau  [   VBIOS][:01:00.0] ... appears to be valid
   nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
   nouveau  [   VBIOS][:01:00.0] BMP version 5.28
   nouveau  [   VBIOS][:01:00.0] version 04.36.20.21
   nouveau W[  PTIMER][:01:00.0] unknown input clock freq
   nouveau  [ PFB][:01:00.0] RAM type: DDR1
   nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
   nouveau :01:00.0: putting AGP V3 device into 8x mode
   nouveau  [ DRM] VRAM: 255 MiB
   nouveau  [ DRM] GART: 64 MiB
   nouveau  [ DRM] BMP BIOS found
   nouveau  [ DRM] BMP version 5.40
   nouveau  [ DRM] Bios version 04.36.20.21
   nouveau  [ DRM] DCB version 2.2
   nouveau  [ DRM] DCB outp 00: 01000300 9c40
   nouveau  [ DRM] DCB outp 01: 02010310 9c40
   nouveau  [ DRM] DCB outp 02: 04000302 
   nouveau  [ DRM] DCB outp 03: 02020321 0303
   nouveau  [ DRM] Loading NV17 power sequencing microcode
   nouveau  [ DRM] Saving VGA fonts
   [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
   [drm] No driver support for vblank timestamp query.
   nouveau  [ DRM] 0xE51A: Parsing digital output script table
   nouveau  [ DRM] 0 available performance level(s)
   nouveau  [ DRM] c: core 425MHz memory 501MHz voltage 1350mV
   nouveau  [ DRM] MM: using M2MF for buffer copies
   nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 0)
   nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 1)
   nouveau  [ DRM] Setting dpms mode 3 on tmds encoder (output 2)
   nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 3)
   nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo 88007b6ae000
   fbcon: nouveaufb (fb0) is primary device
   nouveau  [ DRM] 0xE51A: Parsing digital output script table
   nouveau  [ DRM] Setting dpms mode 0 on tmds encoder (output 2)
   nouveau  [ DRM] Output DVI-I-1 is running on CRTC 0 using output C
   nouveau  [ DRM] Setting dpms mode 0 on vga encoder (output 1)
   nouveau  [ DRM] Output VGA-1 is running on CRTC 1 using output B
   fb0: nouveaufb frame buffer device
   drm: registered panic notifier
   [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 0
 
 I started a bisection... here's the first steps so far.  I will try to
 finish the procedure over the next couple days but I'm reporting this
 now in case someone needs me to get some other info.
[...]

On 2013-03-08 09:28 -0500, Nick Bowler wrote:
 I carried this on a bit further, but it seems that most of the remaining
 commits bisect wants to test do not compile, so there is a huge number
 of skipped commits.  Not exactly a lot of fun...
 
 git bisect start 'drivers/gpu/drm'
 # good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
 git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
 # bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
 git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
 # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
 git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
 # bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and 
 PCH transcoders on lpt_pch_enable
 git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
 # good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add 
 busmaster enable, regression fix
 git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
 # bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 
 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
 git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727
 # bad: [b9f10852fcb1f09369d931dcbfbaad89ad1da4ad] drm/nv98/crypt: fix fuc 
 build with latest envyas
 git bisect bad b9f10852fcb1f09369d931dcbfbaad89ad1da4ad
 # bad: [b10f20d590aa040e4028c04a70a27b9ad6650ba8] drm/nvc0-/gr: remove 
 reset-after-grctx-construction hack
 git bisect bad b10f20d590aa040e4028c04a70a27b9ad6650ba8
 # skip: [18c9b959fd8ea6f3602efbedad788f53e305e6f1] drm/nouveau/gpuobj: create 
 wrapper functions for mapping

Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

On 2013-03-07 10:06 -0500, Nick Bowler wrote:
> I started a bisection... here's the first steps so far.  I will try to
> finish the procedure over the next couple days but I'm reporting this
> now in case someone needs me to get some other info.

I carried this on a bit further, but it seems that most of the remaining
commits bisect wants to test do not compile, so there is a huge number
of skipped commits.  Not exactly a lot of fun...

git bisect start 'drivers/gpu/drm'
# good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
# bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
# good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
# bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and PCH 
transcoders on lpt_pch_enable
git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
# good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add busmaster 
enable, regression fix
git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
# bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 'drm-fixes-3.7' 
of git://people.freedesktop.org/~agd5f/linux into drm-fixes
git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727
# bad: [b9f10852fcb1f09369d931dcbfbaad89ad1da4ad] drm/nv98/crypt: fix fuc build 
with latest envyas
git bisect bad b9f10852fcb1f09369d931dcbfbaad89ad1da4ad
# bad: [b10f20d590aa040e4028c04a70a27b9ad6650ba8] drm/nvc0-/gr: remove 
reset-after-grctx-construction hack
git bisect bad b10f20d590aa040e4028c04a70a27b9ad6650ba8
# skip: [18c9b959fd8ea6f3602efbedad788f53e305e6f1] drm/nouveau/gpuobj: create 
wrapper functions for mapping gpuobj into vm/bar
git bisect skip 18c9b959fd8ea6f3602efbedad788f53e305e6f1
# skip: [092599da308bf56b96c849ecdd315b8a1a13ca52] drm/nv50/instmem: remove use 
of nouveau_gpuobj_new_fake()
git bisect skip 092599da308bf56b96c849ecdd315b8a1a13ca52
# skip: [4196faa8623264b79279a06fd186654c959f2767] drm/nouveau/i2c: port to 
subdev interfaces
git bisect skip 4196faa8623264b79279a06fd186654c959f2767
# skip: [9da226f698c01b268b9172050df4150f269a7613] drm/nvc0/fifo: handle bar1 
control regs much like fifo/nve0
git bisect skip 9da226f698c01b268b9172050df4150f269a7613
# skip: [8aceb7de47ea2491abc1a577dc875b19e9947a54] drm/nouveau/clk: implement 
stub clock subdev
git bisect skip 8aceb7de47ea2491abc1a577dc875b19e9947a54
# skip: [70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9] drm/nv04-nv40/fifo: remove 
use of nouveau_gpuobj_new_fake()
git bisect skip 70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9
# skip: [f589be88caf32501a734e531180d5df5d6089ef3] drm/nouveau/pageflip: kick 
flip handling out of engsw and into fence
git bisect skip f589be88caf32501a734e531180d5df5d6089ef3
# skip: [73a60c0d218a292f8ef29d3467726ff26ed366fc] drm/nouveau/gpuobj: remove 
flags for vm-mappings
git bisect skip 73a60c0d218a292f8ef29d3467726ff26ed366fc
# skip: [70790f4f819875e8f390871fd15bbbf823f28e1b] drm/nouveau/clock: pull in 
the implementation from all over the place
git bisect skip 70790f4f819875e8f390871fd15bbbf823f28e1b
# skip: [5787640db6ae722aeadb394d480c7ca21b603e34] drm/nv04-nv40/instmem: 
remove use of nouveau_gpuobj_new_fake()
git bisect skip 5787640db6ae722aeadb394d480c7ca21b603e34
# skip: [cb75d97e9c77743ecfcc43375be135a55a4d9b25] drm/nouveau: implement 
devinit subdev, and new init table parser
git bisect skip cb75d97e9c77743ecfcc43375be135a55a4d9b25
# skip: [8a9b889e668a5bc2f4031015fe4893005c43403d] drm/nouveau: remove last use 
of nouveau_gpuobj_new_fake()
git bisect skip 8a9b889e668a5bc2f4031015fe4893005c43403d
# skip: [a73c5c526a8a39b2e61709c753d44be597c9a4c0] drm/nvc0-nve0/graph: rename 
dev to priv, no code changes
git bisect skip a73c5c526a8a39b2e61709c753d44be597c9a4c0
# good: [d6ba6d215a538a58f0f0026f0961b0b9125e8042] drm/nvc0/fence: restore 
pre-suspend fence buffer context on resume
git bisect good d6ba6d215a538a58f0f0026f0961b0b9125e8042
# skip: [7d9115dee978e8540734c456c925d71a37752b8d] drm/nouveau/mc: port to 
subdev interfaces
git bisect skip 7d9115dee978e8540734c456c925d71a37752b8d
# good: [3a92d37e4099054fe187b485a9d27c439c10eca7] drm/nouveau/gem: use 
bo.offset rather than mm_node.start
git bisect good 3a92d37e4099054fe187b485a9d27c439c10eca7
# skip: [5a5c7432bbbd2e318dff107b4ff960ab543a7cef] drm/nouveau/timer: port to 
subdev interfaces
git bisect skip 5a5c7432bbbd2e318dff107b4ff960ab543a7cef
# bad: [77145f1cbdf8d28b46ff8070ca749bad821e0774] drm/nouveau: port remainder 
of drm code, and rip out compat layer
git bisect bad 77145f1cbdf8d28b46ff8070ca749bad821e0774
# skip: [51a3d3425663698a79e8a9d01998a8a32ddee13b] drm/nouveau/backlight: 
remove dependence on nouveau_drv.h
git bisect skip 51a3d3425663698a79e8a9d01998a8a32ddee13b

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

Re: Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

On 2013-03-07 10:06 -0500, Nick Bowler wrote:
 I started a bisection... here's the first steps so far.  I will try to
 finish the procedure over the next couple days but I'm reporting this
 now in case someone needs me to get some other info.

I carried this on a bit further, but it seems that most of the remaining
commits bisect wants to test do not compile, so there is a huge number
of skipped commits.  Not exactly a lot of fun...

git bisect start 'drivers/gpu/drm'
# good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
# bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
# good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
# bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and PCH 
transcoders on lpt_pch_enable
git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
# good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add busmaster 
enable, regression fix
git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
# bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 'drm-fixes-3.7' 
of git://people.freedesktop.org/~agd5f/linux into drm-fixes
git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727
# bad: [b9f10852fcb1f09369d931dcbfbaad89ad1da4ad] drm/nv98/crypt: fix fuc build 
with latest envyas
git bisect bad b9f10852fcb1f09369d931dcbfbaad89ad1da4ad
# bad: [b10f20d590aa040e4028c04a70a27b9ad6650ba8] drm/nvc0-/gr: remove 
reset-after-grctx-construction hack
git bisect bad b10f20d590aa040e4028c04a70a27b9ad6650ba8
# skip: [18c9b959fd8ea6f3602efbedad788f53e305e6f1] drm/nouveau/gpuobj: create 
wrapper functions for mapping gpuobj into vm/bar
git bisect skip 18c9b959fd8ea6f3602efbedad788f53e305e6f1
# skip: [092599da308bf56b96c849ecdd315b8a1a13ca52] drm/nv50/instmem: remove use 
of nouveau_gpuobj_new_fake()
git bisect skip 092599da308bf56b96c849ecdd315b8a1a13ca52
# skip: [4196faa8623264b79279a06fd186654c959f2767] drm/nouveau/i2c: port to 
subdev interfaces
git bisect skip 4196faa8623264b79279a06fd186654c959f2767
# skip: [9da226f698c01b268b9172050df4150f269a7613] drm/nvc0/fifo: handle bar1 
control regs much like fifo/nve0
git bisect skip 9da226f698c01b268b9172050df4150f269a7613
# skip: [8aceb7de47ea2491abc1a577dc875b19e9947a54] drm/nouveau/clk: implement 
stub clock subdev
git bisect skip 8aceb7de47ea2491abc1a577dc875b19e9947a54
# skip: [70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9] drm/nv04-nv40/fifo: remove 
use of nouveau_gpuobj_new_fake()
git bisect skip 70ee6f1cd6911098ddd4c11ee21b69dbe51fb3f9
# skip: [f589be88caf32501a734e531180d5df5d6089ef3] drm/nouveau/pageflip: kick 
flip handling out of engsw and into fence
git bisect skip f589be88caf32501a734e531180d5df5d6089ef3
# skip: [73a60c0d218a292f8ef29d3467726ff26ed366fc] drm/nouveau/gpuobj: remove 
flags for vm-mappings
git bisect skip 73a60c0d218a292f8ef29d3467726ff26ed366fc
# skip: [70790f4f819875e8f390871fd15bbbf823f28e1b] drm/nouveau/clock: pull in 
the implementation from all over the place
git bisect skip 70790f4f819875e8f390871fd15bbbf823f28e1b
# skip: [5787640db6ae722aeadb394d480c7ca21b603e34] drm/nv04-nv40/instmem: 
remove use of nouveau_gpuobj_new_fake()
git bisect skip 5787640db6ae722aeadb394d480c7ca21b603e34
# skip: [cb75d97e9c77743ecfcc43375be135a55a4d9b25] drm/nouveau: implement 
devinit subdev, and new init table parser
git bisect skip cb75d97e9c77743ecfcc43375be135a55a4d9b25
# skip: [8a9b889e668a5bc2f4031015fe4893005c43403d] drm/nouveau: remove last use 
of nouveau_gpuobj_new_fake()
git bisect skip 8a9b889e668a5bc2f4031015fe4893005c43403d
# skip: [a73c5c526a8a39b2e61709c753d44be597c9a4c0] drm/nvc0-nve0/graph: rename 
dev to priv, no code changes
git bisect skip a73c5c526a8a39b2e61709c753d44be597c9a4c0
# good: [d6ba6d215a538a58f0f0026f0961b0b9125e8042] drm/nvc0/fence: restore 
pre-suspend fence buffer context on resume
git bisect good d6ba6d215a538a58f0f0026f0961b0b9125e8042
# skip: [7d9115dee978e8540734c456c925d71a37752b8d] drm/nouveau/mc: port to 
subdev interfaces
git bisect skip 7d9115dee978e8540734c456c925d71a37752b8d
# good: [3a92d37e4099054fe187b485a9d27c439c10eca7] drm/nouveau/gem: use 
bo.offset rather than mm_node.start
git bisect good 3a92d37e4099054fe187b485a9d27c439c10eca7
# skip: [5a5c7432bbbd2e318dff107b4ff960ab543a7cef] drm/nouveau/timer: port to 
subdev interfaces
git bisect skip 5a5c7432bbbd2e318dff107b4ff960ab543a7cef
# bad: [77145f1cbdf8d28b46ff8070ca749bad821e0774] drm/nouveau: port remainder 
of drm code, and rip out compat layer
git bisect bad 77145f1cbdf8d28b46ff8070ca749bad821e0774
# skip: [51a3d3425663698a79e8a9d01998a8a32ddee13b] drm/nouveau/backlight: 
remove dependence on nouveau_drv.h
git bisect skip 51a3d3425663698a79e8a9d01998a8a32ddee13b

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

Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

Hi folks,

Yesterday I upgraded one of my machines to 3.8.2 from 3.6.6.  This
machine has an old NV36 AGP board.  With the new kernel, as soon as
nouveau takes over the console the display connected via DVI goes dark
(the monitor goes into standby mode).  The display connected via VGA
continues to work fine.

Starting Xorg does not correct the problem.  Nouveau seems to know
that the display is connected:

  % cat /sys/class/drm/card0-DVI-I-1/status
  connected

I don't see anything unusual in the log either (full log attached):

  % dmesg -t | grep -iE 'drm|nouveau'
  [drm] Initialized drm 1.1.0 20060810
  nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x436200a1
  nouveau  [  DEVICE][:01:00.0] Chipset: NV36 (NV36)
  nouveau  [  DEVICE][:01:00.0] Family : NV30
  nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
  nouveau  [   VBIOS][:01:00.0] ... appears to be valid
  nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
  nouveau  [   VBIOS][:01:00.0] BMP version 5.28
  nouveau  [   VBIOS][:01:00.0] version 04.36.20.21
  nouveau W[  PTIMER][:01:00.0] unknown input clock freq
  nouveau  [ PFB][:01:00.0] RAM type: DDR1
  nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
  nouveau :01:00.0: putting AGP V3 device into 8x mode
  nouveau  [ DRM] VRAM: 255 MiB
  nouveau  [ DRM] GART: 64 MiB
  nouveau  [ DRM] BMP BIOS found
  nouveau  [ DRM] BMP version 5.40
  nouveau  [ DRM] Bios version 04.36.20.21
  nouveau  [ DRM] DCB version 2.2
  nouveau  [ DRM] DCB outp 00: 01000300 9c40
  nouveau  [ DRM] DCB outp 01: 02010310 9c40
  nouveau  [ DRM] DCB outp 02: 04000302 
  nouveau  [ DRM] DCB outp 03: 02020321 0303
  nouveau  [ DRM] Loading NV17 power sequencing microcode
  nouveau  [ DRM] Saving VGA fonts
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] No driver support for vblank timestamp query.
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] 0 available performance level(s)
  nouveau  [ DRM] c: core 425MHz memory 501MHz voltage 1350mV
  nouveau  [ DRM] MM: using M2MF for buffer copies
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 0)
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 1)
  nouveau  [ DRM] Setting dpms mode 3 on tmds encoder (output 2)
  nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 3)
  nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo 88007b6ae000
  fbcon: nouveaufb (fb0) is primary device
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] Setting dpms mode 0 on tmds encoder (output 2)
  nouveau  [ DRM] Output DVI-I-1 is running on CRTC 0 using output C
  nouveau  [ DRM] Setting dpms mode 0 on vga encoder (output 1)
  nouveau  [ DRM] Output VGA-1 is running on CRTC 1 using output B
  fb0: nouveaufb frame buffer device
  drm: registered panic notifier
  [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 0

I started a bisection... here's the first steps so far.  I will try to
finish the procedure over the next couple days but I'm reporting this
now in case someone needs me to get some other info.

  git bisect start 'drivers/gpu/drm'
  # good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
  git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
  # bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
  git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
  # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
  git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
  # bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and 
PCH transcoders on lpt_pch_enable
  git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
  # good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add 
busmaster enable, regression fix
  git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
  # bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 
'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
  git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727

Thanks,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
-- next part --
A non-text attachment was scrubbed...
Name: nouveau-black-lcd.log.xz
Type: application/x-xz
Size: 10880 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130307/56055089/attachment.bin>

Black screen with nouveau in 3.8.x (regression)

[Nick Bowler]

Hi folks,

Yesterday I upgraded one of my machines to 3.8.2 from 3.6.6.  This
machine has an old NV36 AGP board.  With the new kernel, as soon as
nouveau takes over the console the display connected via DVI goes dark
(the monitor goes into standby mode).  The display connected via VGA
continues to work fine.

Starting Xorg does not correct the problem.  Nouveau seems to know
that the display is connected:

  % cat /sys/class/drm/card0-DVI-I-1/status
  connected

I don't see anything unusual in the log either (full log attached):

  % dmesg -t | grep -iE 'drm|nouveau'
  [drm] Initialized drm 1.1.0 20060810
  nouveau  [  DEVICE][:01:00.0] BOOT0  : 0x436200a1
  nouveau  [  DEVICE][:01:00.0] Chipset: NV36 (NV36)
  nouveau  [  DEVICE][:01:00.0] Family : NV30
  nouveau  [   VBIOS][:01:00.0] checking PRAMIN for image...
  nouveau  [   VBIOS][:01:00.0] ... appears to be valid
  nouveau  [   VBIOS][:01:00.0] using image from PRAMIN
  nouveau  [   VBIOS][:01:00.0] BMP version 5.28
  nouveau  [   VBIOS][:01:00.0] version 04.36.20.21
  nouveau W[  PTIMER][:01:00.0] unknown input clock freq
  nouveau  [ PFB][:01:00.0] RAM type: DDR1
  nouveau  [ PFB][:01:00.0] RAM size: 256 MiB
  nouveau :01:00.0: putting AGP V3 device into 8x mode
  nouveau  [ DRM] VRAM: 255 MiB
  nouveau  [ DRM] GART: 64 MiB
  nouveau  [ DRM] BMP BIOS found
  nouveau  [ DRM] BMP version 5.40
  nouveau  [ DRM] Bios version 04.36.20.21
  nouveau  [ DRM] DCB version 2.2
  nouveau  [ DRM] DCB outp 00: 01000300 9c40
  nouveau  [ DRM] DCB outp 01: 02010310 9c40
  nouveau  [ DRM] DCB outp 02: 04000302 
  nouveau  [ DRM] DCB outp 03: 02020321 0303
  nouveau  [ DRM] Loading NV17 power sequencing microcode
  nouveau  [ DRM] Saving VGA fonts
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] No driver support for vblank timestamp query.
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] 0 available performance level(s)
  nouveau  [ DRM] c: core 425MHz memory 501MHz voltage 1350mV
  nouveau  [ DRM] MM: using M2MF for buffer copies
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 0)
  nouveau  [ DRM] Setting dpms mode 3 on vga encoder (output 1)
  nouveau  [ DRM] Setting dpms mode 3 on tmds encoder (output 2)
  nouveau  [ DRM] Setting dpms mode 3 on TV encoder (output 3)
  nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo 88007b6ae000
  fbcon: nouveaufb (fb0) is primary device
  nouveau  [ DRM] 0xE51A: Parsing digital output script table
  nouveau  [ DRM] Setting dpms mode 0 on tmds encoder (output 2)
  nouveau  [ DRM] Output DVI-I-1 is running on CRTC 0 using output C
  nouveau  [ DRM] Setting dpms mode 0 on vga encoder (output 1)
  nouveau  [ DRM] Output VGA-1 is running on CRTC 1 using output B
  fb0: nouveaufb frame buffer device
  drm: registered panic notifier
  [drm] Initialized nouveau 1.1.0 20120801 for :01:00.0 on minor 0

I started a bisection... here's the first steps so far.  I will try to
finish the procedure over the next couple days but I'm reporting this
now in case someone needs me to get some other info.

  git bisect start 'drivers/gpu/drm'
  # good: [3820288942d1c1524c3ee85cbf503fee1533cfc3] Linux 3.6.6
  git bisect good 3820288942d1c1524c3ee85cbf503fee1533cfc3
  # bad: [19b00d2dc9bedf0856e366cb7b9c7733ded659e4] Linux 3.8.2
  git bisect bad 19b00d2dc9bedf0856e366cb7b9c7733ded659e4
  # good: [a0d271cbfed1dd50278c6b06bead3d00ba0a88f9] Linux 3.6
  git bisect good a0d271cbfed1dd50278c6b06bead3d00ba0a88f9
  # bad: [daed2dbb7ea4d179e472396ce46377fe758d5faf] drm/i915: use the CPU and 
PCH transcoders on lpt_pch_enable
  git bisect bad daed2dbb7ea4d179e472396ce46377fe758d5faf
  # good: [df86b5765a48d5f557489577652bd6df145b0e1b] drm/savage: re-add 
busmaster enable, regression fix
  git bisect good df86b5765a48d5f557489577652bd6df145b0e1b
  # bad: [39df01cd6ce9f6dd755ace0030e2bebe75da7727] Merge branch 
'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
  git bisect bad 39df01cd6ce9f6dd755ace0030e2bebe75da7727

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


nouveau-black-lcd.log.xz
Description: application/xz
___
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-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

[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

[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

[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

[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

[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/)

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/)

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

[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

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
Detec

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

[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]

 AGP V3 device into 8x mode
[drm] nouveau :01:00.0: 64 MiB GART (aperture)
[drm] nouveau :01:00.0: Saving VGA fonts
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] nouveau_ttm_tt_populate+0xb9/0x194
PGD 0 
Oops: 0002 [#1] PREEMPT 
CPU 0 
Modules linked in:

Pid: 1, comm: swapper Not tainted 3.2.0-rc6-bisect-00099-g1fbe6f6 #60 ASUSTek 
Computer Inc. K8N-E-Deluxe/'K8N-E-Deluxe'
RIP: 0010:[]  [] 
nouveau_ttm_tt_populate+0xb9/0x194
RSP: 0018:88007d05d7e0  EFLAGS: 00010202
RAX: 7c061000 RBX: 88007d34cec0 RCX: 1000
RDX: ea0001b21558 RSI: 88007d05d8f0 RDI: 8149508d
RBP: 88007d05d820 R08:  R09: 
R10: 0001 R11: dead00100100 R12: 
R13:  R14: 88007d184000 R15: 
FS:  () GS:8161c000() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2:  CR3: 7d349000 CR4: 06f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process swapper (pid: 1, threadinfo 88007d05c000, task 88007d050ac0)
Stack:
 816520b8 01b63980 00c0 88007d34cec0
 88007c2002f8 88007d05d8f0 88007d05d800 
 88007d05d850 8119c59c 88007c2002f8 88007d05d8f0
Call Trace:
 [] ttm_tt_bind+0x2c/0x4f
 [] ttm_bo_handle_move_mem+0x110/0x29e
 [] ttm_bo_move_buffer+0xe9/0x124
 [] ? drm_mm_kmalloc+0x28/0xa5
 [] ttm_bo_validate+0xb2/0xed
 [] ttm_bo_init+0x360/0x399
 [] nouveau_bo_new+0x220/0x23a
 [] ? nouveau_ttm_tt_create+0x71/0x71
 [] ? nouveau_ramht_insert+0x225/0x32e
 [] nouveau_gem_new+0x55/0xe5
 [] ? nouveau_gpuobj_channel_init+0x637/0x68a
 [] nouveau_notifier_init_channel+0x5f/0x134
 [] nouveau_channel_alloc+0x1fd/0x568
 [] nouveau_card_init+0x134c/0x14be
 [] nouveau_load+0x5d8/0x61f
 [] drm_get_pci_dev+0x158/0x25d
 [] nouveau_pci_probe+0x10/0x12
 [] local_pci_probe+0x12/0x16
 [] pci_device_probe+0x65/0x96
 [] ? sysfs_create_link+0xe/0x10
 [] driver_probe_device+0xa3/0x131
 [] __driver_attach+0x58/0x7c
 [] ? driver_probe_device+0x131/0x131
 [] bus_for_each_dev+0x51/0x7d
 [] driver_attach+0x19/0x1b
 [] bus_add_driver+0xb2/0x206
 [] driver_register+0x96/0x103
 [] __pci_register_driver+0x47/0xb3
 [] drm_pci_init+0x85/0xea
 [] ? ttm_init+0x62/0x62
 [] ? ttm_init+0x62/0x62
 [] nouveau_init+0x4f/0x51
 [] do_one_initcall+0x78/0x126
 [] kernel_init+0x8b/0x10b
 [] ? schedule_tail+0x16/0x3d
 [] kernel_thread_helper+0x4/0x10
 [] ? start_kernel+0x31d/0x31d
 [] ? gs_change+0xb/0xb
Code: 88 00 00 00 48 8b 80 70 01 00 00 48 85 c0 75 0b eb 02 31 ff 48 8b 05 66 
c1 46 00 45 31 c9 45 31 c0 31 d2 b9 00 10 00 00 ff 50 10 
 89 07 48 8b 43 50 4a 8b 34 e8 49 8b 86 c0 02 00 00 48 89 c7 
RIP  [] nouveau_ttm_tt_populate+0xb9/0x194
 RSP 
CR2: 
---[ end trace eb6d24f9d33e5957 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G  D  3.2.0-rc6-bisect-00099-g1fbe6f6 #60
Call Trace:
 [] panic+0x9a/0x19e
 [] do_exit+0x8e/0x68c
 [] ? kmsg_dump+0xe5/0xf6
 [] oops_end+0x9d/0xa5
 [] no_context+0x1fd/0x20c
 [] ? change_page_attr_set_clr+0x265/0x335
 [] __bad_area_nosemaphore+0x1b0/0x1d0
 [] bad_area_nosemaphore+0xe/0x10
 [] do_page_fault+0x173/0x36e
 [] ? ns_capable+0x43/0x58
 [] ? ttm_mem_global_alloc_zone.clone.3+0x126/0x148
 [] ? ttm_mem_global_alloc_page+0x50/0x52
 [] page_fault+0x1f/0x30
 [] ? nouveau_ttm_tt_populate+0xb9/0x194
 [] ttm_tt_bind+0x2c/0x4f
 [] ttm_bo_handle_move_mem+0x110/0x29e
 [] ttm_bo_move_buffer+0xe9/0x124
 [] ? drm_mm_kmalloc+0x28/0xa5
 [] ttm_bo_validate+0xb2/0xed
 [] ttm_bo_init+0x360/0x399
 [] nouveau_bo_new+0x220/0x23a
 [] ? nouveau_ttm_tt_create+0x71/0x71
 [] ? nouveau_ramht_insert+0x225/0x32e
 [] nouveau_gem_new+0x55/0xe5
 [] ? nouveau_gpuobj_channel_init+0x637/0x68a
 [] nouveau_notifier_init_channel+0x5f/0x134
 [] nouveau_channel_alloc+0x1fd/0x568
 [] nouveau_card_init+0x134c/0x14be
 [] nouveau_load+0x5d8/0x61f
 [] drm_get_pci_dev+0x158/0x25d
 [] nouveau_pci_probe+0x10/0x12
 [] local_pci_probe+0x12/0x16
 [] pci_device_probe+0x65/0x96
 [] ? sysfs_create_link+0xe/0x10
 [] driver_probe_device+0xa3/0x131
 [] __driver_attach+0x58/0x7c
 [] ? driver_probe_device+0x131/0x131
 [] bus_for_each_dev+0x51/0x7d
 [] driver_attach+0x19/0x1b
 [] bus_add_driver+0xb2/0x206
 [] driver_register+0x96/0x103
 [] __pci_register_driver+0x47/0xb3
 [] drm_pci_init+0x85/0xea
 [] ? ttm_init+0x62/0x62
 [] ? ttm_init+0x62/0x62
 [] nouveau_init+0x4f/0x51
 [] do_one_initcall+0x78/0x126
 [] kernel_init+0x8b/0x10b
 [] ? schedule_tail+0x16/0x3d
 [] kernel_thread_helper+0x4/0x10
 [] ? start_kernel+0x31d/0x31d
 [] ? gs_change+0xb/0xb

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

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]

] nouveau_notifier_init_channel+0x5f/0x134
 [811a7945] nouveau_channel_alloc+0x1fd/0x568
 [811a6569] nouveau_card_init+0x134c/0x14be
 [811a6d93] nouveau_load+0x5d8/0x61f
 [8118f723] drm_get_pci_dev+0x158/0x25d
 [81301f3e] nouveau_pci_probe+0x10/0x12
 [8111854b] local_pci_probe+0x12/0x16
 [811187b5] pci_device_probe+0x65/0x96
 [810dedf1] ? sysfs_create_link+0xe/0x10
 [81224ae1] driver_probe_device+0xa3/0x131
 [81224bc7] __driver_attach+0x58/0x7c
 [81224b6f] ? driver_probe_device+0x131/0x131
 [81223dd4] bus_for_each_dev+0x51/0x7d
 [812247e4] driver_attach+0x19/0x1b
 [81224470] bus_add_driver+0xb2/0x206
 [81224f1a] driver_register+0x96/0x103
 [81118a24] __pci_register_driver+0x47/0xb3
 [8118f8ad] drm_pci_init+0x85/0xea
 [8167c30f] ? ttm_init+0x62/0x62
 [8167c30f] ? ttm_init+0x62/0x62
 [8167c35e] nouveau_init+0x4f/0x51
 [810002e2] do_one_initcall+0x78/0x126
 [8165ab3a] kernel_init+0x8b/0x10b
 [81025bd9] ? schedule_tail+0x16/0x3d
 [81306cc4] kernel_thread_helper+0x4/0x10
 [8165aaaf] ? start_kernel+0x31d/0x31d
 [81306cc0] ? gs_change+0xb/0xb

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-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

Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

On 2012-04-03 21:27 -0400, Nick Bowler wrote:
> CCing Tom Bylander as he sent me a mail off-list saying he experiences
> a similar issue on an FX 5200.
> 
> Tom, maybe you'll have better luck bisecting this than I did?
> 
> On 2012-03-19 10:35 -0400, Nick Bowler wrote:
> > Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
> > on my card w/ nouveau is totally black (both at the console and in X).
> > Almost everything appears to work normally: DPMS works, modesetting
> > works, DDC works... all messages indicate that things are working --
> > just the image is completely black.
> 
> OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master).  I
> captured the dmesg output before (3.2.13, which is a working kernel),
> and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical
> manner).  All three logs are attached in full (gzipped).

Ping?  I'm still seeing this on 3.4-rc3+.  Is there any other info that
I need to provide?

> One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log
> that occurs early and did not appear in either of the other logs:
> 
> [ cut here ]
> WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60
> pcibios_fwaddrmap_lookup+0x1d/0x3d()
> Hardware name: K8N-E-Deluxe
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47
> Call Trace:
>  [] warn_slowpath_common+0x80/0x98
>  [] warn_slowpath_null+0x15/0x17
>  [] pcibios_fwaddrmap_lookup+0x1d/0x3d
>  [] pcibios_allocate_resources+0xd4/0x217
>  [] ? pci_legacy_init+0x3e/0x3e
>  [] pcibios_resource_survey+0x17/0x2d
>  [] pcibios_init+0x28/0x3a
>  [] pci_subsys_init+0x47/0x4d
>  [] do_one_initcall+0x78/0x126
>  [] kernel_init+0xe9/0x17a
>  [] ? rdinit_setup+0x28/0x28
>  [] kernel_thread_helper+0x4/0x10
>  [] ? start_kernel+0x321/0x321
>  [] ? gs_change+0xb/0xb
> ---[ end trace 4eaa2a86a8e2da22 ]---
> 
> Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped
> for nouveau-related differences.  I see no obvious errors, but I admit
> that I don't really know what to look for.
> 
> % diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]'
> 
> @@ -418,19 +429,21 @@
>  Real Time Clock Driver v1.12b
>  Linux agpgart interface v0.103
>  [drm] Initialized drm 1.1.0 20060810
> +VGA switcheroo: detected Optimus DSM method \ handle
>  ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
> -nouveau :01:00.0: PCI INT A -> Link[LNKE] -> GSI 19 (level, low) -> IRQ 
> 19
>  [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1)
> -[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
> +[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
>  [drm] nouveau :01:00.0: ... appears to be valid
> +[drm] nouveau :01:00.0: Using VBIOS from PRAMIN
>  [drm] nouveau :01:00.0: BMP BIOS found
>  [drm] nouveau :01:00.0: BMP version 5.40
>  [drm] nouveau :01:00.0: Bios version 04.36.20.21
> -[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2
> -[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40
> -[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40
> -[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 
> -[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303
> +[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
> +[drm] nouveau :01:00.0: DCB version 2.2
> +[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40
> +[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40
> +[drm] nouveau :01:00.0: DCB outp 02: 04000302 
> +[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303
>  [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
> @@ -439,11 +452,10 @@
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
>  [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959
> -[drm] nouveau :01:00.0: 0 available performance level(s)
> -[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
> -[TTM] Zone  kernel: Available graphics memory: 512160 kiB.
> -[TTM] Initializing pool allocator.
> -[drm] nouveau :01:00.0: Detected 256MiB VRAM
> +[TTM] Zone  kernel: Available graphics memory: 512142 kiB
> +[TTM] Initializing pool allocator
> +[TTM] Initializing DMA pool allocator
> +[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1)
>  agpgart-amd64 :00:00.0: AGP 3.0 bridge
>  

Re: Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

On 2012-04-03 21:27 -0400, Nick Bowler wrote:
 CCing Tom Bylander as he sent me a mail off-list saying he experiences
 a similar issue on an FX 5200.
 
 Tom, maybe you'll have better luck bisecting this than I did?
 
 On 2012-03-19 10:35 -0400, Nick Bowler wrote:
  Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
  on my card w/ nouveau is totally black (both at the console and in X).
  Almost everything appears to work normally: DPMS works, modesetting
  works, DDC works... all messages indicate that things are working --
  just the image is completely black.
 
 OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master).  I
 captured the dmesg output before (3.2.13, which is a working kernel),
 and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical
 manner).  All three logs are attached in full (gzipped).

Ping?  I'm still seeing this on 3.4-rc3+.  Is there any other info that
I need to provide?

 One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log
 that occurs early and did not appear in either of the other logs:
 
 [ cut here ]
 WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60
 pcibios_fwaddrmap_lookup+0x1d/0x3d()
 Hardware name: K8N-E-Deluxe
 Modules linked in:
 Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47
 Call Trace:
  [81026baf] warn_slowpath_common+0x80/0x98
  [81026bdc] warn_slowpath_null+0x15/0x17
  [8129f79f] pcibios_fwaddrmap_lookup+0x1d/0x3d
  [81687306] pcibios_allocate_resources+0xd4/0x217
  [81688447] ? pci_legacy_init+0x3e/0x3e
  [81687460] pcibios_resource_survey+0x17/0x2d
  [81688dfd] pcibios_init+0x28/0x3a
  [8168848e] pci_subsys_init+0x47/0x4d
  [810002e2] do_one_initcall+0x78/0x126
  [81662bab] kernel_init+0xe9/0x17a
  [8166248a] ? rdinit_setup+0x28/0x28
  [8131ac44] kernel_thread_helper+0x4/0x10
  [81662ac2] ? start_kernel+0x321/0x321
  [8131ac40] ? gs_change+0xb/0xb
 ---[ end trace 4eaa2a86a8e2da22 ]---
 
 Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped
 for nouveau-related differences.  I see no obvious errors, but I admit
 that I don't really know what to look for.
 
 % diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]'
 
 @@ -418,19 +429,21 @@
  Real Time Clock Driver v1.12b
  Linux agpgart interface v0.103
  [drm] Initialized drm 1.1.0 20060810
 +VGA switcheroo: detected Optimus DSM method \ handle
  ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
 -nouveau :01:00.0: PCI INT A - Link[LNKE] - GSI 19 (level, low) - IRQ 
 19
  [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1)
 -[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
 +[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
  [drm] nouveau :01:00.0: ... appears to be valid
 +[drm] nouveau :01:00.0: Using VBIOS from PRAMIN
  [drm] nouveau :01:00.0: BMP BIOS found
  [drm] nouveau :01:00.0: BMP version 5.40
  [drm] nouveau :01:00.0: Bios version 04.36.20.21
 -[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2
 -[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40
 -[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40
 -[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 
 -[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303
 +[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
 +[drm] nouveau :01:00.0: DCB version 2.2
 +[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40
 +[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40
 +[drm] nouveau :01:00.0: DCB outp 02: 04000302 
 +[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303
  [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode
  [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
  [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
 @@ -439,11 +452,10 @@
  [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
  [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
  [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959
 -[drm] nouveau :01:00.0: 0 available performance level(s)
 -[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
 -[TTM] Zone  kernel: Available graphics memory: 512160 kiB.
 -[TTM] Initializing pool allocator.
 -[drm] nouveau :01:00.0: Detected 256MiB VRAM
 +[TTM] Zone  kernel: Available graphics memory: 512142 kiB
 +[TTM] Initializing pool allocator
 +[TTM] Initializing DMA pool allocator
 +[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1)
  agpgart-amd64 :00:00.0: AGP 3.0 bridge
  agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
  agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
 @@ -452,11 +464,14 @@
  [drm] nouveau :01:00.0

Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

CCing Tom Bylander as he sent me a mail off-list saying he experiences
a similar issue on an FX 5200.

Tom, maybe you'll have better luck bisecting this than I did?

On 2012-03-19 10:35 -0400, Nick Bowler wrote:
> Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
> on my card w/ nouveau is totally black (both at the console and in X).
> Almost everything appears to work normally: DPMS works, modesetting
> works, DDC works... all messages indicate that things are working --
> just the image is completely black.

OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master).  I
captured the dmesg output before (3.2.13, which is a working kernel),
and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical
manner).  All three logs are attached in full (gzipped).

One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log
that occurs early and did not appear in either of the other logs:

[ cut here ]
WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60
pcibios_fwaddrmap_lookup+0x1d/0x3d()
Hardware name: K8N-E-Deluxe
Modules linked in:
Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47
Call Trace:
 [] warn_slowpath_common+0x80/0x98
 [] warn_slowpath_null+0x15/0x17
 [] pcibios_fwaddrmap_lookup+0x1d/0x3d
 [] pcibios_allocate_resources+0xd4/0x217
 [] ? pci_legacy_init+0x3e/0x3e
 [] pcibios_resource_survey+0x17/0x2d
 [] pcibios_init+0x28/0x3a
 [] pci_subsys_init+0x47/0x4d
 [] do_one_initcall+0x78/0x126
 [] kernel_init+0xe9/0x17a
 [] ? rdinit_setup+0x28/0x28
 [] kernel_thread_helper+0x4/0x10
 [] ? start_kernel+0x321/0x321
 [] ? gs_change+0xb/0xb
---[ end trace 4eaa2a86a8e2da22 ]---

Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped
for nouveau-related differences.  I see no obvious errors, but I admit
that I don't really know what to look for.

% diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]'

@@ -418,19 +429,21 @@
 Real Time Clock Driver v1.12b
 Linux agpgart interface v0.103
 [drm] Initialized drm 1.1.0 20060810
+VGA switcheroo: detected Optimus DSM method \ handle
 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
-nouveau :01:00.0: PCI INT A -> Link[LNKE] -> GSI 19 (level, low) -> IRQ 19
 [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1)
-[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
+[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
 [drm] nouveau :01:00.0: ... appears to be valid
+[drm] nouveau :01:00.0: Using VBIOS from PRAMIN
 [drm] nouveau :01:00.0: BMP BIOS found
 [drm] nouveau :01:00.0: BMP version 5.40
 [drm] nouveau :01:00.0: Bios version 04.36.20.21
-[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2
-[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40
-[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40
-[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 
-[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303
+[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
+[drm] nouveau :01:00.0: DCB version 2.2
+[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40
+[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40
+[drm] nouveau :01:00.0: DCB outp 02: 04000302 
+[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303
 [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode
 [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
 [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
@@ -439,11 +452,10 @@
 [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
 [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
 [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959
-[drm] nouveau :01:00.0: 0 available performance level(s)
-[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
-[TTM] Zone  kernel: Available graphics memory: 512160 kiB.
-[TTM] Initializing pool allocator.
-[drm] nouveau :01:00.0: Detected 256MiB VRAM
+[TTM] Zone  kernel: Available graphics memory: 512142 kiB
+[TTM] Initializing pool allocator
+[TTM] Initializing DMA pool allocator
+[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1)
 agpgart-amd64 :00:00.0: AGP 3.0 bridge
 agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
 agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
@@ -452,11 +464,14 @@
 [drm] nouveau :01:00.0: Saving VGA fonts
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] No driver support for vblank timestamp query.
+[drm] nouveau :01:00.0: 0 available performance level(s)
+[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
+[drm] nouveau :01:00.0: 0xE51A: Parsing digital output script table
 [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0)
 [drm] nouve

Re: Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

CCing Tom Bylander as he sent me a mail off-list saying he experiences
a similar issue on an FX 5200.

Tom, maybe you'll have better luck bisecting this than I did?

On 2012-03-19 10:35 -0400, Nick Bowler wrote:
 Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
 on my card w/ nouveau is totally black (both at the console and in X).
 Almost everything appears to work normally: DPMS works, modesetting
 works, DDC works... all messages indicate that things are working --
 just the image is completely black.

OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master).  I
captured the dmesg output before (3.2.13, which is a working kernel),
and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical
manner).  All three logs are attached in full (gzipped).

One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log
that occurs early and did not appear in either of the other logs:

[ cut here ]
WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60
pcibios_fwaddrmap_lookup+0x1d/0x3d()
Hardware name: K8N-E-Deluxe
Modules linked in:
Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47
Call Trace:
 [81026baf] warn_slowpath_common+0x80/0x98
 [81026bdc] warn_slowpath_null+0x15/0x17
 [8129f79f] pcibios_fwaddrmap_lookup+0x1d/0x3d
 [81687306] pcibios_allocate_resources+0xd4/0x217
 [81688447] ? pci_legacy_init+0x3e/0x3e
 [81687460] pcibios_resource_survey+0x17/0x2d
 [81688dfd] pcibios_init+0x28/0x3a
 [8168848e] pci_subsys_init+0x47/0x4d
 [810002e2] do_one_initcall+0x78/0x126
 [81662bab] kernel_init+0xe9/0x17a
 [8166248a] ? rdinit_setup+0x28/0x28
 [8131ac44] kernel_thread_helper+0x4/0x10
 [81662ac2] ? start_kernel+0x321/0x321
 [8131ac40] ? gs_change+0xb/0xb
---[ end trace 4eaa2a86a8e2da22 ]---

Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped
for nouveau-related differences.  I see no obvious errors, but I admit
that I don't really know what to look for.

% diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]'

@@ -418,19 +429,21 @@
 Real Time Clock Driver v1.12b
 Linux agpgart interface v0.103
 [drm] Initialized drm 1.1.0 20060810
+VGA switcheroo: detected Optimus DSM method \ handle
 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
-nouveau :01:00.0: PCI INT A - Link[LNKE] - GSI 19 (level, low) - IRQ 19
 [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1)
-[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
+[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS
 [drm] nouveau :01:00.0: ... appears to be valid
+[drm] nouveau :01:00.0: Using VBIOS from PRAMIN
 [drm] nouveau :01:00.0: BMP BIOS found
 [drm] nouveau :01:00.0: BMP version 5.40
 [drm] nouveau :01:00.0: Bios version 04.36.20.21
-[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2
-[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40
-[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40
-[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 
-[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303
+[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do
+[drm] nouveau :01:00.0: DCB version 2.2
+[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40
+[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40
+[drm] nouveau :01:00.0: DCB outp 02: 04000302 
+[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303
 [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode
 [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D
 [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1
@@ -439,11 +452,10 @@
 [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3
 [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0
 [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959
-[drm] nouveau :01:00.0: 0 available performance level(s)
-[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV
-[TTM] Zone  kernel: Available graphics memory: 512160 kiB.
-[TTM] Initializing pool allocator.
-[drm] nouveau :01:00.0: Detected 256MiB VRAM
+[TTM] Zone  kernel: Available graphics memory: 512142 kiB
+[TTM] Initializing pool allocator
+[TTM] Initializing DMA pool allocator
+[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1)
 agpgart-amd64 :00:00.0: AGP 3.0 bridge
 agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode.
 agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode
@@ -452,11 +464,14 @@
 [drm] nouveau :01:00.0: Saving VGA fonts
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] No driver support for vblank timestamp query.
+[drm] nouveau :01:00.0: 0 available performance level(s)
+[drm] nouveau :01:00.0: c: core 425MHz

Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

Hi folks,

Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
on my card w/ nouveau is totally black (both at the console and in X).
Almost everything appears to work normally: DPMS works, modesetting
works, DDC works... all messages indicate that things are working --
just the image is completely black.

The VGA is one of two outputs in use: the other (DVI) output works
normally.  The card also has an unused TV-out port, FWIW.

The card is an NV36 generation (Geforce FX5700 AGP).  This is a
regression from Linux 3.2 -- unfortunately, bisection has proved
extremely difficult because the intermediate kernels git is asking me
to test panic immediately on boot (and compiling Linux takes a fairly
long time on this box too).  The failed attempt went like this:

  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

  (I stopped at this point)

I'm running the latest git xf86-video-nouveau, but since the issue
occurs at the console it's probably not too important...

Let me know if you need any more info,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Regression: black screen on VGA w/ nouveau in Linux 3.3

[Nick Bowler]

Hi folks,

Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output
on my card w/ nouveau is totally black (both at the console and in X).
Almost everything appears to work normally: DPMS works, modesetting
works, DDC works... all messages indicate that things are working --
just the image is completely black.

The VGA is one of two outputs in use: the other (DVI) output works
normally.  The card also has an unused TV-out port, FWIW.

The card is an NV36 generation (Geforce FX5700 AGP).  This is a
regression from Linux 3.2 -- unfortunately, bisection has proved
extremely difficult because the intermediate kernels git is asking me
to test panic immediately on boot (and compiling Linux takes a fairly
long time on this box too).  The failed attempt went like this:

  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

  (I stopped at this point)

I'm running the latest git xf86-video-nouveau, but since the issue
occurs at the console it's probably not too important...

Let me know if you need any more info,
-- 
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

Regression: Borked display on second output with Intel G45 in 3.0-rc2

[Nick Bowler]

On 2011-06-06 19:20 +0200, Melchior FRANZ wrote:
> * Nick Bowler -- Monday 06 June 2011:
> > After upgrading to 3.0-rc2, my second display is no longer working
> > correctly on a desktop with an Intel G45 graphics chip.
> [...]
> > What I do know is that the problem was originally introduced by
> > 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> > base (pre-ILK)").  It was subsequently fixed by 982b2035d9d7 ("Revert
> > "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> > The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
> 
> That's apparently the bug that I've submitted a patch for on 2011/5/31:
> https://lkml.org/lkml/2011/5/31/393
> I assume/hope it's still in someone's queue.

Yup, that fixes it right up, thanks.

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

Regression: Borked display on second output with Intel G45 in 3.0-rc2

[Nick Bowler]

After upgrading to 3.0-rc2, my second display is no longer working
correctly on a desktop with an Intel G45 graphics chip.  The system has
two displays, one connected by HDMI and the other by VGA.

Both displays work fine in the console; the troubles begin after
starting X.  It *looks* as if one of the displays is still scanning out
from the old framebuffer: what I see on the VGA monitor after starting X
is a black screen with a console cursor at the top -- this is just like
an empty VT except that the cursor is not blinking.  If I switch to VT 1
and then back to X, the display contains all the bootup text that was on
VT 1.  In any case, the mouse cursor works properly on the display.
There are no unusual messages in dmesg or the Xorg log in any case.

If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1
--same-as HDMI1 && xrandr --output VGA1 --right-of VGA1) , it's possible
to get both displays showing the right thing.  But then if I switch back
to the console, I end up with one display showing the console text and
the other is still showing my X session!  (In this instance, the VGA was
working and the HDMI was showing the wrong thing).

This is a regression from 2.6.39, but that's not the whole story: this
problem appears to have been introduced very briefly late in the 2.6.39
-rc cycle and subsequently fixed on mainline.  It then reappeared during
the 3.0 merge window.  Unfortunately, this fact seems to make it
impossible to bisect to a specific commit.

What I do know is that the problem was originally introduced by
49183b2818de ("drm/i915: Only enable the plane after setting the fb
base (pre-ILK)").  It was subsequently fixed by 982b2035d9d7 ("Revert
"drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
Unfortunately, I cannot be more specific than that because it appears
that the entire drm side of that merge consists of 'bad' commits and git
bisect gets very confused.

Let me know if you need any more info,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Regression: Borked display on second output with Intel G45 in 3.0-rc2

[Nick Bowler]

After upgrading to 3.0-rc2, my second display is no longer working
correctly on a desktop with an Intel G45 graphics chip.  The system has
two displays, one connected by HDMI and the other by VGA.

Both displays work fine in the console; the troubles begin after
starting X.  It *looks* as if one of the displays is still scanning out
from the old framebuffer: what I see on the VGA monitor after starting X
is a black screen with a console cursor at the top -- this is just like
an empty VT except that the cursor is not blinking.  If I switch to VT 1
and then back to X, the display contains all the bootup text that was on
VT 1.  In any case, the mouse cursor works properly on the display.
There are no unusual messages in dmesg or the Xorg log in any case.

If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1
--same-as HDMI1  xrandr --output VGA1 --right-of VGA1) , it's possible
to get both displays showing the right thing.  But then if I switch back
to the console, I end up with one display showing the console text and
the other is still showing my X session!  (In this instance, the VGA was
working and the HDMI was showing the wrong thing).

This is a regression from 2.6.39, but that's not the whole story: this
problem appears to have been introduced very briefly late in the 2.6.39
-rc cycle and subsequently fixed on mainline.  It then reappeared during
the 3.0 merge window.  Unfortunately, this fact seems to make it
impossible to bisect to a specific commit.

What I do know is that the problem was originally introduced by
49183b2818de (drm/i915: Only enable the plane after setting the fb
base (pre-ILK)).  It was subsequently fixed by 982b2035d9d7 (Revert
drm/i915: Only enable the plane after setting the fb base (pre-ILK)).
The problem was reintroduced by 98b98d316349 (Merge branch 'drm-core-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6).
Unfortunately, I cannot be more specific than that because it appears
that the entire drm side of that merge consists of 'bad' commits and git
bisect gets very confused.

Let me know if you need any more info,
-- 
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: Regression: Borked display on second output with Intel G45 in 3.0-rc2

[Nick Bowler]

On 2011-06-06 19:20 +0200, Melchior FRANZ wrote:
 * Nick Bowler -- Monday 06 June 2011:
  After upgrading to 3.0-rc2, my second display is no longer working
  correctly on a desktop with an Intel G45 graphics chip.
 [...]
  What I do know is that the problem was originally introduced by
  49183b2818de (drm/i915: Only enable the plane after setting the fb
  base (pre-ILK)).  It was subsequently fixed by 982b2035d9d7 (Revert
  drm/i915: Only enable the plane after setting the fb base (pre-ILK)).
  The problem was reintroduced by 98b98d316349 (Merge branch 'drm-core-next'
  of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6).
 
 That's apparently the bug that I've submitted a patch for on 2011/5/31:
 https://lkml.org/lkml/2011/5/31/393
 I assume/hope it's still in someone's queue.

Yup, that fixes it right up, 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

[2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU hung (not reproducible)

[Nick Bowler]

On Sun, 27 Feb 2011 10:10:41 +0100 Paolo Ornati  wrote:
> Today I got this while starting a video in SMplayer (MPlayer) with
> 2.6.38-rc6-00113-g4662db4:

> > [  830.880014] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
> > elapsed... GPU hung
> > [  830.880736] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request 
> > returns -11 (awaiting 174895 at 174857, next 174896)
> > [  830.881093] [drm:init_ring_common] *ERROR* render ring initialization 
> > failed ctl  head  tail  start 
> > [  831.379079] [drm:i915_do_wait_request] *ERROR* something (likely 
> > vbetool) disabled interrupts, re-enabling
> > [  831.399099] [drm:i915_do_wait_request] *ERROR* something (likely 
> > vbetool) disabled interrupts, re-enabling

I was experiencing intermittent hangs when starting mplayer earlier in
this release cycle (on both a desktop with a G45 and a laptop with a
GM45), but I haven't encountered them in quite a while.  I don't know if
they looked exactly like the above since all the hangs have been rotated
out of my logs :(.  I ended up concluding that it was actually a
regression in xf86-video-intel rather than the kernel (but no real way
of testing this), since there was a lot of Xv related churn in the
driver around the time I was having the issues.

So you might want to try again with the latest git xf86-video-intel and
see if it still happens.

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

Re: [2.6.38-rc6] G965: i915 Hangcheck timer elapsed... GPU hung (not reproducible)

[Nick Bowler]

On Sun, 27 Feb 2011 10:10:41 +0100 Paolo Ornati orn...@gmail.com wrote:
 Today I got this while starting a video in SMplayer (MPlayer) with
 2.6.38-rc6-00113-g4662db4:

  [  830.880014] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
  elapsed... GPU hung
  [  830.880736] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request 
  returns -11 (awaiting 174895 at 174857, next 174896)
  [  830.881093] [drm:init_ring_common] *ERROR* render ring initialization 
  failed ctl  head  tail  start 
  [  831.379079] [drm:i915_do_wait_request] *ERROR* something (likely 
  vbetool) disabled interrupts, re-enabling
  [  831.399099] [drm:i915_do_wait_request] *ERROR* something (likely 
  vbetool) disabled interrupts, re-enabling

I was experiencing intermittent hangs when starting mplayer earlier in
this release cycle (on both a desktop with a G45 and a laptop with a
GM45), but I haven't encountered them in quite a while.  I don't know if
they looked exactly like the above since all the hangs have been rotated
out of my logs :(.  I ended up concluding that it was actually a
regression in xf86-video-intel rather than the kernel (but no real way
of testing this), since there was a lot of Xv related churn in the
driver around the time I was having the issues.

So you might want to try again with the latest git xf86-video-intel and
see if it still happens.

-- 
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

i915: display doesn't get on back after returning from standby in 2.6.27-rc*

[Nick Bowler]

On 2010-11-25 11:31 -0800, Keith Packard wrote:
> On Thu, 25 Nov 2010 11:10:58 -0500, Nick Bowler  
> wrote:
[...]
> >   https://bugs.freedesktop.org/show_bug.cgi?id=31803
> 
> I've provided a couple of fixes that might be relevant here -- neither
> kernel nor user mode were setting the tracked DPMS state of the outputs
> to ON when doing mode setting, which caused all kinds of comedy. These
> should fix 23472 and 31803. I'm not entirely sure what's up with 23122,
> but it's possible that it's the same issue.
> 
> The user mode DPMS tracking fix is in xf86-video-intel master, the
> kernel DPMS tracking fix was sent to Chris last week.

Hi Keith,

I had a chance to test your patches this weekend:

  drm: record monitor status in output_poll_execute
  drm: Set connector DPMS status to ON in drm_crtc_helper_set_config

cherry picked from ickle's repo on top of Linus' git 0f639a3c5ca6
("Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6").

Unfortunately, they do not correct my laptop backlight issue (fdo
bugzilla #31803): the panel still dims whenever the lid is opened.

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

i915: display doesn't get on back after returning from standby in 2.6.27-rc*

[Nick Bowler]

On 2010-11-25 16:58 +0100, Michal Hocko wrote:
> [Let's add Rafael for regression tracking]
> 
> On Tue 23-11-10 13:32:34, Michal Hocko wrote:
> > Hi,
> > since early 2.6.37 (I haven't bisected when exactly) my screen doesn't
> > get on after it got into standby mode. I have to either change to a
> > text console and back (if it gets to standby by the screen saver) or
> > close the lid on my laptop if I try:
> > xset dpms force standby
[...]
> > Is this a known issue?

I suspect that all of the following are the same issue:

  https://bugzilla.kernel.org/show_bug.cgi?id=23122
  https://bugzilla.kernel.org/show_bug.cgi?id=23472
  https://bugs.freedesktop.org/show_bug.cgi?id=31803

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

Re: i915: display doesn't get on back after returning from standby in 2.6.27-rc*

[Nick Bowler]

On 2010-11-25 16:58 +0100, Michal Hocko wrote:
 [Let's add Rafael for regression tracking]
 
 On Tue 23-11-10 13:32:34, Michal Hocko wrote:
  Hi,
  since early 2.6.37 (I haven't bisected when exactly) my screen doesn't
  get on after it got into standby mode. I have to either change to a
  text console and back (if it gets to standby by the screen saver) or
  close the lid on my laptop if I try:
  xset dpms force standby
[...]
  Is this a known issue?

I suspect that all of the following are the same issue:

  https://bugzilla.kernel.org/show_bug.cgi?id=23122
  https://bugzilla.kernel.org/show_bug.cgi?id=23472
  https://bugs.freedesktop.org/show_bug.cgi?id=31803

-- 
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

[PATCH 0/7] BKL removal follow-up

[Nick Bowler]

On 2010-11-21 09:45 -0800, Linus Torvalds wrote:
> Yes, I'd be ok with UDF doing a "select BKL" along with a "default n"
> for BKL itself.
> 
> I think UDF currently is the only sane reason to have BKL enabled any
> more, and yes, it would probably make it easier to configure things.

UFS (which I use) also relies on BKL.

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

Re: [PATCH 0/7] BKL removal follow-up

[Nick Bowler]

On 2010-11-21 09:45 -0800, Linus Torvalds wrote:
 Yes, I'd be ok with UDF doing a select BKL along with a default n
 for BKL itself.
 
 I think UDF currently is the only sane reason to have BKL enabled any
 more, and yes, it would probably make it easier to configure things.

UFS (which I use) also relies on BKL.

-- 
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

[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.

[Nick Bowler]

On 13:26 Mon 14 Jun , Justin P. Mattock wrote:
> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct 
> cpu_key *key,  /* Key to s
>  
>   pathrelse(search_path);
>  
> - right_neighbor_of_leaf_node = 0;
> -
> + 

This hunk introduces whitespace on the empty line, which is not cool.

>   /* With each iteration of this loop we search through the items in the
>  current node, and calculate the next current node(next path element)
>  for the next iteration of this loop.. */
> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct 
> cpu_key *key,  /* Key to s
>  starting from the root. */
>   block_number = SB_ROOT_BLOCK(sb);
>   expected_level = -1;
> - right_neighbor_of_leaf_node = 0;
> -
> + 

Here, too.

Most of the patches in this series have similar issues.

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

Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.

[Nick Bowler]

On 13:26 Mon 14 Jun , Justin P. Mattock wrote:
 @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct 
 cpu_key *key,  /* Key to s
  
   pathrelse(search_path);
  
 - right_neighbor_of_leaf_node = 0;
 -
 + 

This hunk introduces whitespace on the empty line, which is not cool.

   /* With each iteration of this loop we search through the items in the
  current node, and calculate the next current node(next path element)
  for the next iteration of this loop.. */
 @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct 
 cpu_key *key,  /* Key to s
  starting from the root. */
   block_number = SB_ROOT_BLOCK(sb);
   expected_level = -1;
 - right_neighbor_of_leaf_node = 0;
 -
 + 

Here, too.

Most of the patches in this series have similar issues.

-- 
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