Windows Vista 0x64 Scatter Gather Element Problem[Porting 32bit driver to 64 bit for Vista].

NTDEV
1

Hi All,
I am trying to port my 32-bit WDM driver to 0x64 bit Vista. Initial
problem was that I was not getting enough MapBuffers from
IoGetDmaAdapter. I Made the DeviceDescription.Dma64BitAddresses=True and
started getting the number of map buffers that I need. Also since my
device is capable of doing a 64-Bit DMA this will be the right thing to
do in my case.
After this another Issue that I am seeing right now is that when I
get a ScatterGatherElement the HighAddress field is set to some valid
value.

I do the following to setup my DMA Descriptor:

pDMADesc[ulHWDescCnt].BuffAddrLow =
pSGL->Elements[ulCnt].Address.LowPart;
pDMADesc[ulHWDescCnt].BuffAddrHi =
(pSGL->Elements[ulCnt].Address.HighPart);

Where:
pDMADesc ----- Is the hardware specific structure.
pSGL ---- Scatter Gather list.

The problem that I am seeing right now is HighPart [defined as LONG] is
a signed value and I am assigning it to BuffAddrHi which is Unsigned and
hence the correct address does not get copied to the Hardware
descriptor. In One case I was getting a value of 0xfffffa80 in the high
part and BuffAddrHi contains only 0x01.

Question:

  1. Why is the low address defined as ULONG and HighAddress as LONG??? Is
    this done intentionally or is it a bug.

Thanks,

2

Ajitabh Saxena wrote:

I do the following to setup my DMA Descriptor:

pDMADesc[ulHWDescCnt].BuffAddrLow =
pSGL->Elements[ulCnt].Address.LowPart;
pDMADesc[ulHWDescCnt].BuffAddrHi =
(pSGL->Elements[ulCnt].Address.HighPart);
Where:
pDMADesc ----- Is the hardware specific structure.
pSGL ---- Scatter Gather list.

The problem that I am seeing right now is HighPart [defined as LONG]
is a signed value and I am assigning it to BuffAddrHi which is
Unsigned and hence the correct address does not get copied to the
Hardware descriptor. In One case I was getting a value of 0xfffffa80
in the high part and BuffAddrHi contains only 0x01.

That’s not the compiler’s fault. It will do that assignment
bit-for-bit. The MEANING might change, but not the VALUE. You must
have some other problem here.

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

3

One thing I still do not understand is that how come on a machine with
4GB memory I can get such a huge physical address??? [High part being
set to 0xfffffa80 and low part had some value ].
After I rebooted the machine once everything looks just perfect. The
Driver works just fine.

Any Ideas???

  • Aj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 14, 2006 3:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows Vista 0x64 Scatter Gather Element
Problem[Porting 32bit driver to 64 bit for Vista].

Ajitabh Saxena wrote:

I do the following to setup my DMA Descriptor:

pDMADesc[ulHWDescCnt].BuffAddrLow =
pSGL->Elements[ulCnt].Address.LowPart;
pDMADesc[ulHWDescCnt].BuffAddrHi =
(pSGL->Elements[ulCnt].Address.HighPart);
Where:
pDMADesc ----- Is the hardware specific structure.
pSGL ---- Scatter Gather list.

The problem that I am seeing right now is HighPart [defined as LONG]
is a signed value and I am assigning it to BuffAddrHi which is
Unsigned and hence the correct address does not get copied to the
Hardware descriptor. In One case I was getting a value of 0xfffffa80
in the high part and BuffAddrHi contains only 0x01.

That’s not the compiler’s fault. It will do that assignment
bit-for-bit. The MEANING might change, but not the VALUE. You must
have some other problem here.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

4

I’ve just learned this answer, so I’m happy to share my understanding.

Many machines BIOS reserves an area of the memory range from 3GB to 4GB
for use by the BIOS. It’s reasons are hidden in legacy modes (people on
this list might fill in this section). As a result, some portion of the
3GB-4GB memory area is not usable by “real” physical memory (amount
depends on motherboard and BIOS). This results in the need to use
64-bit physical memory addresses.

Weird to think that this is true, but it is. Be careful when putting
4GB of physical memory in a machine with older hardware (esp. TV tuners
and some audio cards), as they just won’t work until you physically
remove a bit of the memory. BTW, the /MAXMEM type switch doesn’t help
in these situations, because the physical memory still exists (and is
just ignored by the OS).

Fun and Exciting Times! :slight_smile:

BTW, a 4GB RAM machine is a great test case for hardware as a result of
this oddity…

.

-----Original Message-----
From: Ajitabh Saxena [mailto:xxxxx@broadcom.com]
Sent: Thursday, December 14, 2006 5:17 PM
Subject: RE: Windows Vista 0x64 Scatter Gather Element Problem[Porting
32bit driver to 64 bit for Vista].

One thing I still do not understand is that how come on a machine with
4GB memory I can get such a huge physical address??? [High part being
set to 0xfffffa80 and low part had some value ].
After I rebooted the machine once everything looks just perfect. The
Driver works just fine.

Any Ideas???

  • Aj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 14, 2006 3:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows Vista 0x64 Scatter Gather Element
Problem[Porting 32bit driver to 64 bit for Vista].

Ajitabh Saxena wrote:

I do the following to setup my DMA Descriptor:

pDMADesc[ulHWDescCnt].BuffAddrLow =
pSGL->Elements[ulCnt].Address.LowPart;
pDMADesc[ulHWDescCnt].BuffAddrHi =
(pSGL->Elements[ulCnt].Address.HighPart);
Where:
pDMADesc ----- Is the hardware specific structure.
pSGL ---- Scatter Gather list.

