--- /dev/null
+*** This file contains messages I've culled off the net as well
+as previous discussions all of which have useful info on fixes
+that need to be added to ReactOS. messages are between five
+dashes on a line by themselves. If you implement the fix
+reffered to in a message, feel free to delete it from the file.
+Rex ***
+-----
+Subject: [ros-kernel] Inside the Boot Process
+Date: Mon, 22 Mar 1999 22:05:47 +0100
+From: Emanuele Aliberti <ea@iol.it>
+
+For those working on the boot loader: in WinNt Magazine november 1998
+issue (http://www.winntmag.com/) there is a detailed description, by
+Mark Russinovich, of the rôle the MBR, NTLDR, boot.ini, ntdetect.com...
+play in the boot process ("Inside the Boot Process, Part 1").
+-----
+Yes with DPCs, KeDrainDpcQueue should go to HIGH_LEVEL because
+it needs to synchronize with KeInsertDpcQueue. Also the idle thread
+should run at DISPATCH_LEVEL and regularly drain the dpc queue, that
+way if an irq happens and the dpc can't be executed immediately it
+will be executed as soon as the processor is idle rather than
+waiting for the next timer tick
+-----
+About the console driver, I think it might be quite useful to have a simple
+way for apps to print to the screen for debugging. But when the kernel is more
+stable, console handling should be moved to user level because console printing
+needs to know about windows and so on which can only be done at user level.
+-----
+Subject: Re: IMSAMP-how to avoid rebooting?
+Date: 9 Nov 1998 00:40:32 -0000
+From: Charles Bryant <n51190709.ch@chch.demon.co.uk>
+Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
+References: 1, 2 , 3 , 4
+
+In article <un264wzle.fsf@xxx.yyy.zzz>, David C. <qqqq@xxx.yyy.zzz> wrote:
+>The reason it won't unload when something is bound to it is the same
+>reason you can't unload any other driver that has an open client. If
+>you install any driver, and have a user program (or another driver) open
+>a handle to it, and then give the "net stop" command to unload it,
+>you'll find that the unload will be delayed until the user program
+>closes its handle.
+
+When developing a driver I found this to be a considerable nuisance.
+Frequently a bug would leave an IRP stuck in the driver and I
+couldn't unload and reload a fixed version. While reading NTDDK.H I
+found a suspicious constant and discovered that the Flags field in
+the device (the one which you OR in DO_BUFFERED_IO or DO_DIRECT_IO)
+has a bit called DO_UNLOAD_PENDING. By experiment I confirmed that
+this bit is set when you do 'net stop', so a driver can check it
+periodically (e.g. from a timer DPC every ten seconds) and cancel all
+queued IRPs if it is found to be set.
+
+Since this is not documented anywhere that I can find, it might be
+unwise to rely on it for production code, but it is very useful for
+debugging. Maybe someone with internals knowledge can comment on the
+reliability of it.
+-----
+Subject: Re: Kernel bugs
+Date: Fri, 23 Oct 1998 12:08:36 -0700
+From: rex <rex@lvcablemodem.com>
+To: Jason Filby <jasonfilby@yahoo.com>
+References: 1
+
+Jason Filby wrote:
+
+> Hi,
+>
+> Ok -- here's most of what I get when I press a key:
+>
+> Page fault detected at address 1fd4 with eip c042f794
+> Recursive page fault detected
+> Exception 14(2)
+> CS:EIP 20:c042f794
+>
+> Rex -- do you know of anyway to find out which function in what file
+> is causing the exception? I know that for problems in the kernel, you
+> just look in the ntoskrnl\kernel.sym file and find the EIP value which
+> matches the one given in the exception debug text. But what about
+> modules? How can we track exceptions that occur in functions in modules?
+>
+
+I know this is a little belated, but I thought I'd take astab at answering
+this anyway. add an option to the
+makefile for the module to generate a listing file with
+symbol information. Then, on a boot test, note the
+address that the module is loaded at, and subtract
+this from the EIP value. add any offset used in the
+module link specification (I dont think there currently
+is one), and look for the last symbol with a lower
+address offset.
+
+Brian, I have an idea on how to make this exception
+dump information a little more useful. We should
+have the load information for the load modules
+in memory somewhere. Perhaps the exception
+dump could check offending addresses to see if
+they lie in the kernel or in a module, and if they
+lie in a module the proper offset could be subtracted
+and this number could be displayed seperately. If
+I get a chance today, I'll make this change and send
+it to ya.
+
+Rex.
+-----
+Subject: Re: Question on "Sending buffers on the stack to asynchronous DeviceIoControl with buffered I/O"
+Date: Mon, 16 Nov 1998 11:24:57 -0800
+From: "-Paul" <paulsan@microsoftSPAM.com>
+Organization: Microsoft Corp.
+Newsgroups: microsoft.public.win32.programmer.kernel, comp.os.ms-windows.programmer.nt.kernel-mode
+References: 1
+
+Radu, I post the following information occassionally for questions such as
+yours. I hope it helps.
+
+-Paul
+
+Here is an explanation of buffers and DeviceIoControl.
+
+First, here are the parameters,
+
+BOOL DeviceIoControl(
+ HANDLE hDevice, // handle to device of interest
+ DWORD dwIoControlCode, // control code of operation to perform
+ LPVOID lpInBuffer, // pointer to buffer to supply input data
+ DWORD nInBufferSize, // size of input buffer
+ LPVOID lpOutBuffer, // pointer to buffer to receive output data
+ DWORD nOutBufferSize, // size of output buffer
+ LPDWORD lpBytesReturned, // pointer to variable to receive output byte
+count
+ LPOVERLAPPED lpOverlapped // pointer to overlapped structure for
+asynchronous operation
+ );
+
+METHOD_BUFFERED
+
+user-mode perspective
+
+lpInBuffer - optional, contains data that is written to the driver
+lpOutBuffer - optional, contains data that is read from the driver after
+the call has completed
+
+lpInBuffer and lpOutBuffer can be two buffers or a single shared buffer.
+If a shared buffer, lpInBuffer is overwritten by lpOutBuffer.
+
+
+I/O Manager perspective
+
+examines nInBufferSize and nOutBufferSize. Allocates memory from non-paged
+pool and puts the address of this pool in Irp->AssociatedIrp.SystemBuffer.
+The size of this buffer is equal to the size of the larger of the two
+bufferes. This buffer is accessible at any IRQL.
+
+copies nInBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
+copies nOutBufferSize to
+irpSp->Parameters.DeviceIoControl.OutputBufferLength
+copies contents of lpInBuffer to SystemBuffer allocated above
+calls your driver
+
+
+
+Device Driver perspective
+
+you have one buffer, Irp->AssociatedIrp.SystemBuffer. You read input data
+from this buffer and you write output data to the same buffer, overwriting
+the input data.
+
+Before calling IoCompleteRequest, you must
+- set IoStatus.Status to an approriate NtStatus
+- if IoStatus.Status == STATUS_SUCCESS
+ set IoStatus.Information to the
+ number of bytes you want copied
+ from the SystemBuffer back into
+ lpOutBuffer.
+
+
+I/O Manager Completion Routine perspective
+
+looks at IoStatus block, if IoStatus.Status = STATUS_SUCCESS, copies the
+number of bytes specified by IoStatus.Information from
+Irp->AssociatedIrp.SystemBuffer into lpOutBuffer
+completes the request
+
+
+
+
+
+
+METHOD_IN_DIRECT
+
+user-mode perspective
+
+lpInBuffer - optional, contains data that is written to the driver. This
+buffer is used in the exact same fashion as METHOD_BUFFERED. To avoid
+confusion, mentally rename this buffer to lpControlBuffer. This is
+typically a small, optional buffer that might contain a control structure
+with useful information for the device driver. This buffer is smal and is
+double buffered.
+
+lpOutBuffer - NOT OPTIONAL, This LARGE buffer contains data that is read by
+the driver. To avoid confusion, mentally rename this buffer to
+lpDataTransferBuffer. This is physically the same buffer that the device
+driver will read from. There is no double buffering. Technically, this
+buffer is still optional, but since you are using this buffering method,
+what would be the point???
+
+I/O Manager perspective
+
+If lpInBuffer exists, allocates memory from non-paged pool and puts the
+address of this pool in Irp->AssociatedIrp.SystemBuffer. This buffer is
+accessible at any IRQL.
+
+copies nInBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
+copies nOutBufferSize to
+irpSp->Parameters.DeviceIoControl.OutputBufferLength
+copies contents of lpInBuffer to SystemBuffer allocated above
+So far this is completely identical to METHOD_BUFFERED. Most likely
+lpInBuffer (mentally renamed to lpControlBuffer) is very small in size.
+
+For lpOutBuffer (mentally renamed to lpDataTransferBuffer), an MDL is
+allocated. lpOutBuffer is probed and locked into memory. Then, the user
+buffer virtual addresses are checked to be sure they are readable in the
+caller's access mode.
+
+The MDL is address is stored in Irp->MdlAddress.
+Your driver is called.
+
+
+Device Driver perspective
+
+The device driver can read the copy of lpOutBuffer via
+Irp->AssociatedIrp.SystemBuffer. Anything written by the device driver to
+this buffer is lost. The I/O Manager does not copy any data back to the
+user-mode buffers as it did in the completion routine for METHOD_BUFFERED.
+Art Baker's book is wrong in this respect (page 168, "data going from the
+driver back to the caller is passed through an intermediate system-space
+buffer" and page 177, "When the IOCTL IRP is completed, the contents of the
+system buffer will be copied back into the callers original output buffer".
+
+The device driver accesses the Win32 buffer directly via Irp->MdlAddress.
+The driver uses whatever Mdl API's to read the buffer. Usually, this
+buffer is to be written to some mass storage media or some similar
+operation. Since this is a large data transfer, assume a completion
+routine is required.
+
+mark the Irp pending
+queue it
+return status pending
+
+
+
+
+Device Driver Completion Routine perspective
+
+standard completion routine operations
+set IoStatus.Status to an approriate NtStatus
+IoStatus.Information is not needed
+completete the request
+
+
+
+
+I/O Manager Completion Routine perspective
+
+standard I/O Manager completion routine operations
+unmap the pages
+deallocate the Mdl
+complete the request
+
+
+
+
+
+METHOD_OUT_DIRECT
+
+user-mode perspective
+
+lpInBuffer - optional, contains data that is written to the driver. This
+buffer is used in the exact same fashion as METHOD_BUFFERED. To avoid
+confusion, mentally rename this buffer to lpControlBuffer. This is
+typically a small, optional buffer that might contain a control structure
+with useful information for the device driver. This buffer is smal and is
+double buffered.
+
+lpOutBuffer - NOT OPTIONAL, This LARGE buffer contains data that is written
+by the driver and read by the wer-mode application when the request is
+completed. To avoid confusion, mentally rename this buffer to
+lpDataTransferBuffer. This is physically the same buffer that the device
+driver will write to. There is no double buffering. Technically, this
+buffer is still optional, but since you are using this buffering method,
+what would be the point???
+
+I/O Manager perspective
+
+If lpInBuffer exists, allocates memory from non-paged pool and puts the
+address of this pool in Irp->AssociatedIrp.SystemBuffer. This buffer is
+accessible at any IRQL.
+
+copies nInBufferSize to irpSp->Parameters.DeviceIoControl.InputBufferLength
+copies nOutBufferSize to
+irpSp->Parameters.DeviceIoControl.OutputBufferLength
+copies contents of lpInBuffer to SystemBuffer allocated above
+So far this is completely identical to METHOD_BUFFERED. Most likely
+lpInBuffer (mentally renamed to lpControlBuffer) is very small in size.
+
+For lpOutBuffer (mentally renamed to lpDataTransferBuffer), an MDL is
+allocated. lpOutBuffer is probed and locked into memory. Then the user
+buffer's addresses are checked to make sure the caller could write to them
+in the caller's access mode.
+
+The MDL is address is stored in Irp->MdlAddress.
+Your driver is called.
+
+
+Device Driver perspective
+
+The device driver can read the copy of lpOutBuffer via
+Irp->AssociatedIrp.SystemBuffer. Anything written by the device driver to
+this buffer is lost.
+
+The device driver accesses the Win32 buffer directly via Irp->MdlAddress.
+The driver uses whatever Mdl API's to write data to the buffer. Usually,
+this buffer is to be read from some mass storage media or some similar
+operation. Since this is a large data transfer, assume a completion
+routine is required.
+
+mark the Irp pending
+queue it
+return status pending
+
+
+
+
+Device Driver Completion Routine perspective
+
+standard completion routine operations
+set IoStatus.Status to an approriate NtStatus
+IoStatus.Information is not needed
+completete the request
+
+
+
+
+I/O Manager Completion Routine perspective
+
+standard I/O Manager completion routine operations
+unmap the pages
+deallocate the Mdl
+complete the request
+
+
+
+
+METHOD_NEITHER
+
+I/O Manager perspective
+
+Irp->UserBuffer = lpOutputBuffer;
+IrpSp->Parameters.DeviceIoControl.Type3InputBuffer = lpInputBuffer;
+
+No comments here. Don't use METHOD_DIRECT unless you know what you are
+doing. Simple rule.
+
+If your IOCtl involves no data transfer buffers, then METHOD_NEITHER is the
+fastest path through the I/O Manager that involves an Irp.
+
+
+
+
+Final Comment
+
+Don't touch Irp->UserBuffer. This is a bookmark for the I/O Manager. Two
+major problems can occur. 1 - page fault at high IRQL, or 2 - you write
+something to Irp->UserBuffer and the I/O Manager overwrites you in its
+completion routine. File systems access Irp->UserBuffer, but FSD writers
+know all of the above and know when it is safe to touch Irp->UserBuffer.
+
+
+
+Radu Woinaroski wrote in message <364F8F6E.2434B010@scitec.com.au>...
+>Hello,
+>
+>I have a kernel-mode device driver that accepts a number of IoControl
+>commands that use buffered data transfer (METHOD_BUFFERED).
+>
+>A user mode API provides a higher level access then the DeviceIoControl
+>function.
+>
+>The function is implemented like that
+>
+>BOOL
+Something(
+> HANDLE hDevice ,
+> int param1,
+> int param2,
+> DWORD * pReturn,
+> LPOVERLAPPED pOverlapped)
+>{
+> // here a data buffer on the stack sent to asynchronous DeviceIoControl
+>call
+> int aDataIn[2];
+> aDataIn[0] = param1;
+> aDataIn[1] = param2;
+>
+> return DeviceIoControl(
+> hDevice,
+> DO_SOMETHING_IO,
+> aDataIn,
+> sizeof(int)*2,
+> pReturn,
+> sizeof(DWORD),
+> pOverlapped);
+>}
+>
+>The aDataIn buffer will not exist after DeviceIoControl returns (and
+>when the I/O operation terminates). I know that for buffered IO the
+>input data buffer is copyed by de IOManager to a nonpaged-pool area
+>before passing the request to driver dispatch routine (DeviceControl).
+>At the point of calling the dispatch routine (DeviceControl) the driver
+>runs in the context of the calling thread so DeviceIoControl hasn't
+>returned yet (?? or so I think) so aDataI
+n will still be valid at the
+>time IOManager copyes it to its buffer. So, this apears to work ok (at
+>least in my opinion).
+>
+>Does I/O Manager use the Input buffer from the call to the Win32
+>DeviceIoControl any where else after the first copy ?
+>
+>Is there any reason why this approach (passing a buffer on the stack to
+>a asynchronous DeviceIoControl that uses buffered I/O) wouldn't work ?
+>
+>Allocating buffers from heap and deleting them on IO completion while
+>managing asynchronous IO seems too much work ;-) .
+>
+>Thanks in advance for your opinions
+>Radu W.
+>
+>--
+>Radu Woinaroski
+>Scitec
+>Sydney, Australia
+>Radu.Woinaroski@scitec.com.au
+-----
+Subject: Re: PCI ISR problem
+Date: Fri, 20 Nov 1998 18:04:48 GMT
+From: jeh@cmkrnl.com (Jamie Hanrahan)
+Organization: Kernel Mode Systems, San Diego, CA
+Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
+References: 1
+
+On Thu, 19 Nov 1998 15:46:13 -0600, Eric Gardiner
+<eric.gardiner@natinst.com> wrote:
+
+>I'm having problems with NT4 not hooking the interrupt line indicated by
+>a PCI device. Here's what I'm doing:
+>
+>1) Enumerating the PCI buses on the system (using HalGetBusData) until
+>I find my device.
+>2) Once my device is found, I read the "Interrupt Line Register" in the
+>device's PCI config space to determine what interrupt level to pass to
+>HalGetInterruptVector.
+
+Whups! No. Call HalAssignSlotResources and look at the returned
+CM_RESOURCE_LIST to find the vector, level, port addresses, etc., for
+your device. (Then pass the returned CM_RESOURCE_LIST to ExFreePool.)
+
+
+See Knowledge Base article Q152044.
+
+ --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA (jeh@cmkrnl.com)
+Drivers, internals, networks, applications, and training for VMS and Windows NT
+NT kernel driver FAQ, links, and other information: http://www.cmkrnl.com/
+
+Please post replies, followups, questions, etc., in news, not via e-mail.
+-----
+Subject: Re: IRP canceling
+Date: Mon, 23 Nov 1998 09:05:47 -0500
+From: Walter Oney <waltoney@oneysoft.com>
+Organization: Walter Oney Software
+Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
+References: 1
+
+Seol,Keun Seok wrote:
+> But, if the IRP was the CurrentIrp of the Device Object,
+> the Driver's Start I/O routine will try to process the IRP.
+> In the DDK help, the Start I/O routine MUST check the current IRP's
+> Cancel bit.
+> If set, Start I/O routine must just return.
+>
+> But I think that the IRP already completed should not be accessed.
+
+You're absolutely right. I recommend the following code in a standard
+StartIo routine to avoid the problem you point out:
+
+VOID StartIo(PDEVICE_OBJECT DeviceObject, PIRP Irp)
+ {
+ KIRQL oldirql;
+ IoAcquireCancelSpinLock(&oldirql);
+ if (Irp != DeviceObject->CurrentIrp || Irp->Cancel)
+ {
+ IoReleaseCancelSpinLock(oldirql);
+ return;
+ }
+ else
+ {
+ IoSetCancelRoutine(Irp, NULL);
+ IoReleaseCancelSpinLock(oldirql);
+ }
+ . . .
+ }
+
+This dovetails with a standard cancel routine:
+
+VOID CancelRoutine(PDEVICE_OBJECT DeviceObject, PIRP Irp)
+ {
+ if (DeviceObject->CurrentIrp == Irp)
+ {
+ IoReleaseCancelSpinLock(Irp->CancelIrql);
+ IoStartNextPacket(DeviceObject, TRUE);
+ }
+ else
+ {
+ KeRemoveEntryDeviceQueue(&DeviceObject->DeviceQueue,
+ &Irp->Tail.Overlay.DeviceQueueEntry);
+ IoReleaseCancelSpinLock(Irp->CancelIrql);
+ }
+ Irp->IoStatus.Status = STATUS_CANCELLED;
+ Irp->IoStatus.Information = 0;
+ IoCompleteRequest(Irp, IO_NO_INCREMENT);
+ }
+
+You need to remember that the C language specification requires that
+evaluation of boolean operators short circuit when the result is known.
+So, if StartIo discovers that the Irp it got as an argument is not the
+same as CurrentIrp, it will not attempt to evaulate Irp->Cancel.
+
+Now, as to why this works: StartIo gets called either by IoStartPacket
+or IoStartNextPacket. Each of them will grab the cancel spin lock and
+set CurrentIrp, then release the spin lock and call StartIo. If someone
+should sneak in on another CPU and cancel this very same IRP, your
+cancel routine will immediately release the spin lock and call
+IoStartNextPacket. One of two things will then happen. IoStartNextPacket
+may succeed in getting the cancel spin lock, whereupon it will nullify
+the CurrentIrp pointer. If another IRP is on the queue, it will remove
+it from the queue, set CurrentIrp to point to this *new* IRP, release
+the spin lock, and call StartIo. [You now have two instances of StartIo
+running on two different CPUs for two different IRPs, but it's not a
+problem because they won't be able to interfere with each other.]
+Meanwhile, your original instance of StartIo gets the cancel spin lock
+and sees that CurrentIrp is not equal to the IRP pointer it got as an
+argument, so it gives up.
+
+The second way this could play out is that StartIo gets the cancel lock
+before IoStartNextPacket does. In this case, CurrentIrp is still
+pointing to the IRP that's in the process of being cancelled and that
+StartIo got as an argument. But this IRP hasn't been completed yet (the
+CPU that's running your cancel routine is spinning inside
+IoStartNextPacket and therefore hasn't gotten to calling
+IoCompleteRequest yet), so no-one will have been able to call IoFreeIrp
+to make your pointer invalid.
+
+People may tell you that you should be using your own queues for IRPs so
+you can avoid bottlenecking the system on the global cancel spin lock.
+That's true enough, but doing it correctly with Plug and Play and Power
+management things in the way is gigantically complicated. There's a
+sample in the NT 5 beta-2 DDK called CANCEL that shows how to manage
+your own queue if you don't worry about PNP and POWER. I hear tell of an
+upcoming MSJ article by a Microsoft developer that may solve the
+complete problem.
+-----
+The END.
projects / reactos.git / blobdiff