GetBusData returns 0 bytes read for PCMCIA Attribute read

Hello,

I am presently working on a Windows 2000 driver for a PCMCIA card. I need
to be able to read to and write from the card’s attribute memory from IRQL
DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be the logical
solution.

In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp down to the
PDO that is provided as a parameter of AddDevice. The call to the PDO
returns a successful status code and my BUS_INTERFACE_STANDARD structure is
filled. However, every time I try to read a single byte from an offset that
I know is valid, the call to GetBusData returns 0 bytes read. I know the
offset is valid, as we’ve already written drivers for Win9x and NT4
(working with CardWare) using this offset.

Because AddDevice is running at < DISPATCH_LEVEL, I also tried sending an
IRP of type IRP_MN_READ_CONFIG with WhichSpace = PCCARD_ATTRIBUTE_MEMORY
down to the PDO. The result was a successful status code, but the Irp’s
IoStatus.Information was set to 0, indicating 0 bytes were read.

According to the Win2k DDK, calling these functions/Irps are perfectly
legal anytime after AddDevice has been called. So my question is: What
could I be doing wrong that results in 0 bytes being read? The fact that
both methods result in 0 bytes read indicates to me that I’ve done
something wrong in either the way I’m making these calls or how I’m setting
up the device. I’ve tried them before and after I call
IoAttachDeviceToDeviceStack, and it seems to make no difference, as it
shouldn’t according to the DDK.

Any guidance/suggestions would be greatly appreciated.

Thank you,
Curtis Coleman


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Curtis,

You’re close.

One definate issue is that the slot is not guaranteed to be ‘started’ nor
‘powered up’ during your AddDevice. Try the same thing in your
IRP_MN_START_DEVICE handler, AFTER the IRP_MN_START IRP has been completed
by the PCMCIA Bus Driver (on the ‘way back up’).

Another distinct, common, and quite frustrating possibility is that another
ISA device (or motherboard device that is not reported to the OS by your
machine’s BIOS) is decoding those exact same memory addresses, but does not
have a driver loaded. Since no driver is loaded, the BIOS did not describe
the region as reserved, and/or it’s a legacy ISA device that’s decoding the
same addresses, the OS doesn’t know about that device and happily assigned
your device those memory addresses.

This scenario exists because the 640K to 1MB region is very scarce by todays
standards, and used by lots of hardware, some of which has been around for
quite some time. Try reserving (in your machine’s BIOS) the region that
your card is being assigned, so the OS will try to put it somewhere else.
You might also try your card in a different system.

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@viasat.com
Sent: Friday, July 27, 2001 7:43 PM
To: NT Developers Interest List
Subject: [ntdev] GetBusData returns 0 bytes read for PCMCIA Attribute
read

Hello,

I am presently working on a Windows 2000 driver for a PCMCIA card. I need
to be able to read to and write from the card’s attribute memory
from IRQL
DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be
the logical
solution.

In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp
down to the
PDO that is provided as a parameter of AddDevice. The call to the PDO
returns a successful status code and my BUS_INTERFACE_STANDARD
structure is
filled. However, every time I try to read a single byte from an
offset that
I know is valid, the call to GetBusData returns 0 bytes read. I know the
offset is valid, as we’ve already written drivers for Win9x and NT4
(working with CardWare) using this offset.

Because AddDevice is running at < DISPATCH_LEVEL, I also tried sending an
IRP of type IRP_MN_READ_CONFIG with WhichSpace = PCCARD_ATTRIBUTE_MEMORY
down to the PDO. The result was a successful status code, but the Irp’s
IoStatus.Information was set to 0, indicating 0 bytes were read.

According to the Win2k DDK, calling these functions/Irps are perfectly
legal anytime after AddDevice has been called. So my question is: What
could I be doing wrong that results in 0 bytes being read? The fact that
both methods result in 0 bytes read indicates to me that I’ve done
something wrong in either the way I’m making these calls or how
I’m setting
up the device. I’ve tried them before and after I call
IoAttachDeviceToDeviceStack, and it seems to make no difference, as it
shouldn’t according to the DDK.

Any guidance/suggestions would be greatly appreciated.

Thank you,
Curtis Coleman


You are currently subscribed to ntdev as: xxxxx@driverdev.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Tim,

I tried doing the IRP_MN_QUERY_INTERFACE and GetBusData reads at the tail
end of my IRP_MN_START_DEVICE handler, but the results remained the same.
The number of bytes read is always 0.

Regarding the possibility of resource conflicts, the only other ISA device
that I’m aware of on the system is the ISA to PCMCIA adapter (an SCM
SwapBox). Nevertheless, I will try out your suggestion to reserve in the
BIOS the memory region typically allocated to the device.

Thank you for your help.

  • Curtis

