Bug 27862

Summary: Cannot launch X.org server on Core I5 with 2.6.38-rc2-git7
Product: Drivers Reporter: Darisuz Luksza (dariusz.luksza)
Component: Video(DRI - Intel)Assignee: drivers_video-dri-intel (drivers_video-dri-intel)
Status: CLOSED CODE_FIX    
Severity: normal CC: akpm, chris, florian, maciej.rutecki, rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.38-rc2 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 27352    
Attachments: kernel configuration file

Description Darisuz Luksza 2011-01-30 12:13:19 UTC
Created attachment 45542 [details]
kernel configuration file

On my Toshiba Portege r700 with i5 processor and integrated intel graphic card and kernel 2.6.28-rc2-git7 when I want to start x from command line it ends with a blank screen, I cannot switch back on text console or do anything wit it. I can only hard reset by holding power button.

Here is part from my kernel.log:
[   30.455807] phyerr 0x20, rate 0xa
[   30.455813] Raw TxDesc + plcp header:
[   30.455824]   0000: 09 00 00 00 b0 00 00 00 00 00 02 00 02 00 00 00 
[   30.455835]   0016: 00 00 0a 00 00 07 00 00 00 00 00 00 00 00 00 00 
[   30.455847]   0032: 00 00 00 00 00 00 94 0c 6d ee 69 4a 00 00 00 00 
[   30.455859]   0048: 00 00 00 00 00 00 0a 04 10 01 22 00 3a 01 00 00 
[   30.455871]   0064: 00 00 00 00 00 00 00 00 00 00 00 00 03 1a 00 00 
[   30.455883]   0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[   30.455895]   0096: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[   30.455908]   0112: 0a 04 10 01 00 00 b0 00 3a 01 94 0c 6d ee 69 4a 
[   30.455921]   0128: 4c ed de 1c 53 ed 94 0c 6d ee 69 4a d0 00 00 00 
[   30.455933]   0144: 01 00 00 00 01 88 ff ff 00 00 00 00 00 00 00 00 
[   30.455939] TxCtlLow: 0009 TxCtlHigh: 0000 FC: 00b0 FES Time: 0000
[   30.455950] PhyCtl: 0000 PhyCtl_1: 0002 PhyCtl_1_Fbr: 0002
[   30.455959] PhyCtl_1_Rts: 0000 PhyCtl_1_Fbr_Rts: 0000
[   30.455966] MainRates: 000a XtraFrameTypes: 0700 
[   30.455980] SecIV:       00000000000000000000000000000000
[   30.455987] RA:          940C6DEE694A
[   30.455992] Fb FES Time: 0000 RTS PLCP: 000000000000 RTS DUR: 0000 PLCP: 0A0410012200 DUR: 013a
[   30.456011] MModeLen: 0000 MModeFbrLen: 0000
[   30.456018] FrameID:     1a03
[   30.456022] TxStatus:    0000
[   30.456026] MaxNumMpdu:  0000
[   30.456031] MaxAggbyte:  0000
[   30.456035] MaxAggbyte_fb:  0000
[   30.456039] MinByte:     0000
[   30.456045] RTS PLCP: 000000000000 RTS Frame: 00000000000000000000000000000000
[   30.456060] 
[   30.456061] txpkt (MPDU) Complete
[   30.456066] FrameID: 1a03   TxStatus: 0019
[   30.456074] [15:12]  0  frame attempts
[   30.456079]  [11:8]  0  rts attempts
[   30.456083]     [7]  0  PM mode indicated
[   30.456088]     [6]  0  intermediate status
[   30.456092]     [5]  0  AMPDU
[   30.456098]   [4:2]  6  Frame Suppressed Reason (Underflow)
[   30.456103]     [1]  0  acked
[   30.456107] LastTxTime: 0000 Seq: 0000 PHYTxStatus: 0020 RxAckRSSI: 0000 RxAckSQ: 0000

X.org server version: 1.9.3.901-r1
xf86-video-intel version: 2.14.0

lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0007
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3050 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915
Comment 1 Andrew Morton 2011-02-01 01:01:20 UTC
I assume you meant 2.6.38, not 2.6.28?

If so, was 2.6.37 OK?
Comment 2 Darisuz Luksza 2011-02-01 01:36:43 UTC
Yes in deed I meant 2.6.38.

Yes on 2.6.37 x.org starts and works properly.
Comment 3 Chris Wilson 2011-02-01 09:27:46 UTC
Try

commit 3e28a0c0b43823d3104fe8fc50b5994b41fc0cc1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jan 20 15:07:26 2011 +0000

    Create the UXA generational resources during screen create
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

commit c6dc27562abbc8ca9e873ad502ca49ae010461d2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 24 20:25:27 2011 +0000

    uxa: Only recreate the glyph cache on *generational* updates
    
    The screen resources are recreated when the screen is rotated as well,
    without being finalized. In this case, we do not need to reconstuct the
    cache (or if we did, we would need to tear it down first).
    
    Reported-by: Till Matthiesen <entropy@everymail.net>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33412
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

to fix the X crash, and

commit ede3ff5204b0117d00609f4980df3b864cefe96f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 31 11:16:33 2011 +0000

    drm: Simplify and defend later checks when disabling a crtc
    
    By setting the FB of a CRTC to NULL, we are turning off the CRTC (and so
    disable the unused encoders and connectors). As such we can simplify the
    later tests by making sure the set->mode is NULL. Setting the
    num_connectors to zero means that we do not need to loop over the unused
    connectors.
    
    All current usage appears correct, this only builds additional defense
    into the routine.
    
    References: https://bugzilla.kernel.org/show_bug.cgi?id=27722
    Tested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

to fix the OOPS in the midst of restoring the console after the X crash.
Comment 4 Chris Wilson 2011-02-01 09:28:26 UTC
I meant:

commit 9334ef755f060e251f3f395caeda1a58b6834ea3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jan 28 11:53:03 2011 +0000

    drm: Don't switch fb when disabling an output
    
    In drm_crtc_helper_set_config, we call drm_crtc_helper_set_mode which
    may return early and do no operation if the crtc is to be disabled. In
    this case we merrily swap to the new fb, discarding the old_fb believing
    that it has been cleaned up. However, due to the early return, the
    old_fb was not presented to the backend for correct reaping, and nor was
    the new one - which is about to be reaped via the
    drm_helper_disable_unused_functions(), leading to incorrect refcounting
    of the pinned objects.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27722
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29230
    Tested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

for the OOPS.
Comment 5 Darisuz Luksza 2011-02-01 10:12:14 UTC
(In reply to comment #4)
> I meant:
> 
> commit 9334ef755f060e251f3f395caeda1a58b6834ea3
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Jan 28 11:53:03 2011 +0000
> 
>     drm: Don't switch fb when disabling an output

Yes, this patch fix this problem, thank you!
Comment 6 Chris Wilson 2011-02-01 10:23:00 UTC
I've sent the pull request for that particular patch earlier. Thanks for testing!
Comment 7 Rafael J. Wysocki 2011-02-01 10:34:03 UTC
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Patch : https://bugs.freedesktop.org/attachment.cgi?id=42634
Comment 8 Rafael J. Wysocki 2011-02-01 10:44:17 UTC
*** Bug 27672 has been marked as a duplicate of this bug. ***
Comment 9 Rafael J. Wysocki 2011-02-12 22:40:43 UTC
Fixed by commit 9334ef755f060e251f3f395caeda1a58b6834ea3 .