Bug 532579 - [nouveau] - X crashes before login: [Mat Booth] [9500 GT]
Summary: [nouveau] - X crashes before login: [Mat Booth] [9500 GT]
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: 12
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: card_undefined NV96
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-02 21:00 UTC by Mat Booth
Modified: 2018-04-11 17:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-04 03:32:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg log (65.91 KB, text/plain)
2009-11-02 21:01 UTC, Mat Booth
no flags Details
dmesg output (40.23 KB, text/plain)
2009-11-02 21:02 UTC, Mat Booth
no flags Details
dmesg output (37.76 KB, text/plain)
2009-11-04 19:20 UTC, Mat Booth
no flags Details
Xorg log (64.42 KB, text/plain)
2009-11-04 19:21 UTC, Mat Booth
no flags Details
dmesg output (37.71 KB, text/plain)
2009-11-06 18:35 UTC, Mat Booth
no flags Details
Xorg log (64.43 KB, text/plain)
2009-11-06 18:36 UTC, Mat Booth
no flags Details

Description Mat Booth 2009-11-02 21:00:53 UTC
Description of problem:

X is managing to get itself into a nice tight loop before GDM gets the chance to present me with the logon box.

Video hardware is:
01:00.0 VGA compatible controller: nVidia Corporation GeForce 9500 GT (rev a1) (prog-if 00 [VGA controller])
 Subsystem: nVidia Corporation Device 0560
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
 Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
 Region 3: Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
 Region 5: I/O ports at cc00 [size=128]
 Expansion ROM at fe980000 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
  Address: 0000000000000000  Data: 0000
 Capabilities: [78] Express (v1) Endpoint, MSI 00
  DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
   ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
  DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
   MaxPayload 128 bytes, MaxReadReq 512 bytes
  DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
  LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <1us
   ClockPM- Surprise- LLActRep- BwNot-
  LnkCtl:	ASPM L0s Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
  LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
 Capabilities: [b4] Vendor Specific Information <?>
 Capabilities: [100] Virtual Channel <?>
 Capabilities: [128] Power Budgeting <?>
 Capabilities: [600] Vendor Specific Information <?>
 Kernel driver in use: nouveau
 Kernel modules: nouveau, nvidiafb

And with the following kernel, nouveau and X installed:

kernel-2.6.31.5-96.fc12.x86_64
xorg-x11-drv-nouveau-0.0.15-13.20090929gitdd8339f.fc12.x86_64
xorg-x11-server-common-1.7.0-5.fc12.x86_64
xorg-x11-server-Xvfb-1.7.0-5.fc12.x86_64
xorg-x11-server-Xorg-1.7.0-5.fc12.x86_64
xorg-x11-server-utils-7.4-13.fc12.x86_64


I will attach dmesg output and the Xorg log, but I'll spoil it for you by telling you how it ends:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.
Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49e7e8]
1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49e1b4]
2: /usr/bin/Xorg (xf86PostMotionEventP+0xce) [0x478eee]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f8b26028000+0x3f4f) [0x7f8b2602bf4f]
4: /usr/bin/Xorg (0x400000+0x6bdf7) [0x46bdf7]
5: /usr/bin/Xorg (0x400000+0x1169e3) [0x5169e3]
6: /lib64/libpthread.so.0 (0x7f8b2c83a000+0xf320) [0x7f8b2c849320]
7: /lib64/libc.so.6 (ioctl+0x7) [0x7f8b2b0c6c07]
8: /usr/lib64/libdrm.so.2 (drmIoctl+0x23) [0x7f8b28b4f203]
9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7f8b28b4f48b]
10: /usr/lib64/libdrm_nouveau.so.1 (0x7f8b284ef000+0x2d5d) [0x7f8b284f1d5d]
11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0x10b) [0x7f8b284f1f6b]
12: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7f8b286f4000+0xbfa8) [0x7f8b286fffa8]
13: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7f8b286f4000+0xd190) [0x7f8b28701190]
14: /usr/lib64/xorg/modules/libexa.so (0x7f8b26459000+0x8120) [0x7f8b26461120]
15: /usr/bin/Xorg (0x400000+0x152ad4) [0x552ad4]
16: /usr/bin/Xorg (0x400000+0xcbfc9) [0x4cbfc9]
17: /usr/bin/Xorg (0x400000+0x2c60c) [0x42c60c]
18: /usr/bin/Xorg (0x400000+0x21c9a) [0x421c9a]
19: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f8b2b00bb4d]
20: /usr/bin/Xorg (0x400000+0x21849) [0x421849]