On 07/27/01, ““Timothy A. Johns” ” wrote:
> Curtis,
>
> You’re close.
>
> One definate issue is that the slot is not guaranteed to be ‘started’ nor
> ‘powered up’ during your AddDevice. Try the same thing in your
> IRP_MN_START_DEVICE handler, AFTER the IRP_MN_START IRP has been completed
> by the PCMCIA Bus Driver (on the ‘way back up’).
>
> Another distinct, common, and quite frustrating possibility is that another
> ISA device (or motherboard device that is not reported to the OS by your
> machine’s BIOS) is decoding those exact same memory addresses, but does not
> have a driver loaded. Since no driver is loaded, the BIOS did not describe
> the region as reserved, and/or it’s a legacy ISA device that’s decoding the
> same addresses, the OS doesn’t know about that device and happily assigned
> your device those memory addresses.
>
> This scenario exists because the 640K to 1MB region is very scarce by todays
> standards, and used by lots of hardware, some of which has been around for
> quite some time. Try reserving (in your machine’s BIOS) the region that
> your card is being assigned, so the OS will try to put it somewhere else.
> You might also try your card in a different system.
>
> -Tim
>
> Timothy A. Johns — xxxxx@driverdev.com
> Driver Development Corporation — 800.841.0092
> Bring Up Your Hardware — Fast. www.driverdev.com
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > xxxxx@viasat.com
> > Sent: Friday, July 27, 2001 7:43 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] GetBusData returns 0 bytes read for PCMCIA Attribute
> > read
> >
> >
> > Hello,
> >
> > I am presently working on a Windows 2000 driver for a PCMCIA card. I need
> > to be able to read to and write from the card’s attribute memory
> > from IRQL
> > DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be
> > the logical
> > solution.
> >
> > In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp
> > down to the
> > PDO that is provided as a parameter of AddDevice. The call to the PDO
> > returns a successful status code and my BUS_INTERFACE_STANDARD
> > structure is
> > filled. However, every time I try to read a single byte from an
> > offset that
> > I know is valid, the call to GetBusData returns 0 bytes read. I know the
> > offset is valid, as we’ve already written drivers for Win9x and NT4
> > (working with CardWare) using this offset.
> >
> > Because AddDevice is running at < DISPATCH_LEVEL, I also tried sending an
> > IRP of type IRP_MN_READ_CONFIG with WhichSpace = PCCARD_ATTRIBUTE_MEMORY
> > down to the PDO. The result was a successful status code, but the Irp’s
> > IoStatus.Information was set to 0, indicating 0 bytes were read.
> >
> > According to the Win2k DDK, calling these functions/Irps are perfectly
> > legal anytime after AddDevice has been called. So my question is: What
> > could I be doing wrong that results in 0 bytes being read? The fact that
> > both methods result in 0 bytes read indicates to me that I’ve done
> > something wrong in either the way I’m making these calls or how
> > I’m setting
> > up the device. I’ve tried them before and after I call
> > IoAttachDeviceToDeviceStack, and it seems to make no difference, as it
> > shouldn’t according to the DDK.
> >
> > Any guidance/suggestions would be greatly appreciated.
> >
> > Thank you,
> > Curtis Coleman
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Curtis,

I was confused - my impression was that the value you read, not the number
of bytes read, was zero. This is unlikely due to a conflict.

Another thought - are you sure that you’re layered over a PDO created by the
PCMCIA bus driver? You can use
IoGetDeviceProperty(DevicePropertyEnumeratorName) to check this. if you get
anything other than “PCMCIA” you’re layered over something else.

A final thought - try installing the checked build of PCMCIA.SYS (you’ll
have to disable SFP), and use WinDBG to modify the debug level and or mask
to 0xFFFFFFFF. I forget what the symbols are, but “X *debug*” and “X
*level*” should probably find them. You’ll need the checked symbol file for
PCMCIA.SYS as well (either PCMCIA.DBG or PCMCIA.PDB, or both).

After enabling those flags/levels, I strongly suspect PCMCIA.SYS will spit
out some serious KdPrint()s when you try to do the read.

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@viasat.com
Sent: Friday, July 27, 2001 10:00 PM
To: NT Developers Interest List
Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
Attribute read

Tim,

I tried doing the IRP_MN_QUERY_INTERFACE and GetBusData reads at the tail
end of my IRP_MN_START_DEVICE handler, but the results remained the same.
The number of bytes read is always 0.

Regarding the possibility of resource conflicts, the only other
ISA device
that I’m aware of on the system is the ISA to PCMCIA adapter (an SCM
SwapBox). Nevertheless, I will try out your suggestion to reserve in the
BIOS the memory region typically allocated to the device.

Thank you for your help.

  • Curtis

On 07/27/01, ““Timothy A. Johns” ” wrote:
> > Curtis,
> >
> > You’re close.
> >
> > One definate issue is that the slot is not guaranteed to be
> ‘started’ nor
> > ‘powered up’ during your AddDevice. Try the same thing in your
> > IRP_MN_START_DEVICE handler, AFTER the IRP_MN_START IRP has
> been completed
> > by the PCMCIA Bus Driver (on the ‘way back up’).
> >
> > Another distinct, common, and quite frustrating possibility is
> that another
> > ISA device (or motherboard device that is not reported to the OS by your
> > machine’s BIOS) is decoding those exact same memory addresses,
> but does not
> > have a driver loaded. Since no driver is loaded, the BIOS did
> not describe
> > the region as reserved, and/or it’s a legacy ISA device that’s
> decoding the
> > same addresses, the OS doesn’t know about that device and
> happily assigned
> > your device those memory addresses.
> >
> > This scenario exists because the 640K to 1MB region is very
> scarce by todays
> > standards, and used by lots of hardware, some of which has been
> around for
> > quite some time. Try reserving (in your machine’s BIOS) the region that
> > your card is being assigned, so the OS will try to put it
> somewhere else.
> > You might also try your card in a different system.
> >
> > -Tim
> >
> > Timothy A. Johns — xxxxx@driverdev.com
> > Driver Development Corporation — 800.841.0092
> > Bring Up Your Hardware — Fast. www.driverdev.com
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > > xxxxx@viasat.com
> > > Sent: Friday, July 27, 2001 7:43 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] GetBusData returns 0 bytes read for PCMCIA Attribute
> > > read
> > >
> > >
> > > Hello,
> > >
> > > I am presently working on a Windows 2000 driver for a PCMCIA
> card. I need
> > > to be able to read to and write from the card’s attribute memory
> > > from IRQL
> > > DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be
> > > the logical
> > > solution.
> > >
> > > In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp
> > > down to the
> > > PDO that is provided as a parameter of AddDevice. The call to the PDO
> > > returns a successful status code and my BUS_INTERFACE_STANDARD
> > > structure is
> > > filled. However, every time I try to read a single byte from an
> > > offset that
> > > I know is valid, the call to GetBusData returns 0 bytes read.
> I know the
> > > offset is valid, as we’ve already written drivers for Win9x and NT4
> > > (working with CardWare) using this offset.
> > >
> > > Because AddDevice is running at < DISPATCH_LEVEL, I also
> tried sending an
> > > IRP of type IRP_MN_READ_CONFIG with WhichSpace =
> PCCARD_ATTRIBUTE_MEMORY
> > > down to the PDO. The result was a successful status code, but
> the Irp’s
> > > IoStatus.Information was set to 0, indicating 0 bytes were read.
> > >
> > > According to the Win2k DDK, calling these functions/Irps are perfectly
> > > legal anytime after AddDevice has been called. So my question is: What
> > > could I be doing wrong that results in 0 bytes being read?
> The fact that
> > > both methods result in 0 bytes read indicates to me that I’ve done
> > > something wrong in either the way I’m making these calls or how
> > > I’m setting
> > > up the device. I’ve tried them before and after I call
> > > IoAttachDeviceToDeviceStack, and it seems to make no difference, as it
> > > shouldn’t according to the DDK.
> > >
> > > Any guidance/suggestions would be greatly appreciated.
> > >
> > > Thank you,
> > > Curtis Coleman
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@driverdev.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Tim,

