[coreboot] how to prevent legacy resource conflictwith multiple VGA cards

[Scott Duplichan]

-----Original Message-----
From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org] On Behalf Of Peter Stuge
Sent: Thursday, October 28, 2010 11:44 PM
To: coreboot at coreboot.org
Subject: Re: [coreboot] how to prevent legacy resource conflictwith multiple VGA cards

]Myles Watson wrote:
]> The UMA device could check the tree for these bits and disable
]> itself, or some more code could be added to generically do the
]> same thing.
]
]I think it's a very good idea to have this code be generic, since it
]can apply to all chipsets with UMA.
]
]
]Scott Duplichan wrote:
]> There must be a pretty basic problem remaining because the driver
]> fails after a few seconds. Win7 reports that a kernel mode thread
]> has spent too long in the ATI driver code.
]
]I guess that the watchdog is those few seconds. Does graphics work
]during that time?

The high resolution display from the ATI driver is often visible
for a few seconds. But then the display appears to reset. Sometimes
the BSOD is "the device driver got stuck in an infinite loop". Other
times it is Stop 116 BSOD.

I just now tried several different video option roms. The all behave the same.

Earlier this evening I tried different memory congigurations. With 4GB (2+2),
I have an ACPI related BSOD to fix. With 3GB (2+1), a memory test fails
immediately when it gets near the end of the first GB. With a single 1GB DIMM
or a single 2 GB DIMM, the problem is the same.

]Could you use windbg to get more details, in particular find out what
]the ATI driver was trying to do?

For the infinite loop case, I captured a stack trace:

nt!DbgBreakPointWithStatus
nt!KiBugCheckDebugBreak+0x14
nt!KeBugCheck2+0x7c8
nt!KeBugCheckEx+0x104
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x3e
dxgkrnl!TdrTimedOperationDelay+0xbb
atikmdag!OsServices::Wait+0x92
atikmdag!MCIL_WaitFor+0x50
atikmdag!Cail_MCILWaitFor+0x72
atikmdag!Cail_R600_WaitForIdle+0x52
atikmdag!Cail_R600_WaitForIdle+0x172
atikmdag!Cail_ExecuteAsicSetupTable+0x98
atikmdag!CAIL_ASICSetup+0x7b
atikmdag!CAIL_VPURecoveryBegin+0x20e
atikmdag!CAILVPURecoveryBegin+0x19
atikmdag!AsicInit::ResetTheAsic+0x4a
atikmdag!DISPATCHER::HeavyWeightReset+0x65
atikmdag!DISPATCHER::ResetFromTimeoutWorker+0x16b
atikmdag!Dispatch_ResetFromTimeout+0x67
dxgkrnl!DXGADAPTER::DdiResetFromTimeout+0x4c
dxgkrnl!DXGADAPTER::PrepareToReset+0xf6
dxgkrnl!TdrIsRecoveryRequired+0x279
dxgmms1!VidSchiReportHwHang+0x4ce
dxgmms1!VidSchiCheckHwProgress+0xee
dxgmms1!VidSchiWaitForSchedulerEvents+0x319
dxgmms1!VidSchiScheduleCommandToRun+0x3d9
dxgmms1!VidSchiWorkerThread+0x196
nt!PspSystemThreadStartup+0x1a9
nt!KxStartSystemThread+0x16

Looks like it had a hang early and some recovery attempts were unsuccessful.

To break into the initial failure might take some experimentation. I did do
the sanity check of reading a few I/O ports and they do not come back FF.
The frame buffer looks OK. I don't even know what bars are for. 

Thanks,
Scott

]//Peter