I have the same error with a 10de:0425 GeForce 8600M GS, with the following DCB entry:
Raw DCB entry 0: 01010323 00000034

Skipping the mask check for unhandled bits makes X start fine.

I'm on #nouveau as Anssi.

Same here with nv84:

09:00.0 3D controller [0302]: nVidia Corporation Unknown device [10de:0407] (rev a1)
	Subsystem: Toshiba America Info Systems Unknown device [1179:ff00]
	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: 64 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f2000000 (32-bit, non-prefetchable) [disabled] [size=16M]
	Region 1: Memory at d0000000 (64-bit, prefetchable) [disabled] [size=256M]
	Region 3: Memory at f0000000 (64-bit, non-prefetchable) [disabled] [size=32M]
	Region 5: I/O ports at 2000 [disabled] [size=128]
	Capabilities: <access denied>
	Kernel modules: nvidia

0a:00.0 VGA compatible controller [0300]: nVidia Corporation Unknown device [10de:0407] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Unknown device [1179:ff00]
	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: 64 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at f3000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Region 3: Memory at f4000000 (64-bit, non-prefetchable) [size=32M]
	Region 5: I/O ports at 3000 [size=128]
	Capabilities: <access denied>
	Kernel modules: nvidia


    (II) NOUVEAU(0): Found LVDS manufacturer table revision 4.0
    (EE) NOUVEAU(0): LVDS table revision not currently supported
    (EE) NOUVEAU(0): Pointers to flat panel table invalid
    (II) NOUVEAU(0): Found TMDS table revision 2.0
    (WW) NOUVEAU(0): TMDS table script pointers not stubbed
    (II) NOUVEAU(0): Setting owner: 0x0.
    (II) NOUVEAU(0): Setting owner: 0x3.
    (II) NOUVEAU(0): Setting owner: 0x0.
    (II) NOUVEAU(0): Display Configuration Block version 4.0 found
    (II) NOUVEAU(0): DCB header length 27, with 10 possible entries
    Raw DCB entry 0: 01000323 00000034
    (EE) NOUVEAU(0): Unknown LVDS configuration bits, please report
    (II) NOUVEAU(0): NV50DispPreInit is called.

If I disable check in parse_dcb_entry(), X later segfaults at:

    (WW) NOUVEAU(1): DCB type 14 not known
    (II) NOUVEAU(1): nv50_lvds_detect is called.
    (II) NOUVEAU(1): Output LVDS-0 connected

    Backtrace:
    0: X(xf86SigHandler+0x6d) [0x48efbd]
    1: /lib/libc.so.6 [0x2b538de9f430]
    2: /lib/libc.so.6(memcpy+0xd2) [0x2b538dee49a2]
    3: X(xf86DuplicateMode+0x2e) [0x4b69be]
    4: X(xf86ProbeOutputModes+0x25c) [0x4b21cc]
    5: X(xf86InitialConfiguration+0x78) [0x4b27f8]
    6: /usr/lib64/xorg/modules/drivers//nouveau_drv.so [0x2b538f74c7bb]
    7: X(InitOutput+0x9b6) [0x468156]
    8: X(main+0x275) [0x439ba5]
    9: /lib/libc.so.6(__libc_start_main+0xf4) [0x2b538de8cb74]
    10: X(FontFileCompleteXLFD+0x209) [0x439079]

    Fatal server error:
    Caught signal 11.  Server aborting

Created attachment 15931 [details]
Xorg.log from nv84

FWIW, disabling Screen1 and Card1 in xorg.conf and mask check
makes X starts successfully (not counting garbage on screen
first second or so).

Created attachment 16037 [details]
Xorg.log from NV50

Having this issue with an NV50.

*** Bug 15666 has been marked as a duplicate of this bug. ***

I have this issue also.  What information can I send to help?

*** Bug 15833 has been marked as a duplicate of this bug. ***

For those who are eager, you can bypass the check that causes the error, don't
bypass the entire output creation stage. I'm not inclined to bypass it as it
serves as a reminder. Stuart Bennett has said he'll look at it, once he fixes
some of the pre-NV50 issues.

(In reply to comment #9)
> For those who are eager, you can bypass the check that causes the error, don't
> bypass the entire output creation stage. I'm not inclined to bypass it as it
> serves as a reminder. Stuart Bennett has said he'll look at it, once he fixes
> some of the pre-NV50 issues.
> 

How can I bypass this, please?

I took the opportunity to play with git bisect and here is the result:

c5203647ddf262978e7d6a4912661a9cc448da66 is first bad commit
commit c5203647ddf262978e7d6a4912661a9cc448da66
Author: Stuart Bennett <sb476@cam.ac.uk>
Date:   Wed Mar 19 23:12:59 2008 +0000

    randr12: unbreak LVDS and primary I2C for < NV50
    
    NV50 check disallowed pre-NV50 cards using I2C on first head, and made garbage get written to CR0 on LVDS
    
    This should work for both pre-nv50 and nv50.

:040000 040000 bb26db757c088e20d6d26d6227c8d2357699e0dc 0941deb311d605fbfeb90d54e8aafd4248a59861 M	src


You probably already know that but the benefit for me was to get back to a usable state.

I used the following configuration: 

$ git bisect start -- src/nv_bios.c
$ git bisect bad
$ git bisect good 7c25d338e0c79a288fa192d9a2d4ac6eb59996c1

So I bisected on all changes in nv_bios.c.

The issue is known, i know perfectly well what causes the error. It's in nv_bios.c around line 4148. Please just accept that the driver isn't end-user ready and for that reason i don't work around it.

(In reply to comment #12)
> The issue is known, i know perfectly well what causes the error. It's in
> nv_bios.c around line 4148. Please just accept that the driver isn't end-user
> ready and for that reason i don't work around it.
> 

/*			if (conf & mask) {
*				xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
*					   "Unknown LVDS configuration bits, please report\n");
*				pNv->dcb_table.entries = 0;
*				return false;
*			}
*/

That's my workaround (suggestion from Maarten, thx)


HTH

This is all fixed in the latest code, closing.