Calling IoGetDeviceProperty with the property DevicePropertyEnumeratorName
does return “PCMCIA” as it should.

My target system is already running a checked build of Win2k (SP2), and
I’ve already set up the symbols for it. The checked build should already
have the debug version of PCMCIA.sys, right? I’ve also set the symbols path
in WinDbg to the path where all of the symbol subdirectories reside, and it
seems to find the symbols okay during bug checks, etc.

I’m not quite sure how to set the debug level in WinDbg. I’ve tried doing a
“X *debug*”, “X *level*”, and several other variations, but the Examine
Symbols command doesn’t seem to do anything. I’ve looked through the
documentation for WinDbg and the DDK, but haven’t found anything that
describes what I need to do. Searching through Microsoft’s articles, I
found an article on how to set the debug level for NDIS.sys, and tried to
use the same method for PCMCIA.sys, but I saw no additional debug output.
In case you’re curious, the address of the article is:
http://support.microsoft.com/support/kb/articles/q248/4/13.asp.

I’m sure that the method of setting the debug level is probably quite
simple, and that I’m just missing it or looking in the wrong place. If you
could point me in the right direction, I’d really appreciate it.

Thank you,
Curtis

On 07/28/01, ““Timothy A. Johns” ” wrote:
> Curtis,
>
> I was confused - my impression was that the value you read, not the number
> of bytes read, was zero. This is unlikely due to a conflict.
>
> Another thought - are you sure that you’re layered over a PDO created by the
> PCMCIA bus driver? You can use
> IoGetDeviceProperty(DevicePropertyEnumeratorName) to check this. if you get
> anything other than “PCMCIA” you’re layered over something else.
>
> A final thought - try installing the checked build of PCMCIA.SYS (you’ll
> have to disable SFP), and use WinDBG to modify the debug level and or mask
> to 0xFFFFFFFF. I forget what the symbols are, but “X debug” and “X
> level” should probably find them. You’ll need the checked symbol file for
> PCMCIA.SYS as well (either PCMCIA.DBG or PCMCIA.PDB, or both).
>
> After enabling those flags/levels, I strongly suspect PCMCIA.SYS will spit
> out some serious KdPrint()s when you try to do the read.
>
> -Tim
>
>
> Timothy A. Johns — xxxxx@driverdev.com
> Driver Development Corporation — 800.841.0092
> Bring Up Your Hardware — Fast. www.driverdev.com
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > xxxxx@viasat.com
> > Sent: Friday, July 27, 2001 10:00 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
> > Attribute read
> >
> >
> > Tim,
> >
> > I tried doing the IRP_MN_QUERY_INTERFACE and GetBusData reads at the tail
> > end of my IRP_MN_START_DEVICE handler, but the results remained the same.
> > The number of bytes read is always 0.
> >
> > Regarding the possibility of resource conflicts, the only other
> > ISA device
> > that I’m aware of on the system is the ISA to PCMCIA adapter (an SCM
> > SwapBox). Nevertheless, I will try out your suggestion to reserve in the
> > BIOS the memory region typically allocated to the device.
> >
> > Thank you for your help.
> >
> > - Curtis
> >
> > On 07/27/01, ““Timothy A. Johns” ” wrote:
> > > Curtis,
> > >
> > > You’re close.
> > >
> > > One definate issue is that the slot is not guaranteed to be
> > ‘started’ nor
> > > ‘powered up’ during your AddDevice. Try the same thing in your
> > > IRP_MN_START_DEVICE handler, AFTER the IRP_MN_START IRP has
> > been completed
> > > by the PCMCIA Bus Driver (on the ‘way back up’).
> > >
> > > Another distinct, common, and quite frustrating possibility is
> > that another
> > > ISA device (or motherboard device that is not reported to the OS by your
> > > machine’s BIOS) is decoding those exact same memory addresses,
> > but does not
> > > have a driver loaded. Since no driver is loaded, the BIOS did
> > not describe
> > > the region as reserved, and/or it’s a legacy ISA device that’s
> > decoding the
> > > same addresses, the OS doesn’t know about that device and
> > happily assigned
> > > your device those memory addresses.
> > >
> > > This scenario exists because the 640K to 1MB region is very
> > scarce by todays
> > > standards, and used by lots of hardware, some of which has been
> > around for
> > > quite some time. Try reserving (in your machine’s BIOS) the region that
> > > your card is being assigned, so the OS will try to put it
> > somewhere else.
> > > You might also try your card in a different system.
> > >
> > > -Tim
> > >
> > > Timothy A. Johns — xxxxx@driverdev.com
> > > Driver Development Corporation — 800.841.0092
> > > Bring Up Your Hardware — Fast. www.driverdev.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > > > xxxxx@viasat.com
> > > > Sent: Friday, July 27, 2001 7:43 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] GetBusData returns 0 bytes read for PCMCIA Attribute
> > > > read
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I am presently working on a Windows 2000 driver for a PCMCIA
> > card. I need
> > > > to be able to read to and write from the card’s attribute memory
> > > > from IRQL
> > > > DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be
> > > > the logical
> > > > solution.
> > > >
> > > > In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp
> > > > down to the
> > > > PDO that is provided as a parameter of AddDevice. The call to the PDO
> > > > returns a successful status code and my BUS_INTERFACE_STANDARD
> > > > structure is
> > > > filled. However, every time I try to read a single byte from an
> > > > offset that
> > > > I know is valid, the call to GetBusData returns 0 bytes read.
> > I know the
> > > > offset is valid, as we’ve already written drivers for Win9x and NT4
> > > > (working with CardWare) using this offset.
> > > >
> > > > Because AddDevice is running at < DISPATCH_LEVEL, I also
> > tried sending an
> > > > IRP of type IRP_MN_READ_CONFIG with WhichSpace =
> > PCCARD_ATTRIBUTE_MEMORY
> > > > down to the PDO. The result was a successful status code, but
> > the Irp’s
> > > > IoStatus.Information was set to 0, indicating 0 bytes were read.
> > > >
> > > > According to the Win2k DDK, calling these functions/Irps are perfectly
> > > > legal anytime after AddDevice has been called. So my question is: What
> > > > could I be doing wrong that results in 0 bytes being read?
> > The fact that
> > > > both methods result in 0 bytes read indicates to me that I’ve done
> > > > something wrong in either the way I’m making these calls or how
> > > > I’m setting
> > > > up the device. I’ve tried them before and after I call
> > > > IoAttachDeviceToDeviceStack, and it seems to make no difference, as it
> > > > shouldn’t according to the DDK.
> > > >
> > > > Any guidance/suggestions would be greatly appreciated.
> > > >
> > > > Thank you,
> > > > Curtis Coleman
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Set PcmicaDebugMask to 0xff. Use ED PCMICA!PCMICADEBUGMASK