Killing /usr/bin/Xorg allowed me log in normally.

Comment 1 Mat Booth 2009-11-02 21:01:52 UTC
Created attachment 367206 [details]
Xorg log

Comment 2 Mat Booth 2009-11-02 21:02:25 UTC
Created attachment 367207 [details]
dmesg output

Comment 3 Mat Booth 2009-11-02 21:05:43 UTC
Using nomodeset is even worse, completely blank screens, Xorg stuck in a tight loop, but no back traces this time and killing Xorg has no effect whatsoever.

Comment 4 Mat Booth 2009-11-02 21:14:59 UTC
Tried updating to
xorg-x11-drv-nouveau-0.0.15-16.20091030git5587f40.fc12.x86_64
from Koji but I get exactly the same backtrace as in the description.

Comment 5 Adam Williamson 2009-11-02 21:27:06 UTC
Ben, is this another 530169?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 6 Ben Skeggs 2009-11-02 23:13:03 UTC
nomodeset is definitely going to be a fail here, it'll probably work with a single display plugged in, definitely not with multiple.  The UMS code just isn't capable enough to deal with it.

I'm seeing another issue with the display engine in your kernel log too, I'll add some extra debugging capabilities to the kernel module and update once it's done - but this isn't likely related to the backtrace.

Adam, no, I don't think it is.