The problem that I am seeing right now is HighPart [defined as LONG]
is a signed value and I am assigning it to BuffAddrHi which is
Unsigned and hence the correct address does not get copied to the
Hardware descriptor. In One case I was getting a value of 0xfffffa80
in the high part and BuffAddrHi contains only 0x01.

That’s not the compiler’s fault. It will do that assignment
bit-for-bit. The MEANING might change, but not the VALUE. You must
have some other problem here.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

What does this mean from the driver side?? What physical should I post
to the hardware?? Because If I post the high address to the hardware
[High part being
set to 0xfffffa80] I get a PCI abort?? If the OS is giving me high
address how does the driver handle this??

Please clarify a little bit more.
Thanks for the reply,

  • Aj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Henry
Gabryjelski
Sent: Monday, December 18, 2006 10:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Windows Vista 0x64 Scatter Gather Element
Problem[Porting 32bit driver to 64 bit for Vista].

I’ve just learned this answer, so I’m happy to share my understanding.

Many machines BIOS reserves an area of the memory range from 3GB to 4GB
for use by the BIOS. It’s reasons are hidden in legacy modes (people on
this list might fill in this section). As a result, some portion of the
3GB-4GB memory area is not usable by “real” physical memory (amount
depends on motherboard and BIOS). This results in the need to use
64-bit physical memory addresses.

Weird to think that this is true, but it is. Be careful when putting
4GB of physical memory in a machine with older hardware (esp. TV tuners
and some audio cards), as they just won’t work until you physically
remove a bit of the memory. BTW, the /MAXMEM type switch doesn’t help
in these situations, because the physical memory still exists (and is
just ignored by the OS).

Fun and Exciting Times! :slight_smile:

BTW, a 4GB RAM machine is a great test case for hardware as a result of
this oddity…

.

-----Original Message-----
From: Ajitabh Saxena [mailto:xxxxx@broadcom.com]
Sent: Thursday, December 14, 2006 5:17 PM
Subject: RE: Windows Vista 0x64 Scatter Gather Element Problem[Porting
32bit driver to 64 bit for Vista].

One thing I still do not understand is that how come on a machine with
4GB memory I can get such a huge physical address??? [High part being
set to 0xfffffa80 and low part had some value ].
After I rebooted the machine once everything looks just perfect. The
Driver works just fine.

Any Ideas???

  • Aj

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 14, 2006 3:34 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows Vista 0x64 Scatter Gather Element
Problem[Porting 32bit driver to 64 bit for Vista].

Ajitabh Saxena wrote:

I do the following to setup my DMA Descriptor:

pDMADesc[ulHWDescCnt].BuffAddrLow =
pSGL->Elements[ulCnt].Address.LowPart;
pDMADesc[ulHWDescCnt].BuffAddrHi =
(pSGL->Elements[ulCnt].Address.HighPart);
Where:
pDMADesc ----- Is the hardware specific structure.
pSGL ---- Scatter Gather list.

The problem that I am seeing right now is HighPart [defined as LONG]
is a signed value and I am assigning it to BuffAddrHi which is
Unsigned and hence the correct address does not get copied to the
Hardware descriptor. In One case I was getting a value of 0xfffffa80
in the high part and BuffAddrHi contains only 0x01.

That’s not the compiler’s fault. It will do that assignment
bit-for-bit. The MEANING might change, but not the VALUE. You must
have some other problem here.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

Ajitabh Saxena wrote:

What does this mean from the driver side?? What physical should I post
to the hardware?? Because If I post the high address to the hardware
[High part being set to 0xfffffa80] I get a PCI abort?? If the OS is giving me high
address how does the driver handle this??

Is your hardware a 64-bit PCI card? If not, then you should never see a
physical address greater than 4GB. The address you posted looks like a
virtual address.

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

7

My Driver is a 64-Bit DMA capable driver and my hardware can also do
64-Bit DMA.

The address that I posted was in the HighPart of the Scatter Gather
element so it cannot be a Virtual Address. I got this Sglist using the
GetScatterGatherList Dma API. Also this happened only once and when I
posted this address I got a PCI abort [which would happen if the memory
which the H/W is trying to touch is not there and so the target does not
respond].

Once I rebooted my machine after that I was not able to see this issue
anymore and DMA is happening properly.

Another question is that when I see in the device manager I see that
there are two drivers loaded for my device. One is my driver and another
one is KsThunk.sys. Can someone explain why is KsThunk driver needed for
a 64-Bit device??

Thanks,

  • Aj.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, December 18, 2006 11:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Windows Vista 0x64 Scatter Gather Element
Problem[Porting 32bit driver to 64 bit for Vista].

Ajitabh Saxena wrote:

What does this mean from the driver side?? What physical should I post

to the hardware?? Because If I post the high address to the hardware
[High part being set to 0xfffffa80] I get a PCI abort?? If the OS is
giving me high address how does the driver handle this??

Is your hardware a 64-bit PCI card? If not, then you should never see a
physical address greater than 4GB. The address you posted looks like a
virtual address.

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

8

Your driver would appear to be a KS (AvStream/Stream/audio) driver. KsThunk.sys thunks all defined KS IOCTLs from 32-bit clients so you don’t have to. It is an upper class filter on the media and imaging stacks, but it only creates a filter device object if KS init calls are used (wrote some of that code myself, but only some ;-)).

If you’re not a KS driver, then either something’s changed since I last worked on it, or the heuristic itself was bad. Still, it’s unlikely to cause you grief unless you deliberately use IOCTL codes reserved by Microsoft.

9

>one is KsThunk.sys. Can someone explain why is KsThunk driver needed for

a 64-Bit device??

It is some additional filter driver installed by the AVStream framework for all
devices of your class.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com