Bryan

-----Original Message-----
From: xxxxx@viasat.com [mailto:xxxxx@viasat.com]
Sent: Monday, July 30, 2001 8:59 AM
To: NT Developers Interest List
Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
Attribute read

Tim,

Calling IoGetDeviceProperty with the property
DevicePropertyEnumeratorName
does return “PCMCIA” as it should.

My target system is already running a checked build of Win2k (SP2), and
I’ve already set up the symbols for it. The checked build should already

have the debug version of PCMCIA.sys, right? I’ve also set the symbols
path
in WinDbg to the path where all of the symbol subdirectories reside, and
it
seems to find the symbols okay during bug checks, etc.

I’m not quite sure how to set the debug level in WinDbg. I’ve tried
doing a
“X *debug*”, “X *level*”, and several other variations, but the Examine
Symbols command doesn’t seem to do anything. I’ve looked through the
documentation for WinDbg and the DDK, but haven’t found anything that
describes what I need to do. Searching through Microsoft’s articles, I
found an article on how to set the debug level for NDIS.sys, and tried
to
use the same method for PCMCIA.sys, but I saw no additional debug
output.
In case you’re curious, the address of the article is:
http://support.microsoft.com/support/kb/articles/q248/4/13.asp.

I’m sure that the method of setting the debug level is probably quite
simple, and that I’m just missing it or looking in the wrong place. If
you
could point me in the right direction, I’d really appreciate it.

Thank you,
Curtis

On 07/28/01, ““Timothy A. Johns” ” wrote:
> Curtis,
>
> I was confused - my impression was that the value you read, not the
number
> of bytes read, was zero. This is unlikely due to a conflict.
>
> Another thought - are you sure that you’re layered over a PDO created
by the
> PCMCIA bus driver? You can use
> IoGetDeviceProperty(DevicePropertyEnumeratorName) to check this. if
you get
> anything other than “PCMCIA” you’re layered over something else.
>
> A final thought - try installing the checked build of PCMCIA.SYS
(you’ll
> have to disable SFP), and use WinDBG to modify the debug level and or
mask
> to 0xFFFFFFFF. I forget what the symbols are, but “X debug” and “X
> level” should probably find them. You’ll need the checked symbol
file for
> PCMCIA.SYS as well (either PCMCIA.DBG or PCMCIA.PDB, or both).
>
> After enabling those flags/levels, I strongly suspect PCMCIA.SYS will
spit
> out some serious KdPrint()s when you try to do the read.
>
> -Tim
>
>
> Timothy A. Johns — xxxxx@driverdev.com
> Driver Development Corporation — 800.841.0092
> Bring Up Your Hardware — Fast. www.driverdev.com
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > xxxxx@viasat.com
> > Sent: Friday, July 27, 2001 10:00 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
> > Attribute read
> >
> >
> > Tim,
> >
> > I tried doing the IRP_MN_QUERY_INTERFACE and GetBusData reads at the
tail
> > end of my IRP_MN_START_DEVICE handler, but the results remained the
same.
> > The number of bytes read is always 0.
> >
> > Regarding the possibility of resource conflicts, the only other
> > ISA device
> > that I’m aware of on the system is the ISA to PCMCIA adapter (an SCM
> > SwapBox). Nevertheless, I will try out your suggestion to reserve in
the
> > BIOS the memory region typically allocated to the device.
> >
> > Thank you for your help.
> >
> > - Curtis
> >
> > On 07/27/01, ““Timothy A. Johns” ” wrote:
> > > Curtis,
> > >
> > > You’re close.
> > >
> > > One definate issue is that the slot is not guaranteed to be
> > ‘started’ nor
> > > ‘powered up’ during your AddDevice. Try the same thing in your
> > > IRP_MN_START_DEVICE handler, AFTER the IRP_MN_START IRP has
> > been completed
> > > by the PCMCIA Bus Driver (on the ‘way back up’).
> > >
> > > Another distinct, common, and quite frustrating possibility is
> > that another
> > > ISA device (or motherboard device that is not reported to the OS
by your
> > > machine’s BIOS) is decoding those exact same memory addresses,
> > but does not
> > > have a driver loaded. Since no driver is loaded, the BIOS did
> > not describe
> > > the region as reserved, and/or it’s a legacy ISA device that’s
> > decoding the
> > > same addresses, the OS doesn’t know about that device and
> > happily assigned
> > > your device those memory addresses.
> > >
> > > This scenario exists because the 640K to 1MB region is very
> > scarce by todays
> > > standards, and used by lots of hardware, some of which has been
> > around for
> > > quite some time. Try reserving (in your machine’s BIOS) the
region that
> > > your card is being assigned, so the OS will try to put it
> > somewhere else.
> > > You might also try your card in a different system.
> > >
> > > -Tim
> > >
> > > Timothy A. Johns — xxxxx@driverdev.com
> > > Driver Development Corporation — 800.841.0092
> > > Bring Up Your Hardware — Fast. www.driverdev.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > > > xxxxx@viasat.com
> > > > Sent: Friday, July 27, 2001 7:43 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] GetBusData returns 0 bytes read for PCMCIA
Attribute
> > > > read
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I am presently working on a Windows 2000 driver for a PCMCIA
> > card. I need
> > > > to be able to read to and write from the card’s attribute memory
> > > > from IRQL
> > > > DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be
> > > > the logical
> > > > solution.
> > > >
> > > > In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp
> > > > down to the
> > > > PDO that is provided as a parameter of AddDevice. The call to
the PDO
> > > > returns a successful status code and my BUS_INTERFACE_STANDARD
> > > > structure is
> > > > filled. However, every time I try to read a single byte from an
> > > > offset that
> > > > I know is valid, the call to GetBusData returns 0 bytes read.
> > I know the
> > > > offset is valid, as we’ve already written drivers for Win9x and
NT4
> > > > (working with CardWare) using this offset.
> > > >
> > > > Because AddDevice is running at < DISPATCH_LEVEL, I also
> > tried sending an
> > > > IRP of type IRP_MN_READ_CONFIG with WhichSpace =
> > PCCARD_ATTRIBUTE_MEMORY
> > > > down to the PDO. The result was a successful status code, but
> > the Irp’s
> > > > IoStatus.Information was set to 0, indicating 0 bytes were read.
> > > >
> > > > According to the Win2k DDK, calling these functions/Irps are
perfectly
> > > > legal anytime after AddDevice has been called. So my question
is: What
> > > > could I be doing wrong that results in 0 bytes being read?
> > The fact that
> > > > both methods result in 0 bytes read indicates to me that I’ve
done
> > > > something wrong in either the way I’m making these calls or how
> > > > I’m setting
> > > > up the device. I’ve tried them before and after I call
> > > > IoAttachDeviceToDeviceStack, and it seems to make no difference,
as it
> > > > shouldn’t according to the DDK.
> > > >
> > > > Any guidance/suggestions would be greatly appreciated.
> > > >
> > > > Thank you,
> > > > Curtis Coleman
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > > To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Curtis,

