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