Blue dump under server2003-32 vs. 2008-64

Hello,

I’m using the following code to allocate a contiguous physical memory in a device driver.
The start address of this space is written to an FPGA and the FPGA writes data to this buffer.
When FPGA goes to the end of the buffer it goes again to buffer start.


NTSTATUS AllocateContinuousPhysicalMemory (IN PDEVICE_EXTENSION DevExt,int Channel)
{
ULONG NumberOfMapRegisters;
DEVICE_DESCRIPTION DeviceDescription;
PPHYSICAL_ADDRESS LogicalAddress;
PDMA_ADAPTER DmaAdapter;
PDEVICE_OBJECT FdoData;
PALLOCATE_COMMON_BUFFER AllocateCommonBuffer;
PVOID UserSpaceAddress;

PAGED_CODE();

RtlZeroMemory(&DeviceDescription, sizeof(DEVICE_DESCRIPTION));

#if defined(DMA_VER2)
DeviceDescription.Version = DEVICE_DESCRIPTION_VERSION2;
#else
DeviceDescription.Version = DEVICE_DESCRIPTION_VERSION;
#endif

DeviceDescription.Master = TRUE;
DeviceDescription.ScatterGather = FALSE;
DeviceDescription.Dma32BitAddresses = FALSE;
DeviceDescription.Dma64BitAddresses = TRUE;
DeviceDescription.InterfaceType = PCIBus;
DeviceDescription.MaximumLength = COMMON_BUFFER_SIZE;

FdoData = WdfDeviceWdmGetPhysicalDevice(DevExt->Device);

DmaAdapter = IoGetDmaAdapter(FdoData,&DeviceDescription,&NumberOfMapRegisters);

if (!DmaAdapter)
{
KdPrint ((“IoGetDmaAdapter failed.\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

AllocateCommonBuffer = DmaAdapter->DmaOperations->AllocateCommonBuffer;

if (!AllocateCommonBuffer)
{
KdPrint ((“devExt->AllocateCommonBuffer=0x0\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

//Allocate common buffer and return its kernel virtual address
DevExt->KernelCommonBuffer[Channel] = AllocateCommonBuffer(DmaAdapter,
COMMON_BUFFER_SIZE,
&LogicalAddress,
FALSE);

if (!DevExt->KernelCommonBuffer)
{
KdPrint ((“AllocateCommonBuffer failed.\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

RtlZeroMemory(DevExt->KernelCommonBuffer[Channel], COMMON_BUFFER_SIZE);

DevExt->CommonBufferMdl[Channel] = IoAllocateMdl (DevExt->KernelCommonBuffer[Channel],COMMON_BUFFER_SIZE,FALSE, FALSE, NULL);

if (!DevExt->CommonBufferMdl)
{
KdPrint ((“IoAllocateMdl failed.\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

MmBuildMdlForNonPagedPool (DevExt->CommonBufferMdl[Channel]);

DevExt->PhysicalKernelCommonBuffer[Channel] = MmGetPhysicalAddress (DevExt->KernelCommonBuffer[Channel]);

return STATUS_SUCCESS;
}

Upon IOCTL request., the FPGA starts writing.

When the driver is compiled and runs under server 2003-32 I’m getting blue dump with the following information.

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [\1public\PUBLIC\a99059\Mini092214-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\Windows\symbols\Server2003_32;M:\zvi_vered\module\FIO_VLRTR\windows\module\objchk_wnet_x86\i386
Executable search path is: M:\zvi_vered\module\FIO_VLRTR\windows\module\objchk_wnet_x86\i386
Unable to load image \WINDOWS\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (16 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Mon Sep 22 09:33:12.890 2014 (UTC + 3:00)
System Uptime: 0 days 0:08:16.042
Unable to load image \WINDOWS\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
Loading Kernel Symbols


Loading User Symbols
Loading unloaded module list

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 19, {20, e15b11e0, e15b2138, ffebffea}

*** WARNING: Unable to verify timestamp for mssmbios.sys
GetUlongFromAddress: unable to read from 808a8bf8
Probably caused by : ntkrnlpa.exe ( nt!KeDelayExecutionThread+99 )

Followup: MachineOwner

11: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: e15b11e0, The pool entry we were looking for within the page.
Arg3: e15b2138, The next pool entry.
Arg4: ffebffea, (reserved)

Debugging Details:

GetUlongFromAddress: unable to read from 808a8bf8

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: e15b11e0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 808927bb to 80827c63

STACK_TEXT:
badd0cc4 808927bb 00000019 00000020 e15b11e0 nt!KeDelayExecutionThread+0x99
badd0d2c 808c6dd5 e15b11e8 00000000 808a46c0 nt!KiDoubleFaultStack+0xf0b
badd0d48 808c7dba e79e7758 e6b3eaf4 badd0d80 nt!CmpFileWrite+0x24f
badd0d58 80814841 e79e7758 00000000 8bf72660 nt!CmpFindReusableCellFromCache+0x5c
badd0d80 80880441 00000000 00000000 8bf72660 nt!FsRtlLookupLastBaseMcbEntry+0x1f
badd0dac 80949b7c 00000000 00000000 00000000 nt!fputwc+0x23
badd0ddc 8088e062 80880356 00000001 00000000 nt!NtSetInformationJobObject+0x58c
00000000 00000000 00000000 00000000 00000000 nt!CmpDelayedCloseSize+0x2

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeDelayExecutionThread+99
80827c63 5d pop ebp

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KeDelayExecutionThread+99

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlpa.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 45d69710

FAILURE_BUCKET_ID: 0x19_20_nt!KeDelayExecutionThread+99

BUCKET_ID: 0x19_20_nt!KeDelayExecutionThread+99

Followup: MachineOwner

When the same code is compiled and runs under sever 2008-64 it works fine.

Can you help ?

Thanks,
Zvika

if (!DevExt->KernelCommonBuffer[Channel])

PHYSICAL_ADDRESS LogicalAddress;

And why are you even calling MmGetPhysicalAddress if you already got it from AllocateCommonBuffer?

Hello,

AllocateCommonBuffer returns a virtual kernel address.
MmGetPhysicalAddress turns it to a physical address.
Am I right ?

Best regards,
Zvika

-----Original Message-----
From: xxxxx@broadcom.com
Sent: Wednesday, September 24, 2014 1:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blue dump under server2003-32 vs. 2008-64

PHYSICAL_ADDRESS LogicalAddress;

And why are you even calling MmGetPhysicalAddress if you already got it
from AllocateCommonBuffer?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>AllocateCommonBuffer returns a virtual kernel address. MmGetPhysicalAddress turns it to a physical address. Am I right ?

Read the description of the third argument.

On Sep 23, 2014, at 7:47 PM, Zvi Vered wrote:
> Hello,
>
> AllocateCommonBuffer returns a virtual kernel address.
> MmGetPhysicalAddress turns it to a physical address.
> Am I right ?

AllocateCommonBuffer returns both. It?s sole purpose is to allocate space for DMA, which always needs both addresses.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hello,

I will use “LogicalAddress” as the physical address written to the
FPGA and check.

Thank you for your help,
Zvika

On Wed, Sep 24, 2014 at 6:25 AM, wrote:
>>AllocateCommonBuffer returns a virtual kernel address. MmGetPhysicalAddress turns it to a physical address. Am I right ?
>
> Read the description of the third argument.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Hello,

I changed the code to:

PHYSICAL_ADDRESS LogicalAddress;

//Allocate common buffer and return its kernel virtual address
DevExt->KernelCommonBuffer[Channel] = AllocateCommonBuffer(DmaAdapter,
COMMON_BUFFER_SIZE,
&LogicalAddress,
FALSE);

I’m writing the low 32bits of LogicalAddress to the FGPA as destination
address.

When FPGA starts writing data to RAM, there is a reset (no blue dump).
After restart, there is no crashdump file.

This time I checked under Server2008-32

Can you help ?

Thanks,
Zvika

-----Original Message-----
From: xxxxx@broadcom.com
Sent: Wednesday, September 24, 2014 6:25 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blue dump under server2003-32 vs. 2008-64

AllocateCommonBuffer returns a virtual kernel address. MmGetPhysicalAddress
turns it to a physical address. Am I right ?

Read the description of the third argument.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

And is the high 32-bits of the destination address always zero, like you have an assert of it being zero?

The DMA adapter code you listed some messages back was configured to allow full 64-bit addressing. The 32-bit version of Server 2008 supports memory above the 4 GB line.

Jan

On Sep 30, 2014, at 9:02 PM, Zvi Vered wrote:

> Hello,
>
> I changed the code to:
>
> PHYSICAL_ADDRESS LogicalAddress;
>
> //Allocate common buffer and return its kernel virtual address
> DevExt->KernelCommonBuffer[Channel] = AllocateCommonBuffer(DmaAdapter,
> COMMON_BUFFER_SIZE,
> &LogicalAddress,
> FALSE);
>
> I’m writing the low 32bits of LogicalAddress to the FGPA as destination address.
>
> When FPGA starts writing data to RAM, there is a reset (no blue dump).
> After restart, there is no crashdump file.
>
> This time I checked under Server2008-32
>
> Can you help ?
>
> Thanks,
> Zvika
>
> -----Original Message----- From: xxxxx@broadcom.com
> Sent: Wednesday, September 24, 2014 6:25 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Blue dump under server2003-32 vs. 2008-64
>
>> AllocateCommonBuffer returns a virtual kernel address. MmGetPhysicalAddress turns it to a physical address. Am I right ?
>
> Read the description of the third argument.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Zvi Vered wrote:

I changed the code to:

PHYSICAL_ADDRESS LogicalAddress;

//Allocate common buffer and return its kernel virtual address
DevExt->KernelCommonBuffer[Channel] = AllocateCommonBuffer(DmaAdapter,
COMMON_BUFFER_SIZE,
&LogicalAddress,
FALSE);

I’m writing the low 32bits of LogicalAddress to the FGPA as destination
address.

Why? You told the system that your DMA handles 64-bit addresses.

DeviceDescription.Master = TRUE;
DeviceDescription.ScatterGather = FALSE;
DeviceDescription.Dma32BitAddresses = FALSE;
DeviceDescription.Dma64BitAddresses = TRUE;

Assuming that’s true, you must write all 64-bits of the LogicalAddress
to your hardware. If that’s NOT true, then you need to change the
DeviceDescription.

When FPGA starts writing data to RAM, there is a reset (no blue dump).
After restart, there is no crashdump file.

Yes, that often happens when you tell your hardware to overwrite random
pages in physical memory.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.