You’re close - you probably just need to specify the module - try “x
PCMCIA!*”,“x PCMCIA!*level*”, etc.

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@viasat.com
Sent: Monday, July 30, 2001 3:59 PM
To: NT Developers Interest List
Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
Attribute read

Tim,

Calling IoGetDeviceProperty with the property
DevicePropertyEnumeratorName
does return “PCMCIA” as it should.

My target system is already running a checked build of Win2k (SP2), and
I’ve already set up the symbols for it. The checked build should already
have the debug version of PCMCIA.sys, right? I’ve also set the
symbols path
in WinDbg to the path where all of the symbol subdirectories
reside, and it
seems to find the symbols okay during bug checks, etc.

I’m not quite sure how to set the debug level in WinDbg. I’ve
tried doing a
“X *debug*”, “X *level*”, and several other variations, but the Examine
Symbols command doesn’t seem to do anything. I’ve looked through the
documentation for WinDbg and the DDK, but haven’t found anything that
describes what I need to do. Searching through Microsoft’s articles, I
found an article on how to set the debug level for NDIS.sys, and tried to
use the same method for PCMCIA.sys, but I saw no additional debug output.
In case you’re curious, the address of the article is:
http://support.microsoft.com/support/kb/articles/q248/4/13.asp.

I’m sure that the method of setting the debug level is probably quite
simple, and that I’m just missing it or looking in the wrong
place. If you
could point me in the right direction, I’d really appreciate it.

Thank you,
Curtis

On 07/28/01, ““Timothy A. Johns” ” wrote:
> > Curtis,
> >
> > I was confused - my impression was that the value you read, not
> the number
> > of bytes read, was zero. This is unlikely due to a conflict.
> >
> > Another thought - are you sure that you’re layered over a PDO
> created by the
> > PCMCIA bus driver? You can use
> > IoGetDeviceProperty(DevicePropertyEnumeratorName) to check
> this. if you get
> > anything other than “PCMCIA” you’re layered over something else.
> >
> > A final thought - try installing the checked build of PCMCIA.SYS (you’ll
> > have to disable SFP), and use WinDBG to modify the debug level
> and or mask
> > to 0xFFFFFFFF. I forget what the symbols are, but “X debug” and “X
> > level” should probably find them. You’ll need the checked
> symbol file for
> > PCMCIA.SYS as well (either PCMCIA.DBG or PCMCIA.PDB, or both).
> >
> > After enabling those flags/levels, I strongly suspect
> PCMCIA.SYS will spit
> > out some serious KdPrint()s when you try to do the read.
> >
> > -Tim
> >
> >
> > Timothy A. Johns — xxxxx@driverdev.com
> > Driver Development Corporation — 800.841.0092
> > Bring Up Your Hardware — Fast. www.driverdev.com
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > > xxxxx@viasat.com
> > > Sent: Friday, July 27, 2001 10:00 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
> > > Attribute read
> > >
> > >
> > > Tim,
> > >
> > > I tried doing the IRP_MN_QUERY_INTERFACE and GetBusData reads
> at the tail
> > > end of my IRP_MN_START_DEVICE handler, but the results
> remained the same.
> > > The number of bytes read is always 0.
> > >
> > > Regarding the possibility of resource conflicts, the only other
> > > ISA device
> > > that I’m aware of on the system is the ISA to PCMCIA adapter (an SCM
> > > SwapBox). Nevertheless, I will try out your suggestion to
> reserve in the
> > > BIOS the memory region typically allocated to the device.
> > >
> > > Thank you for your help.
> > >
> > > - Curtis
> > >
> > > On 07/27/01, ““Timothy A. Johns” ” wrote:
> > > > Curtis,
> > > >
> > > > You’re close.
> > > >
> > > > One definate issue is that the slot is not guaranteed to be
> > > ‘started’ nor
> > > > ‘powered up’ during your AddDevice. Try the same thing in your
> > > > IRP_MN_START_DEVICE handler, AFTER the IRP_MN_START IRP has
> > > been completed
> > > > by the PCMCIA Bus Driver (on the ‘way back up’).
> > > >
> > > > Another distinct, common, and quite frustrating possibility is
> > > that another
> > > > ISA device (or motherboard device that is not reported to
> the OS by your
> > > > machine’s BIOS) is decoding those exact same memory addresses,
> > > but does not
> > > > have a driver loaded. Since no driver is loaded, the BIOS did
> > > not describe
> > > > the region as reserved, and/or it’s a legacy ISA device that’s
> > > decoding the
> > > > same addresses, the OS doesn’t know about that device and
> > > happily assigned
> > > > your device those memory addresses.
> > > >
> > > > This scenario exists because the 640K to 1MB region is very
> > > scarce by todays
> > > > standards, and used by lots of hardware, some of which has been
> > > around for
> > > > quite some time. Try reserving (in your machine’s BIOS)
> the region that
> > > > your card is being assigned, so the OS will try to put it
> > > somewhere else.
> > > > You might also try your card in a different system.
> > > >
> > > > -Tim
> > > >
> > > > Timothy A. Johns — xxxxx@driverdev.com
> > > > Driver Development Corporation — 800.841.0092
> > > > Bring Up Your Hardware — Fast. www.driverdev.com
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > > > > xxxxx@viasat.com
> > > > > Sent: Friday, July 27, 2001 7:43 PM
> > > > > To: NT Developers Interest List
> > > > > Subject: [ntdev] GetBusData returns 0 bytes read for
> PCMCIA Attribute
> > > > > read
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > I am presently working on a Windows 2000 driver for a PCMCIA
> > > card. I need
> > > > > to be able to read to and write from the card’s attribute memory
> > > > > from IRQL
> > > > > DISPATCH_LEVEL, so using the BUS_INTERFACE_STANDARD seems to be
> > > > > the logical
> > > > > solution.
> > > > >
> > > > > In the AddDevice function, I send an IRP_MN_QUERY_INTERFACE Irp
> > > > > down to the
> > > > > PDO that is provided as a parameter of AddDevice. The
> call to the PDO
> > > > > returns a successful status code and my BUS_INTERFACE_STANDARD
> > > > > structure is
> > > > > filled. However, every time I try to read a single byte from an
> > > > > offset that
> > > > > I know is valid, the call to GetBusData returns 0 bytes read.
> > > I know the
> > > > > offset is valid, as we’ve already written drivers for
> Win9x and NT4
> > > > > (working with CardWare) using this offset.
> > > > >
> > > > > Because AddDevice is running at < DISPATCH_LEVEL, I also
> > > tried sending an
> > > > > IRP of type IRP_MN_READ_CONFIG with WhichSpace =
> > > PCCARD_ATTRIBUTE_MEMORY
> > > > > down to the PDO. The result was a successful status code, but
> > > the Irp’s
> > > > > IoStatus.Information was set to 0, indicating 0 bytes were read.
> > > > >
> > > > > According to the Win2k DDK, calling these functions/Irps
> are perfectly
> > > > > legal anytime after AddDevice has been called. So my
> question is: What
> > > > > could I be doing wrong that results in 0 bytes being read?
> > > The fact that
> > > > > both methods result in 0 bytes read indicates to me that I’ve done
> > > > > something wrong in either the way I’m making these calls or how
> > > > > I’m setting
> > > > > up the device. I’ve tried them before and after I call
> > > > > IoAttachDeviceToDeviceStack, and it seems to make no
> difference, as it
> > > > > shouldn’t according to the DDK.
> > > > >
> > > > > Any guidance/suggestions would be greatly appreciated.
> > > > >
> > > > > Thank you,
> > > > > Curtis Coleman
> > > > >
> > > > > —
> > > > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > > > To unsubscribe send a blank email to
> leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@driverdev.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thank you Tim and Bryan for your help. I was able to increase the debug
level of pcmcia.sys (setting pcmcia!PcmciaDebugMask to 0xFFFFFFFF) and
thereby gain some useful information.

