-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Thursday, October 28, 2010 11:44 PM To: coreboot@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