Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

2013-03-18 Thread Greg Kroah-Hartman
On Thu, Mar 14, 2013 at 11:19:57PM +0100, Michael Leun wrote:
> Hello,
> 
> On Thu, 14 Mar 2013 21:36:24 +0100
> Arkadiusz Miskiewicz  wrote:
> 
> > After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
> [...]
> > 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
> 
> I also have an 3.8.2->3.8.3 regression which goes away with reverting
> the same patch - X comes up with 1024x768 instead of 1366x768.
> 
> Acer Aspire 1825PTZ
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
> Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
> Subsystem: Acer Incorporated [ALI] Device 0300
> 

Thanks for the report, I've reverted this patch, and another i915 patch
for the next 3.8-stable release, so all should be resolved then.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

2013-03-17 Thread Arkadiusz Miskiewicz
On Sunday 17 of March 2013, Daniel Vetter wrote:
> On Sat, Mar 16, 2013 at 11:35 AM, Arkadiusz Miskiewicz
> 
>  wrote:
> > On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
> >> Hello.
> > 
> >> After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
> > More people hits this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=922304
> > https://bugs.archlinux.org/task/34327
> > (seems always GM45 gpu in these reports)
> > 
> > archlinux people also noticed that xrandr reports VGA1 as connected
> > (while in reality nothing is connected to VGA1)
> 
> Can you please test whether 3.9-rc kernels are affected, too? 

3.9.0-rc2-00341-g0863702

works fine here

[0.349462] [drm] Initialized drm 1.1.0 20060810
[0.349566] [drm] radeon kernel modesetting enabled.
[0.350049] [drm] Memory usable by graphics device = 2048M
[0.350110] i915 :00:02.0: setting latency timer to 64
[0.374161] i915 :00:02.0: irq 47 for MSI/MSI-X
[0.374170] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[0.374229] [drm] Driver supports precise vblank timestamp query.
[0.436916] fbcon: inteldrmfb (fb0) is primary device
[0.983961] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[0.983996] i915 :00:02.0: registered panic notifier
[0.986191] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 
0

xrandr reports VGA-1 as disconnected properly

> We need
> to know this since stable rules mandate that a regression is fixed on
> upstream first. Once that's figured out we can backport a fix (if
> 3.9-rc works) or start working on a fix for 3.8-rc kernels first and
> backport afterwards.
> 
> Thanks, Daniel


-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

2013-03-17 Thread Daniel Vetter
On Sat, Mar 16, 2013 at 11:35 AM, Arkadiusz Miskiewicz
 wrote:
> On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
>> Hello.
>>
>> After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
>
> More people hits this:
> https://bugzilla.redhat.com/show_bug.cgi?id=922304
> https://bugs.archlinux.org/task/34327
> (seems always GM45 gpu in these reports)
>
> archlinux people also noticed that xrandr reports VGA1 as connected (while in
> reality nothing is connected to VGA1)

Can you please test whether 3.9-rc kernels are affected, too? We need
to know this since stable rules mandate that a regression is fixed on
upstream first. Once that's figured out we can backport a fix (if
3.9-rc works) or start working on a fix for 3.8-rc kernels first and
backport afterwards.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

2013-03-16 Thread Arkadiusz Miskiewicz
On Thursday 14 of March 2013, Arkadiusz Miskiewicz wrote:
> Hello.
> 
> After upgrading from 3.8.2 to 3.8.3 I'm getting regression :

More people hits this:
https://bugzilla.redhat.com/show_bug.cgi?id=922304
https://bugs.archlinux.org/task/34327
(seems always GM45 gpu in these reports)

archlinux people also noticed that xrandr reports VGA1 as connected (while in 
reality nothing is connected to VGA1)

[arekm@t400 ~]$ more xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 32767 x 32767
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm 
x 190mm
   1440x900   60.0*+   50.0  
   1024x768   60.0  
   800x60060.3 56.2  
   640x48059.9  
VGA1 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  
DP1 disconnected (normal left inverted right x axis y axis)

[arekm@t400 ~]$ xrandr --output VGA --mode 1440x900
warning: output VGA not found; ignoring


Normally this looks like:
[arekm@t400 ~]$ more xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 32767 x 32767  
 
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm 
x 190mm
   1440x900   60.0*+   50.0 
 
   1024x768   60.0  
 
   800x60060.3 56.2  
   640x48059.9  
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)