Turning on the debug info made me realize that IRP_MN_READ_CONFIG is
successfully reading from the configuration space (at least the CIS) but
just returns 0 bytes read in pIrp->IoStatus.Information. According to the
DDK, this should not be the case, but oh well. Calling GetBusData does not
have the same behavior. I call RtlZeroMemory beforehand, and after
GetBusData returns 0 (the number of bytes read), the supplied buffer
remains all zeroes.

There are two issues that I’m now faced with:

  1. While it is reassuring that I can read from the CIS (offset 0) using
    IRP_MN_READ_CONFIG, when I read from a register at a known offset, the
    value read is 0, when it should be non-zero. I also tried writing to the
    offset, and then reading, but saw no change in the value. This offset has
    been used in past drivers for the card, but for some reason does not seem
    to be valid with the IRP_MN_XXXX_CONFIG method.

  2. I need to be able to read and write to a pair of registers in Attribute
    memory at IRQL DISPATCH_LEVEL. For this reason, even if I manage to get
    reads and writes with these registers working through IRP_MN_READ_CONFIG
    and IRP_MN_WRITE_CONFIG, I still need to get GetBusData and SetBusData
    working. The reason why I paid more attention to the IRP method of reading
    and writing is that much more debug information was printed out by
    pcmcia.sys from those operations. It looked like it was actually doing
    something, whereas the GetBusData calls only invoke a single line of debug
    information:

Pcmcia IFC: pdo 84392df8 read card memory

That’s it.
The calls to IRP_MN_READ_CONFIG yield debug info like this:

Pcmcia PNP: pdo 84392df8 irp 8437a008 –> IRP_MN_READ_CONFIG
Pcmcia SKT: skt 84561b08 request power
Pcmcia SKT: skt 84561b08 power worker - SPW_RequestPower
Pcmcia SKT: skt 84561b08 power requests now 2, status 00000000
Pcmcia SKT: skt 84561b08 power worker - SPW_Exit
Pcmcia SKT: skt 84561b08 RequestSocketPower returning, status=00000000
Pcmcia INF: Stall! 3000 usec
Pcmcia INF: skt 84561b08 memory window 1 enabled df000
Pcmcia INF: skt 84561b08 memory window 1 disabled
Pcmcia INF: PcicReadCardMemory: 0xf75c9080 ==> 0xf7443b68
Pcmcia INF: PcicReadCardMemory: 00 01 03 61 08 FF 17 04-67 5A 08 FF 1C 04
01 64
Pcmcia SKT: skt 84561b08 release power
Pcmcia SKT: skt 84561b08 power worker - SPW_ReleasePower
Pcmcia SKT: skt 84561b08 decrementing power requests to 1
Pcmcia SKT: skt 84561b08 power worker - SPW_Exit
Pcmcia SKT: skt 84561b08 ReleaseSocketPower returning 00000000
Pcmcia PNP: pdo 84392df8 irp 8437a008 comp STATUS_SUCCESS 00000000

The bytes listed in the second PcicReadCardMemory line are the first 16
bytes of the CIS, and match the data actually read.