Comment 7 Adam Williamson 2009-11-02 23:37:35 UTC
ugh. alright.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Ben Skeggs 2009-11-03 22:25:35 UTC
It looks like the HW is hanging for some undefined reason (it usually gives some hint as to why, but in this case, it's not).

While this bug is serious, I don't think it should be on the blocker list, it appears to just effect this board and there's other chipsets of the same time that work fine (I have 2 NV96 that do at lease!).

Comment 9 Adam Williamson 2009-11-03 22:53:54 UTC
that's reasonable to me. we have historically not blocked on single-chipset X bugs, even complete fails. we're fairly sure this is pretty hardware specific; both Ben and I have NV96-based adapters (same basic chipset as this card) which work fine. so we're dropping this as a blocker.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Adam Williamson 2009-11-03 22:59:39 UTC
reporter, could you possibly test with your TV capture card removed? i wondered if the bug might be a bad interaction with that; Ben doesn't think so, but it can't hurt to try, if it's not too much trouble for you. thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 11 Mat Booth 2009-11-04 18:40:58 UTC
(In reply to comment #10)
> reporter, could you possibly test with your TV capture card removed? i wondered
> if the bug might be a bad interaction with that; Ben doesn't think so, but it
> can't hurt to try, if it's not too much trouble for you. thanks!
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers  


I gave that a go, but it still fails in the same way without the capture card in. Thanks for the suggestion, though.

Comment 12 Mat Booth 2009-11-04 19:18:49 UTC
I just updated to try the new kernel that's in Rawhide so you can see whatever debugs you've put in:

kernel-2.6.31.5-115.fc12.x86_64

One thing that's different is I now get the fancy new graphical boot screen instead of the text mode progress bar, but I suspect that has more to do with the Plymouth updates.

I will attach new dmesg output an Xorg log.

Comment 13 Mat Booth 2009-11-04 19:20:09 UTC
Created attachment 367523 [details]
dmesg output

Comment 14 Mat Booth 2009-11-04 19:21:02 UTC
Created attachment 367524 [details]
Xorg log

Comment 15 Matěj Cepl 2009-11-05 17:20:17 UTC
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Comment 16 Adam Williamson 2009-11-05 23:27:50 UTC
as per comment #12, Mat's already on very recent components. (Ben, no chance this one's fixed in 122 is there?)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 Ben Skeggs 2009-11-06 00:43:49 UTC
I highly doubt it, but hey, worth a try :P

Comment 18 Mat Booth 2009-11-06 18:35:09 UTC
Still failing in the same way (X caught in a tight loop, just before the GDM login dialog is shown) with the latest stuff from Rawhide:

xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12.x86_64
xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64
kernel-2.6.31.5-122.fc12.x86_64

Will update the dmesg and xorg log.

Comment 19 Mat Booth 2009-11-06 18:35:50 UTC
Created attachment 367861 [details]
dmesg output

Comment 20 Mat Booth 2009-11-06 18:36:22 UTC
Created attachment 367862 [details]
Xorg log

Comment 21 Mat Booth 2009-11-06 18:48:31 UTC
I don't know if this is helpful or interesting but this is the backtrace I get when I attach the debugger after Xorg has hung and is chomping away at 100% CPU:

(gdb) attach 1613
(gdb) bt
#0  0x00007f62fc8a41f7 in ioctl () from /lib64/libc.so.6
#1  0x00007f62fb6fe203 in drmIoctl (fd=11, request=1074291845, arg=0x7fffa43c4b90) at xf86drm.c:188
#2  0x00007f62fb6fe48b in drmCommandWrite (fd=<value optimized out>, drmCommandIndex=<value optimized out>, data=<value optimized out>, size=<value optimized out>) at xf86drm.c:2365
#3  0x00007f62fb0a1efd in nouveau_bo_wait (bo=0x247cb40, cpu_write=<value optimized out>, no_wait=<value optimized out>, no_block=<value optimized out>) at nouveau_bo.c:399
#4  0x00007f62fb0a210b in nouveau_bo_map_range (bo=0x247cb40, delta=0, size=<value optimized out>, flags=8) at nouveau_bo.c:442
#5  0x00007f62fb2b095b in NVAccelUploadM2MF (pdpix=<value optimized out>, x=<value optimized out>, y=<value optimized out>, w=<value optimized out>, h=<value optimized out>, src=<value optimized out>, src_pitch=<value optimized out>) at nouveau_exa.c:202
#6  0x00007f62fb2b16f4 in nouveau_exa_upload_to_screen (pdpix=0x26dd3f0, x=<value optimized out>, y=0, w=552, h=193, src=0x26dd5c0 "", src_pitch=<value optimized out>) at nouveau_exa.c:562
#7  0x00007f62f900e50f in exaCopyDirty (migrate=<value optimized out>, pValidDst=<value optimized out>, pValidSrc=<value optimized out>, transfer=0x7f62fb2b1600 <nouveau_exa_upload_to_screen>, fallback_index=<value optimized out>, sync=<value optimized out>) at exa_migration_classic.c:217
#8  0x00007f62f9010370 in exaDoMigration_mixed (pixmaps=<value optimized out>, npixmaps=3, can_accel=<value optimized out>) at exa_migration_mixed.c:103
#9  0x00007f62f9015fe7 in exaTryDriverComposite (op=<value optimized out>, pSrc=0x26dd320, pMask=0x26dd440, pDst=0x26d3b10, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at exa_render.c:735
#10 0x00007f62f9016fa2 in exaComposite (op=<value optimized out>, pSrc=0x26dd320, pMask=0x26dd440, pDst=0x26d3b10, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at exa_render.c:1034
#11 0x00000000004d1c80 in damageComposite (op=<value optimized out>, pSrc=<value optimized out>, pMask=<value optimized out>, pDst=0x26d3b10, xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>) at damage.c:643
#12 0x00007f62f9015bd8 in exaTrapezoids (op=<value optimized out>, pSrc=0x26dd320, pDst=0x26d3b10, maskFormat=<value optimized out>, xSrc=<value optimized out>, ySrc=<value optimized out>, ntrap=0, traps=0x26b3ae0) at exa_render.c:1183
#13 0x00000000004ce0b7 in ProcRenderTrapezoids (client=0x265d460) at render.c:780
#14 0x000000000042c69c in Dispatch () at dispatch.c:445
#15 0x0000000000421cfa in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:285


If there's anything I can inspect that will help diagnose this, please let me know.

Comment 22 Bug Zapper 2009-11-16 14:55:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 23 Phillip Lynn 2010-01-06 19:45:05 UTC
Has there been any new updates on this issue?  As of 01/06/2010 I am still having the same issue, multiple times a day, with the latest Fedora 12 updates as of 01/06/2010.

Comment 24 Adam Williamson 2010-01-07 15:17:17 UTC
Phillip: the error message referenced in the subject of this bug is very much a generic one and can occur in many circumstances. Unless your experience exactly matches Mat's in all other ways, you are likely suffering from a different bug. Please report it separately.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 25 Phillip Lynn 2010-01-29 14:24:04 UTC
My System is locking up from 1 to 3 times a day.  Just started system waited about 5 minutes and system was locked.

I am using an ASUS N71V series Laptop
CPU P8700
4GB Memory
Fedora 12 latest updates as of 01/29/2010


(II) XINPUT: Adding extended input device "Sleep Button" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device Video Bus
(**) Video Bus: always reports core events
(**) Video Bus: Device: "/dev/input/event6"
(II) Video Bus: Found keys
(II) Video Bus: Configuring as keyboard
(II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"
(II) config/hal: Adding input device Power Button
(**) Power Button: always reports core events
(**) Power Button: Device: "/dev/input/event0"
(II) Power Button: Found keys
(II) Power Button: Configuring as keyboard
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"
(II) NOUVEAU(0): EDID for output LVDS-0
(II) NOUVEAU(0): Manufacturer: LGD  Model: 1dd  Serial#: 0
(II) NOUVEAU(0): Year: 2008  Week: 0
(II) NOUVEAU(0): EDID Version: 1.3
(II) NOUVEAU(0): Digital Display Input
(II) NOUVEAU(0): Max Image Size [cm]: horiz.: 38  vert.: 21
(II) NOUVEAU(0): Gamma: 2.20
(II) NOUVEAU(0): No DPMS capabilities specified
(II) NOUVEAU(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
(II) NOUVEAU(0): First detailed timing is preferred mode
(II) NOUVEAU(0): redX: 0.615 redY: 0.346   greenX: 0.314 greenY: 0.602
(II) NOUVEAU(0): blueX: 0.151 blueY: 0.109   whiteX: 0.312 whiteY: 0.328
(II) NOUVEAU(0): Manufacturer's mask: 0
(II) NOUVEAU(0): Supported detailed timing:
(II) NOUVEAU(0): clock: 97.8 MHz   Image Size:  382 x 215 mm
(II) NOUVEAU(0): h_active: 1600  h_sync: 1648  h_sync_end 1696 h_blank_end 1784 h_border: 0
(II) NOUVEAU(0): v_active: 900  v_sync: 902  v_sync_end 905 v_blanking: 912 v_border: 0
(II) NOUVEAU(0):
(II) NOUVEAU(0):  LP173WD1-TLC1
(II) NOUVEAU(0): EDID (in hex):
(II) NOUVEAU(0):        00ffffffffffff0030e4dd0100000000
(II) NOUVEAU(0):        00120103802615780aa8c09d58509a26

(II) NOUVEAU(0):        1c505400000001010101010101010101
(II) NOUVEAU(0):        0101010101012f2640b860840c303030
(II) NOUVEAU(0):        23007ed7100000190000000000000000
(II) NOUVEAU(0):        00000000000000000000000000fe0000
(II) NOUVEAU(0):        00004c47446973706c61790a000000fe
(II) NOUVEAU(0):        004c503137335744312d544c43310063
(II) NOUVEAU(0): EDID vendor "LGD", prod id 477
(II) NOUVEAU(0): Printing DDC gathered Modelines:
(II) NOUVEAU(0): Modeline "1600x900"x0.0   97.75  1600 1648 1696 1784  900 902 905 912 -hsync -vsync (54.8 kHz)
(II) NOUVEAU(0): Printing probed modes for output LVDS-0
(II) NOUVEAU(0): Modeline "1600x900"x60.1   97.75  1600 1648 1696 1784  900 902 905 912 -hsync -vsync (54.8 kHz)
(II) NOUVEAU(0): Modeline "1152x864"x60.0   81.75  1152 1216 1336 1520  864 867 871 897 -hsync +vsync (53.8 kHz)
(II) NOUVEAU(0): Modeline "1024x768"x59.9   63.50  1024 1072 1176 1328  768 771 775 798 -hsync +vsync (47.8 kHz)
(II) NOUVEAU(0): Modeline "800x600"x59.9   38.25  800 832 912 1024  600 603 607 624 -hsync +vsync (37.4 kHz)
(II) NOUVEAU(0): Modeline "640x480"x59.4   23.75  640 664 720 800  480 483 487 500 -hsync +vsync (29.7 kHz)
(II) NOUVEAU(0): Modeline "720x400"x59.6   22.25  720 744 808 896  400 403 413 417 -hsync +vsync (24.8 kHz)
(II) NOUVEAU(0): Modeline "640x400"x60.0   20.00  640 664 720 800  400 403 409 417 -hsync +vsync (25.0 kHz)
(II) NOUVEAU(0): Modeline "640x350"x59.8   17.50  640 664 720 800  350 353 363 366 -hsync +vsync (21.9 kHz)
(II) NOUVEAU(0): EDID for output VGA-0
(II) NOUVEAU(0): EDID for output DVI-D-0
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x49ea48]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e414]
2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x478fae]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f46b53b5000+0x516f) [0x7f46b53ba16f]
4: /usr/bin/X (0x400000+0x6bea7) [0x46bea7]
5: /usr/bin/X (0x400000+0x116d53) [0x516d53]
6: /lib64/libpthread.so.0 (0x3ee8c00000+0xf0f0) [0x3ee8c0f0f0]
7: /lib64/libc.so.6 (ioctl+0x7) [0x3ee84d6937]
8: /usr/lib64/libdrm.so.2 (drmIoctl+0x23) [0x3cfea03383]
9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x3cfea0360b]
10: /usr/lib64/libdrm_nouveau.so.1 (0x7f46b860b000+0x2f1d) [0x7f46b860df1d]
11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfc) [0x7f46b860e11c]
12: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7f46b8836000+0xc95b) [0x7f46b884295b]
13: /usr/lib64/xorg/modules/drivers/nouveau_drv.so (0x7f46b8836000+0xd6f4) [0x7f46b88436f4]
14: /usr/lib64/xorg/modules/libexa.so (0x7f46b63f1000+0x520f) [0x7f46b63f620f]
15: /usr/lib64/xorg/modules/libexa.so (0x7f46b63f1000+0x7424) [0x7f46b63f8424]
16: /usr/lib64/xorg/modules/libexa.so (0x7f46b63f1000+0xd097) [0x7f46b63fe097]
17: /usr/lib64/xorg/modules/libexa.so (0x7f46b63f1000+0xe042) [0x7f46b63ff042]
18: /usr/bin/X (0x400000+0xd1e80) [0x4d1e80]
19: /usr/lib64/xorg/modules/libexa.so (0x7f46b63f1000+0xcc88) [0x7f46b63fdc88]
20: /usr/bin/X (0x400000+0xce2b7) [0x4ce2b7]
21: /usr/bin/X (0x400000+0x2c71c) [0x42c71c]
22: /usr/bin/X (0x400000+0x21d5a) [0x421d5a]
23: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3ee841eb1d]
24: /usr/bin/X (0x400000+0x21909) [0x421909]