> 
> diff:
>   [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>   [drm] Driver supports precise vblank timestamp query.
>   vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem + [drm]
> GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
> fbcon: inteldrmfb (fb0) is primary device
> - Console: switching to colour frame buffer device 180x56
> + Console: switching to colour frame buffer device 128x48
>   i915 :00:02.0: fb0: inteldrmfb frame buffer device
>   i915 :00:02.0: registered panic notifier
>   acpi device:01: registered as cooling_device0
> 
> console becomes weird, ends up in 2/3 of screen, X when starts gets tiny
> fonts etc.
> 
> Machine is Thinkpad T400 with gm45 GPU
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series
> Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00
> [VGA controller]) Subsystem: Lenovo Device [17aa:2112]
> 
> Reverting bisected commit from 3.8.3 fixes the problem
> 
> 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
> commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
> Author: Daniel Vetter 
> Date:   Sat Dec 1 21:03:22 2012 +0100
> 
> drm/i915: reorder setup sequence to have irqs for output setup
> 
> commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.
> 
> Otherwise the new&shiny irq-driven gmbus and dp aux code won't work
> that well. Noticed since the dp aux code doesn't have an automatic
> fallback with a timeout (since the hw provides for that already).
> 
> v2: Simple move drm_irq_install before intel_modeset_gem_init, as
> suggested by Ben Widawsky.
> 
> v3: Now that interrupts are enabled before all connectors are fully
> set up, we might fall over serving a HPD interrupt while things are
> still being set up. Instead of jumping through massive hoops and
> complicating the code with a separate hpd irq enable step, simply
> block out the hotplug work item from doing anything until things are
> in place.
> 
> v4: Actually, we can enable hotplug processing only after the fbdev is
> fully set up, since we call down into the fbdev from the hotplug work
> functions. So stick the hpd enabling right next to the poll helper
> initialization.
> 
> v5: We need to enable irqs before intel_modeset_init, since that
> function sets up the outputs.
> 
> v6: Fixup cleanup sequence, too.
> 
> Reviewed-by: Imre Deak 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Greg Kroah-Hartman 
> 
> :04 04 26e83b14e8d49da8c451dc2c837646a337a79085
> :fa2cbfcf159808ce188675115888242245e4e69d M  drivers
> 
> relevant dmesg:
> 
>  [drm] Initialized drm 1.1.0 20060810
>  [drm] radeon defaulting to userspace modesetting.
>  i915 :00:02.0: setting latency timer to 64
>  i915 :00:02.0: irq 47 for MSI/MSI-X
>  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>  [drm] Driver supports precise vblank timestamp query.
>  [drm] GMBUS [i915 gmbus dpb] timed 

Re: 3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

2013-03-14 Thread Michael Leun
Hello,

On Thu, 14 Mar 2013 21:36:24 +0100
Arkadiusz Miskiewicz  wrote:

> After upgrading from 3.8.2 to 3.8.3 I'm getting regression :
[...]
> 2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit

I also have an 3.8.2->3.8.3 regression which goes away with reverting
the same patch - X comes up with 1024x768 instead of 1366x768.

Acer Aspire 1825PTZ

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 0300


-- 
MfG,

Michael Leun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


3.8.2->3.8.3 i915 regression: GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5

2013-03-14 Thread Arkadiusz Miskiewicz

Hello.

After upgrading from 3.8.2 to 3.8.3 I'm getting regression :

diff:
  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
  [drm] Driver supports precise vblank timestamp query.
  vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
+ [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
  fbcon: inteldrmfb (fb0) is primary device
- Console: switching to colour frame buffer device 180x56
+ Console: switching to colour frame buffer device 128x48
  i915 :00:02.0: fb0: inteldrmfb frame buffer device
  i915 :00:02.0: registered panic notifier
  acpi device:01: registered as cooling_device0

console becomes weird, ends up in 2/3 of screen, X when starts gets tiny fonts 
etc.

Machine is Thinkpad T400 with gm45 GPU
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Device [17aa:2112]

Reverting bisected commit from 3.8.3 fixes the problem

2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
Author: Daniel Vetter 
Date:   Sat Dec 1 21:03:22 2012 +0100

drm/i915: reorder setup sequence to have irqs for output setup

commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.

Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).

v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.

v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.

v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.

v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.

v6: Fixup cleanup sequence, too.

Reviewed-by: Imre Deak 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

:04 04 26e83b14e8d49da8c451dc2c837646a337a79085 
fa2cbfcf159808ce188675115888242245e4e69d M  drivers


relevant dmesg:

 [drm] Initialized drm 1.1.0 20060810
 [drm] radeon defaulting to userspace modesetting.
 i915 :00:02.0: setting latency timer to 64
 i915 :00:02.0: irq 47 for MSI/MSI-X
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
 fbcon: inteldrmfb (fb0) is primary device
 i915 :00:02.0: fb0: inteldrmfb frame buffer device
 i915 :00:02.0: registered panic notifier
 [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

-- 
Arkadiusz Miśkiewicz, arekm / maven.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/