It seems like the lack of debug activity for GetBusData would indicate
something is going wrong. My question to you (anybody really) is have you
ever gotten GetBusData and SetBusData to work with reading from and writing
to a register in a PCMCIA card’s attribute memory using the
BUS_INTERFACE_STANDARD? The interface is supposedly successfully acquired
by an IRP_MN_QUERY_INTERFACE, but, once again, only a single debug line is
generated:

Pcmcia PNP: pdo 84392df8 irp 8437a008 –> IRP_MN_QUERY_INTERFACE

This gives no indication of processing the request, but one would assume
that it was processed since the IRP results in a successful status.

If anyone has gotten the BUS_INTERFACE_STANDARD to work with a PCMCIA card,
could you indicate what tricks, if any, were necessary to successfully read
and write to a register in the attribute memory?

Thank you,
Curtis Coleman


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Curtis,

One more thing you can try, especially now that you have the symbols loaded,
etc. - try stepping into the call to GetBusData, to see what it actually
does, and what functions it calls.

-Tim

Timothy A. Johns — xxxxx@driverdev.com
Driver Development Corporation — 800.841.0092
Bring Up Your Hardware — Fast. www.driverdev.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@viasat.com
Sent: Monday, July 30, 2001 10:00 PM
To: NT Developers Interest List
Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
Attribute read

Thank you Tim and Bryan for your help. I was able to increase the debug
level of pcmcia.sys (setting pcmcia!PcmciaDebugMask to 0xFFFFFFFF) and
thereby gain some useful information.

Turning on the debug info made me realize that IRP_MN_READ_CONFIG is
successfully reading from the configuration space (at least the CIS) but
just returns 0 bytes read in pIrp->IoStatus.Information. According to the
DDK, this should not be the case, but oh well. Calling GetBusData
does not
have the same behavior. I call RtlZeroMemory beforehand, and after
GetBusData returns 0 (the number of bytes read), the supplied buffer
remains all zeroes.

There are two issues that I’m now faced with:

  1. While it is reassuring that I can read from the CIS (offset 0) using
    IRP_MN_READ_CONFIG, when I read from a register at a known offset, the
    value read is 0, when it should be non-zero. I also tried writing to the
    offset, and then reading, but saw no change in the value. This offset has
    been used in past drivers for the card, but for some reason does not seem
    to be valid with the IRP_MN_XXXX_CONFIG method.

  2. I need to be able to read and write to a pair of registers in
    Attribute
    memory at IRQL DISPATCH_LEVEL. For this reason, even if I manage to get
    reads and writes with these registers working through IRP_MN_READ_CONFIG
    and IRP_MN_WRITE_CONFIG, I still need to get GetBusData and SetBusData
    working. The reason why I paid more attention to the IRP method
    of reading
    and writing is that much more debug information was printed out by
    pcmcia.sys from those operations. It looked like it was actually doing
    something, whereas the GetBusData calls only invoke a single line
    of debug
    information:

Pcmcia IFC: pdo 84392df8 read card memory

That’s it.
The calls to IRP_MN_READ_CONFIG yield debug info like this:

Pcmcia PNP: pdo 84392df8 irp 8437a008 –> IRP_MN_READ_CONFIG
Pcmcia SKT: skt 84561b08 request power
Pcmcia SKT: skt 84561b08 power worker - SPW_RequestPower
Pcmcia SKT: skt 84561b08 power requests now 2, status 00000000
Pcmcia SKT: skt 84561b08 power worker - SPW_Exit
Pcmcia SKT: skt 84561b08 RequestSocketPower returning, status=00000000
Pcmcia INF: Stall! 3000 usec
Pcmcia INF: skt 84561b08 memory window 1 enabled df000
Pcmcia INF: skt 84561b08 memory window 1 disabled
Pcmcia INF: PcicReadCardMemory: 0xf75c9080 ==> 0xf7443b68
Pcmcia INF: PcicReadCardMemory: 00 01 03 61 08 FF 17 04-67 5A 08 FF 1C 04
01 64
Pcmcia SKT: skt 84561b08 release power
Pcmcia SKT: skt 84561b08 power worker - SPW_ReleasePower
Pcmcia SKT: skt 84561b08 decrementing power requests to 1
Pcmcia SKT: skt 84561b08 power worker - SPW_Exit
Pcmcia SKT: skt 84561b08 ReleaseSocketPower returning 00000000
Pcmcia PNP: pdo 84392df8 irp 8437a008 comp STATUS_SUCCESS 00000000

The bytes listed in the second PcicReadCardMemory line are the first 16
bytes of the CIS, and match the data actually read.

It seems like the lack of debug activity for GetBusData would indicate
something is going wrong. My question to you (anybody really) is have you
ever gotten GetBusData and SetBusData to work with reading from
and writing
to a register in a PCMCIA card’s attribute memory using the
BUS_INTERFACE_STANDARD? The interface is supposedly successfully acquired
by an IRP_MN_QUERY_INTERFACE, but, once again, only a single
debug line is
generated:

Pcmcia PNP: pdo 84392df8 irp 8437a008 –> IRP_MN_QUERY_INTERFACE

This gives no indication of processing the request, but one would assume
that it was processed since the IRP results in a successful status.

If anyone has gotten the BUS_INTERFACE_STANDARD to work with a
PCMCIA card,
could you indicate what tricks, if any, were necessary to
successfully read
and write to a register in the attribute memory?

Thank you,
Curtis Coleman


You are currently subscribed to ntdev as: xxxxx@driverdev.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Well, for anyone interested, I have overcome the problems that I was having
with GetBusData and reading from PCMCIA attribute memory in general. My
progress is thanks to Khalid Sabri over at Microsoft. He pointed out
several things that are not stated in the current DDK documentation.

First off, when writing to or reading from PCMCIA attribute memory, calls
to SetBusData and GetBusData should have PCCARD_ATTRIBUTE_MEMORY for the
DataType parameter. This is the same parameter that is used for the IRP
method (IRP_MN_WRITE_CONFIG and IRP_MN_READ_CONFIG) of accessing attribute
memory. From the DDK documentation, I did not think that the parameter
would be the same for GetBusData. For the IRP method, the parameter is
listed as WhichSpace, and the parameter shown for GetBusData is named
DataType (briefly described under the IRP_MN_QUERY_INTERFACE section),
seemingly implying a different variable type. I was originally using
PCMCIAConfiguration for the parameter for GetBusData, which I’d found under
BUS_DATA_TYPE while snooping through ntddk.h, and it seemed to make the
most sense. Regardless of what I’d originally used, the correct way to use
GetBusData and SetBusData for PCMCIA attribute memory is to provide
PCCARD_ATTRIBUTE_MEMORY as the DataType parameter. Similarly, you can use
PCCARD_COMMON_MEMORY for common memory, although I use mapped memory for
that. Both of these constants are defined in ntddpcm.h.