[plynn55@plynn55 ~]$ sudo lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation Device 0a34 (rev a2)
01:00.1 Audio device: nVidia Corporation Device 0be2 (rev a1)
03:00.0 Network controller: Intel Corporation WiFi Link 100 Series
07:00.0 Ethernet controller: Attansic Technology Corp. Device 1063 (rev c0)


Linux plynn55 2.6.31.12-174.2.3.fc12.x86_64 #1 SMP Mon Jan 18 19:52:07
UTC 2010 x86_64 x86_64 x86_64 GNU/Linux


[plynn55@plynn55 ~]$ lsmod
Module                  Size  Used by
fuse                   62064  2      
rfcomm                 71504  4      
sco                    19972  2      
bridge                 54112  0      
stp                     2724  1 bridge
llc                     6400  2 bridge,stp
bnep                   19472  2
l2cap                  38992  16 rfcomm,bnep
sunrpc                191912  1
cpufreq_ondemand        7824  2
acpi_cpufreq           10528  0
freq_table              4864  2 cpufreq_ondemand,acpi_cpufreq
ip6t_REJECT             5856  2
nf_conntrack_ipv6      21912  2
ip6table_filter         4016  1
ip6_tables             19664  1 ip6table_filter
ipv6                  298928  34 ip6t_REJECT,nf_conntrack_ipv6
dm_multipath           17304  0
uinput                  9248  0
arc4                    2160  2
ecb                     3264  2
btusb                  18756  2
iwlagn                144928  0
bluetooth              94884  9 rfcomm,sco,bnep,l2cap,btusb
iwlcore               172004  1 iwlagn
snd_hda_codec_realtek   281380  1
snd_hda_intel          30360  3
snd_hda_codec          72832  2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep               9224  1 snd_hda_codec
snd_seq                58080  0
mac80211              181352  2 iwlagn,iwlcore
snd_seq_device          7620  1 snd_seq
snd_pcm                83144  2 snd_hda_intel,snd_hda_codec
uvcvideo               58972  0
asus_laptop            19588  0
cfg80211               87800  3 iwlagn,iwlcore,mac80211
videodev               36160  1 uvcvideo
v4l1_compat            13892  2 uvcvideo,videodev
snd_timer              22608  2 snd_seq,snd_pcm
iTCO_wdt               13008  0
v4l2_compat_ioctl32    10736  1 videodev
snd                    67592  14 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
atl1c                  33796  0
rfkill                 20488  3 bluetooth,cfg80211
iTCO_vendor_support     3588  1 iTCO_wdt
soundcore               7328  1 snd
snd_page_alloc          9568  2 snd_hda_intel,snd_pcm
serio_raw               6644  0
video                  23476  0
output                  3360  1 video
nouveau               585940  2
ttm                    41952  1 nouveau
drm_kms_helper         25376  1 nouveau
drm                   172416  4 nouveau,ttm,drm_kms_helper
i2c_algo_bit            6020  1 nouveau
i2c_core               28928  4 videodev,nouveau,drm,i2c_algo_bit

Comment 26 Adam Williamson 2010-01-29 18:00:00 UTC
Philip: please file a new bug. We should probably ban bugs with this title; the 'infinite loop' message is very generic and does not tell you anything at all about the nature of the problem, no two 'infinite loop' bugs are actually alike. So they should all get filed separately. Sorry, and thanks :) I'll edit the title of this bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 27 Bug Zapper 2010-11-04 06:52:20 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 28 Bug Zapper 2010-12-04 03:32:24 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.