Bug 17121
| Summary: | [GM45] Two blank rectangles more than 10 cm long when booting | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Eric Valette (eric.valette) |
| Component: | Video(DRI - Intel) | Assignee: | intel-gfx-bugs (intel-gfx-bugs) |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | airlied, alan, chris, daniel, florian, intel-gfx-bugs, jbarnes, maciej.rutecki, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.7.รจ | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 16444 | ||
| Attachments: |
photo shot of the problem
having a try at the maxpwm is zero acpidump dmesg kernel config Kernel config for 3.4.0 kernel 3.7.7 config dmesg dmesg with drm.debug=0xe set on boot line |
||
|
Description
Eric Valette
2010-08-26 17:24:11 UTC
Odd, can you grab a snapshot of the display whilst booting? The suspend regression I guess [from other reports] is due to the introduction of HAS_BSD(),does s2ram work if you #define HAS_BSD(dev) 0. I personally consider the suspend regression is fixed in this snapshot. I will try to shoot the problem via a camera. NB: while unpleasant while booting, this as no consequences on the functional behavior afterwards. I reported it, because, such things could mean wrong access to hardware bits that could have much more impact on other situation. I also can wait, as as far as I see there is a batch of the Intel drm tree queued for past rc3 and report if its not fixed once merged mainline. What do you prefer? Created attachment 29362 [details]
photo shot of the problem
Note that this is now with 2.6.36-rc3-git1 as I saw some intel video patch went in. 2.6.36-rc5-git5 is still affected. On Monday, September 27, 2010, Eric Valette wrote:
> On 26/09/2010 22:04, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.35. Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
> > Subject : Two blank rectangles more than 10 cm long when
> booting
> > Submitter : Eric Valette<eric.valette@free.fr>
> > Date : 2010-08-26 17:24 (32 days old)
> >
> >
>
> Still present on 2.6.36-rc5-git7.
Still present in 2.6.36-rc7-git2. BTW sometimes the whole switch to kernel framebuffer fails (screen goes somewhat very dark gray) and X does not restore the video. I suspect Linux is still running because if I blindly do <ctlr>-<alt>-<F1> and hit the power button twice it does shutdown Bug still there at 2.6.36. Frequency of screen staying black instead of displaying rectangle seems to have increased. Bug still in 2.6.36.1 and 2.6.37-rc4-git4 Side note, as I saw new regressions on 2.6.37 I wonder when the Intel driver is going to stabilise. In addition with Mesa being in complete transformation for Intel, life is a bit chaotic for Intel users. --eric have you got CONFIG_FRAMEBUFFER_CONSOLE? Of course and the picture attached do show the penguins... still there with 2.6.37-rc6 Still there at 2.6.37-rc7-git2. No way to try rc8 before monday. still present in rc8-git1.Extracted from dmesg. i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 i915 0000:00:02.0: setting latency timer to 64 i915 0000:00:02.0: irq 40 for MSI/MSI-X [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:01:00.0 [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. [drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero. Console: switching to colour frame buffer device 240x67 fb0: inteldrmfb frame buffer device drm: registered panic notifier [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness acpi device:03: registered as cooling_device2 input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/LNXVIDEO:00/input/input4 ACPI: Video Device [PEGP] (multi-head: yes rom: yes post: no) acpi device:06: registered as cooling_device3 input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input5 ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 Still a problem in 2.6.38.y? Yes. 2.6.38.2. Created attachment 61622 [details]
having a try at the maxpwm is zero
Hi,
I don't know about the rectangles, but from a a look at the 'max pwm is zero' message, it seems there is something weird in i915_read_blc_pwm_ctl ..
Can you test if the attached patch fixes the 'max pwm is zero' messages for you?
Regards,
Flo
Applied the diff manually. i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 i915 0000:00:02.0: setting latency timer to 64 i915 0000:00:02.0: irq 43 for MSI/MSI-X [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:01:00.0 fixme: max PWM is zero. fbcon: inteldrmfb (fb0) is primary device Console: switching to colour frame buffer device 240x67 fb0: inteldrmfb frame buffer device drm: registered panic notifier [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness Does not fix the rectangle either but for sure the code lokks strange and its probably a typo Thanks for proposing something. I wonder if it will be fixed one day. I do not care about rectangle but sometimes it hangs there especially on reboot. Forgot to say: still exist on 2.6.39.1 How behave the rectangles over time? Do they scroll away or vanish somehow, vary in shape/color or position? Also can you attach the output of acpidump ? Created attachment 61702 [details]
acpidump
> How behave the rectangles over time? Do they scroll away or vanish somehow, Yes. I have the two pingwins and the two rectangles like on attached screenshot. Then text of boot appears (or not depending on grub quiete option) and when the screen is full they vanish. > vary in shape/color or position? No. > Also can you attach the output of acpidump ? done. Note that his laptop has two graphic cards but I'm using only Intel one and not nvidia one in this config. Hmm... there is only one device entry with a _DSM Method in there (GFX0). The GUID of that _DSM method matches the one in the noveau driver. That is why the intel driver does not find the backlight stuff. Can you attach your dmesg and .config too? Created attachment 61712 [details]
dmesg
Created attachment 61722 [details]
kernel config
On the other hand backlight works in X11... Just to verify, this is the same .config as before and the problem persists? (having the whole dmesg is quite a treat.. should have asked for it from the beginning... now it also makes sense, that the backlight is working and so on, because the nouveau driver is loading and parsing his _DSM entry... also vgaarbiter and the switcheroo doing it's thing). I think this is down to the i915 developers to fix. I can't see anything obvious wrong... One last thing to check: Can you add drm.debug=6 to the kernel cmdline and attach the resulting dmesg? Maybe in there we find some obvious wrongness... Also I'm wondering what could be the reason for the rectangles. in comment #22, can you describe what you mean with "when the screen is full they vanish."? Do you mean that they get "scrolled" off, or stay they fixed until at some point X takes over? (i.e. are they independent of the text scrolling by?) It looks to me on your photo, that somehow the dimensions of the fb-console are not how they should be. Maybe it's an issue with the gpu scanning out too big a memory region. Over here the framebuffer-console utilizes the whole screen width... Oh, and one last thing: if you don't compile nouveau, what happens? they get "scrolled" off. Nouveau doesn't change anything. The problem appeared without nouveau being compiled in. I wanted to test vga switchero to see if I can dynamically activate the nvidia board but it doesn't work. There is a separate bug on this. I just was too lasy to remove it. I cannot even cold boot now with 3.2.6. See bug 42790 What's the latest on this one? Is the issue still the white rects? Still there with 3.3.2. Disabled the nvidia card to save power so I'm sure its the Intel driver that males the white rectangle drawing. Hoping Chris's "remove early plane enable" gets rid of this. Testing now. If not, I'll track it down as I'm seeing this on another platform now too and think you're right it indicates a programming error that could potentially cause other trouble, or at least indicate we don't understand something. Hm I don't see this anymore with or without Chris's patch... I'll test on the other platform before closing though... I opened the bug saw closing before I confirm it fixes my case is a bit rough... As it is a single line fix, I will backport it. Tested the fix. The white rectangle is still there I don't see it with Daniel's drm-intel-next-queued branch, with or without Chris's patch. Can you try that branch? I'm afraid not. I do not want to try untested code for drivers on my main laptop. Given the time the bug is open (one year and a half), I can wait two more month until it becomes mainstream ;-) If you know precisely the change that may fix it, then I can try that patch. I just checked out 3.2.0 and didn't see the issue there either, so my test setup must be failing somehow. I'll try your .config and make sure the early boot display stuff is turned off here... The .config there is a bit outdated. Will post a 3.3.6/7 one once I return home. I now load the intel driver as a module from user space and still have the rectangle. SO its not an early init problem. Tested 3.4.0. Idem. Attached config.gz Created attachment 73355 [details]
Kernel config for 3.4.0 kernel
Kernel config for 3.4.0 kernel.
Jesse thinks that the modeset rework might have fixed this. Can you please retest with the latest drm-intel-next-queued git branch from http://cgit.freedesktop.org/~danvet/drm-intel I won't do that before its in an official release. Its my personal laptop and I do not want to mess video display too much. Does it mean 3.6.0? On Mon, Sep 17, 2012 at 5:23 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > --- Comment #44 from Eric Valette <eric.valette@free.fr> 2012-09-17 15:23:09 > --- > I won't do that before its in an official release. Its my personal laptop and > I > do not want to mess video display too much. Does it mean 3.6.0? It means 3.7. But I run that crap on all my machines, and it works (it's base on a recent 3.6.0 release + drm/i915 patches), so shouldn't be too harmful. Well, the bug being 2 years old, I can wait around 3 more months for 3.7. Then, this laptop model is quite bizarre as nobody yet managed to make the nvidia card work without selecting it explicitly via BIOS setting. bbswitch, vgaswitchero all failed. So its not because it works on other machines that mine will work flawlessly. Bbswitch manage to put the card on or off (power consumption tells me) but does not correctly transfers the input/output control via ACPI method. Anyway thanks for the hint. I still have hope that it will be fiwed. My hope is gone. Tried 3.7-rc4. Got a black screen without anything on it. power button enabled a clean reboot. Next reboot I has the white rectangle. Eric, care to revisit an old bug? What kernel are you running now? Does the problem persist? (In reply to comment #40) > I now load the intel driver as a module from user space and still have the > rectangle. SO its not an early init problem. Just to confirm, so the rectangle is *not* there until you load i915? I'm running 3.7.7. And yes it appears when loading the modules. No balnk screen while still in old ascii mode. (In reply to comment #49) > I'm running 3.7.7. And yes it appears when loading the modules. No balnk > screen > while still in old ascii mode. Dunno what we can make of it, but please provide the full dmesg from boot with drm.debug=0xe module parameter, and your current kernel config. Note that I did already provide thsi for older kernel for no result. Anyway I must go home before... (In reply to comment #51) > Note that I did already provide thsi for older kernel for no result. Anyway I > must go home before... I'm aware of that; it's just that there's much more debugging info available in the dmesg now than in the past. And also new sets of eyeballs. Created attachment 93251 [details]
3.7.7 config
Created attachment 93261 [details]
dmesg
drm.debug=0xe produce and error when loading modules. I have this in /etc/modprobe.d/i915-kms.conf options i915 modeset=1 adding "drm.debug=0xe" to this line prevents to load the modules. You need to put it onto the kernel cmdline, the modprobe configs take it in the format options <module-name> <options> Note the lack of a . in between. So if you want to put it into the modprobe files you need a new line with option drm debug=0xe Most distros also require you to rebuild the initramfs images, since gfx module get loaded fairly early. Hence it's quicker for a quick debug run to add in to the kernel cmdline (with the . included). Created attachment 93271 [details]
dmesg with drm.debug=0xe set on boot line
Finally caught where to see the parameter drm.debug=0xe
Very similar to bug 31862. I think Ville fixed something related to this, but can't recall the commit... Please try v3.12 kernel. I decided to force the PC via the BIOS to use the nvidia card after upgrading windows to windows 7 because I find no driver that supports this device in dual video card mode => I'm no more able to test |