My second problem was that I was unable to access a register that was at a
known offset in attribute memory, even when using the IRP_MN_READ_CONFIG
method. The reason for this was that all offsets for accessing attribute
memory are in increments of 16 bits, rather than the standard 8 bits. So an
offset value of 20 is really referring to the spot 40 bytes into the memory
space. This was apparently done to prevent reads and writes to odd offsets.
This, too, is not clearly stated in the documentation. The solution is to
divide all of the offsets used for attribute memory by two, and the correct
region will be accessed.

Khalid said he would submit a bug report for the DDK documentation, so
hopefully these issues will be clarified in future versions of the DDK.

Thank you to everyone who helped me out,
Curtis

On 07/30/01, ““Timothy A. Johns” ” wrote:
> Curtis,
>
> One more thing you can try, especially now that you have the symbols loaded,
> etc. - try stepping into the call to GetBusData, to see what it actually
> does, and what functions it calls.
>
> -Tim
>
> Timothy A. Johns — xxxxx@driverdev.com
> Driver Development Corporation — 800.841.0092
> Bring Up Your Hardware — Fast. www.driverdev.com
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com]On Behalf Of
> > xxxxx@viasat.com
> > Sent: Monday, July 30, 2001 10:00 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: GetBusData returns 0 bytes read for PCMCIA
> > Attribute read
> >
> >
> > Thank you Tim and Bryan for your help. I was able to increase the debug
> > level of pcmcia.sys (setting pcmcia!PcmciaDebugMask to 0xFFFFFFFF) and
> > thereby gain some useful information.
> >
> > Turning on the debug info made me realize that IRP_MN_READ_CONFIG is
> > successfully reading from the configuration space (at least the CIS) but
> > just returns 0 bytes read in pIrp->IoStatus.Information. According to the
> > DDK, this should not be the case, but oh well. Calling GetBusData
> > does not
> > have the same behavior. I call RtlZeroMemory beforehand, and after
> > GetBusData returns 0 (the number of bytes read), the supplied buffer
> > remains all zeroes.
> >
> > There are two issues that I’m now faced with:
> > 1) While it is reassuring that I can read from the CIS (offset 0) using
> > IRP_MN_READ_CONFIG, when I read from a register at a known offset, the
> > value read is 0, when it should be non-zero. I also tried writing to the
> > offset, and then reading, but saw no change in the value. This offset has
> > been used in past drivers for the card, but for some reason does not seem
> > to be valid with the IRP_MN_XXXX_CONFIG method.
> >
> > 2) I need to be able to read and write to a pair of registers in
> > Attribute
> > memory at IRQL DISPATCH_LEVEL. For this reason, even if I manage to get
> > reads and writes with these registers working through IRP_MN_READ_CONFIG
> > and IRP_MN_WRITE_CONFIG, I still need to get GetBusData and SetBusData
> > working. The reason why I paid more attention to the IRP method
> > of reading
> > and writing is that much more debug information was printed out by
> > pcmcia.sys from those operations. It looked like it was actually doing
> > something, whereas the GetBusData calls only invoke a single line
> > of debug
> > information:
> >
> > Pcmcia IFC: pdo 84392df8 read card memory
> >
> > That’s it.
> > The calls to IRP_MN_READ_CONFIG yield debug info like this:
> >
> > Pcmcia PNP: pdo 84392df8 irp 8437a008 –> IRP_MN_READ_CONFIG
> > Pcmcia SKT: skt 84561b08 request power
> > Pcmcia SKT: skt 84561b08 power worker - SPW_RequestPower
> > Pcmcia SKT: skt 84561b08 power requests now 2, status 00000000
> > Pcmcia SKT: skt 84561b08 power worker - SPW_Exit
> > Pcmcia SKT: skt 84561b08 RequestSocketPower returning, status=00000000
> > Pcmcia INF: Stall! 3000 usec
> > Pcmcia INF: skt 84561b08 memory window 1 enabled df000
> > Pcmcia INF: skt 84561b08 memory window 1 disabled
> > Pcmcia INF: PcicReadCardMemory: 0xf75c9080 ==> 0xf7443b68
> > Pcmcia INF: PcicReadCardMemory: 00 01 03 61 08 FF 17 04-67 5A 08 FF 1C 04
> > 01 64
> > Pcmcia SKT: skt 84561b08 release power
> > Pcmcia SKT: skt 84561b08 power worker - SPW_ReleasePower
> > Pcmcia SKT: skt 84561b08 decrementing power requests to 1
> > Pcmcia SKT: skt 84561b08 power worker - SPW_Exit
> > Pcmcia SKT: skt 84561b08 ReleaseSocketPower returning 00000000
> > Pcmcia PNP: pdo 84392df8 irp 8437a008 comp STATUS_SUCCESS 00000000
> >
> > The bytes listed in the second PcicReadCardMemory line are the first 16
> > bytes of the CIS, and match the data actually read.
> >
> > It seems like the lack of debug activity for GetBusData would indicate
> > something is going wrong. My question to you (anybody really) is have you
> > ever gotten GetBusData and SetBusData to work with reading from
> > and writing
> > to a register in a PCMCIA card’s attribute memory using the
> > BUS_INTERFACE_STANDARD? The interface is supposedly successfully acquired
> > by an IRP_MN_QUERY_INTERFACE, but, once again, only a single
> > debug line is
> > generated:
> >
> > Pcmcia PNP: pdo 84392df8 irp 8437a008 –> IRP_MN_QUERY_INTERFACE
> >
> > This gives no indication of processing the request, but one would assume
> > that it was processed since the IRP results in a successful status.
> >
> > If anyone has gotten the BUS_INTERFACE_STANDARD to work with a
> > PCMCIA card,
> > could you indicate what tricks, if any, were necessary to
> > successfully read
> > and write to a register in the attribute memory?
> >
> > Thank you,
> > Curtis Coleman
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@driverdev.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com