summaryrefslogtreecommitdiffstats
path: root/sys/compat/ndis
Commit message (Collapse)AuthorAgeFilesLines
* Use implicit type cast for ->k_lock to fix compilation of ndisrik2005-07-081-3/+3
| | | | | | | | | | | as a part of the GENERIC kernel with INVARIANT* and WITNESS* turned off. (For non GENERIC kernel KTR and MUTEX_PROFILING should be also off). Submitted by: Eygene A. Ryabinkin <rea at rea dot mbslab dot kiae dot ru> Approved by: re (scottl) PR: 81767
* Stop embedding struct ifnet at the top of driver softcs. Instead thebrooks2005-06-102-6/+6
| | | | | | | | | | | | | | | | | | | | struct ifnet or the layer 2 common structure it was embedded in have been replaced with a struct ifnet pointer to be filled by a call to the new function, if_alloc(). The layer 2 common structure is also allocated via if_alloc() based on the interface type. It is hung off the new struct ifnet member, if_l2com. This change removes the size of these structures from the kernel ABI and will allow us to better manage them as interfaces come and go. Other changes of note: - Struct arpcom is no longer referenced in normal interface code. Instead the Ethernet address is accessed via the IFP2ENADDR() macro. To enforce this ac_enaddr has been renamed to _ac_enaddr. - The second argument to ether_ifattach is now always the mac address from driver private storage rather than sometimes being ac_enaddr. Reviewed by: sobomax, sam
* Remove bus_{mem,p}io.h and related code for a micro-optimization on i386nyan2005-05-293-6/+0
| | | | | | and amd64. The optimization is a trivial on recent machines. Reviewed by: -arch (imp, marcel, dfr)
* Missed kern_windrv.c in the last checkin.wpaul2005-05-201-0/+14
|
* Deal with a few bootstrap issues:wpaul2005-05-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can't call KeFlushQueuedDpcs() during bootstrap (cold == 1), since the flush operation sleeps to wait for completion, and we can't sleep here (clowns will eat us). On an i386 SMP system, if we're loaded/probed/attached during bootstrap, smp_rendezvous() won't run us anywhere except CPU 0 (since the other CPUs aren't launched until later), which means we won't be able to set up the GDTs anywhere except CPU 0. To deal with this case, ctxsw_utow() now checks to see if the TID for the current processor has been properly initialized and sets up the GTD for the current CPU if not. Lastly, in if_ndis.c:ndis_shutdown(), do an ndis_stop() to insure we really halt the NIC and stop interrupts from happening. Note that loading a driver during bootstrap is, unfortunately, kind of a hit or miss sort of proposition. In Windows, the expectation is that by the time a given driver's MiniportInitialize() method is called, the system is already in 'multiuser' state, i.e. it's up and running enough to support all the stuff specified in the NDIS API, which includes the underlying OS-supplied facilities it implicitly depends on, such as having all CPUs running, having the DPC queues initialized, WorkItem threads running, etc. But in UNIX, a lot of that stuff won't work during bootstrap. This causes a problem since we need to call MiniportInitialize() at least once during ndis_attach() in order to find out what kind of NIC we have and learn its station address. What this means is that some cards just plain won't work right if you try to pre-load the driver along with the kernel: they'll only be probed/attach correctly if the driver is kldloaded _after_ the system has reached multiuser. I can't really think of a way around this that would still preserve the ability to use an NDIS device for diskless booting.
* In ndis_halt_nic(), invalidate the miniportadapterctx early to try andwpaul2005-05-201-4/+1
| | | | | | | | | prevent anything from making calls to the NIC while it's being shut down. This is yet another attempt to stop things like mdnsd from trying to poke at the card while it's not properly initialized and panicking the system. Also, remove unneeded debug message from if_ndis.c.
* Fix some of the things I broke so that the SMC2602W (AMD Am1772) driverwpaul2005-05-193-32/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | works again. This driver uses NdisScheduleWorkItem(), and we have to take special steps to insure that its workitems don't collide with any of the other workitems used by the NDISulator. In particular, if one of the driver's work jobs blocks, it can prevent NdisMAllocateSharedMemoryAsync() from completing when expected. The original hack to fix this was to have NdisMAllocateSharedMemoryAsync() defer its work to the DPC queue instead of the general task queue. To fix it now, I decided to add some additional workitem threads. (There's supposed to be a pool of worker threads in Windows anyway.) Currently, there are 4. There should be at least 2. One is reserved for the legacy ExQueueWorkItem() API, while the others are used in round-robin by the IoQueueWorkItem() API. NdisMAllocateSharedMemoryAsync() uses the latter API while NdisScheduleWorkItem() uses the former, so the deadlock is avoided. Fixed NdisMRegisterDevice()/NdisMDeregisterDevice() to work a little more sensibly with the new driver_object/device_object framework. It doesn't really register a working user-mode interface, but the existing code was completely wrong for the new framework. Fixed a couple of bugs dealing with the cancellation of events and DPCs. When cancelling an event that's still on the timer queue (i.e. hasn't expired yet), reset dh_inserted in its dispatch header to FALSE. Previously, it was left set to TRUE, which would make a cancelled timer appear to have not been cancelled. Also, when removing a DPC from a queue, reset its list pointers, otherwise a cancelled DPC might mistakenly be treated as still pending. Lastly, fix the behavior of ntoskrnl_wakeup() when dealing with objects that have nobody waiting on them: sync event objects get their signalled state reset to FALSE, but notification objects should still be set to TRUE.
* Remove harmless bit of leftover debug code.wpaul2005-05-161-2/+0
|
* Correct some problems with workitem usage. NdisScheduleWorkItem() doeswpaul2005-05-162-4/+35
| | | | | not use exactly the same workitem sturcture as ExQueueWorkItem() like I originally thought it did.
* Add support for NdisMEthIndicateReceive() and MiniportTransferData().wpaul2005-05-152-10/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Ralink RT2500 driver uses this API instead of NdisMIndicateReceivePacket(). Drivers use NdisMEthIndicateReceive() when they know they support 802.3 media and expect to hand their packets only protocols that want to deal with that particular media type. With this API, the driver does not manage its own NDIS_PACKET/NDIS_BUFFER structures. Instead, it lets bound protocols have a peek at the data, and then they supply an NDIS_PACKET/NDIS_BUFFER combo to the miniport driver, into which it copies the packet data. Drivers use NdisMIndicateReceivePacket() to allow their packets to be read by any protocol, not just those bound to 802.3 media devices. To make this work, we need an internal pool of NDIS_PACKETS for receives. Currently, we check to see if the driver exports a MiniportTransferData() method in its characteristics structure, and only allocate the pool for drivers that have this method. This should allow the RT2500 driver to work correctly, though I still have to fix ndiscvt(8) to parse its .inf file properly. Also, change kern_ndis.c:ndis_halt_nic() to reap timers before acquiring NDIS_LOCK(), since the reaping process might entail sleeping briefly (and we can't sleep with a lock held).
* More fixes for multibus drivers. When calling out to the matchwpaul2005-05-082-2/+2
| | | | | function in if_ndis_pci.c and if_ndis_pccard.c, provide the bustype too so the stubs can ignore devlists that don't concern them.
* Fix support for Windows drivers that support both PCI and PCMCIA devices atwpaul2005-05-082-3/+14
| | | | | | | | | | | | | the same time. Fix if_ndis_pccard.c so that it sets sc->ndis_dobj and sc->ndis_regvals. Correct IMPORT_SFUNC() macros for the READ_PORT_BUFFER_xxx() routines, which take 3 arguments, not 2. This fixes it so that the Windows driver for my Cisco Aironet 340 PCMCIA card works again. (Yes, I know the an(4) driver supports this card natively, but it's the only PCMCIA device I have with a Windows XP driver.)
* Correct the patch table entries for the 64-bit intrinsic mathwpaul2005-05-081-6/+6
| | | | | | | | | | | | | | | routines (_alldiv(), _allmul(), _alludiv(), _aullmul(), etc...) that use the _stdcall calling convention. These routines all take two arguments, but the arguments are 64 bits wide. On the i386 this means they each consume two 32-bit slots on the stack. Consequently, when we specify the argument count in the IMPORT_SFUNC() macro, we have to lie and claim there are 4 arguments instead of two. This will cause the resulting i386 assembly wrapper to push the right number of longwords onto the stack. This fixes a crash I discovered with the RealTek 8180 driver, which uses these routines a lot during initialization.
* Cast 64 bit quantity to uintmax_t to print it with %jx. This iswpaul2005-05-051-1/+1
| | | | | | technically a no-op since uintmax_t is uint64_t on all currently supported architectures, but we should use an explicit cast instead of depending on this obscure coincidence.
* Use %jx instead of %qx to silence compiler warning on amd64.wpaul2005-05-051-1/+1
|
* Avoid sleeping with mutex held in kern_ndis.c.wpaul2005-05-053-35/+32
| | | | | | | | | | | | | | | Remove unused fields from ndis_miniport_block. Fix a bug in KeFlushQueuedDpcs() (we weren't calculating the kq pointer correctly). In if_ndis.c, clear the IFF_RUNNING flag before calling ndis_halt_nic(). Add some guards in kern_ndis.c to avoid letting anyone invoke ndis_get_info() or ndis_set_info() if the NIC isn't fully initialized. Apparently, mdnsd will sometimes try to invoke the ndis_ioctl() routine at exactly the wrong moment (to futz with its multicast filters) when the interface comes up, and can trigger a crash unless we guard against it.
* Remove extranaous free() of ASCII filename from NdisOpenFile().wpaul2005-05-051-1/+0
| | | | | | | | | | | | | | Oh, one additional change I forgot to mention in the last commit: NdisOpenFile() was broken in the case for firmware files that were pre-loaded as modules. When searching for the module in NdisOpenFile(), we would match against a symbol name, which would contain the string we were looking for, then save a pointer to the linker file handle. Later, in NdisMapFile(), we would refer to the filename hung off this handle when trying to find the starting address symbol. Only problem is, this filename is different from the embedded symbol name we're searching for, so the mapping would fail. I found this problem while testing the AirGo driver, which requires a small firmware file.
* This commit makes a bunch of changes, some big, some not so big.wpaul2005-05-057-447/+896
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove the old task threads from kern_ndis.c and reimplement them in subr_ntoskrnl.c, in order to more properly emulate the Windows DPC API. Each CPU gets its own DPC queue/thread, and each queue can have low, medium and high importance DPCs. New APIs implemented: KeSetTargetProcessorDpc(), KeSetImportanceDpc() and KeFlushQueuedDpcs(). (This is the biggest change.) - Fix a bug in NdisMInitializeTimer(): the k_dpc pointer in the nmt_timer embedded in the ndis_miniport_timer struct must be set to point to the DPC, also embedded in the struct. Failing to do this breaks dequeueing of DPCs submitted via timers, and in turn breaks cancelling timers. - Fix a bug in KeCancelTimer(): if the timer is interted in the timer queue (i.e. the timeout callback is still pending), we have to both untimeout() the timer _and_ call KeRemoveQueueDpc() to nuke the DPC that might be pending. Failing to do this breaks cancellation of periodic timers, which always appear to be inserted in the timer queue. - Make use of the nmt_nexttimer field in ndis_miniport_timer: keep a queue of pending timers and cancel them all in ndis_halt_nic(), prior to calling MiniportHalt(). Also call KeFlushQueuedDpcs() to make sure any DPCs queued by the timers have expired. - Modify NdisMAllocateSharedMemory() and NdisMFreeSharedMemory() to keep track of both the virtual and physical addresses of the shared memory buffers that get handed out. The AirGo MIMO driver appears to have a bug in it: for one of the segments is allocates, it returns the wrong virtual address. This would confuse NdisMFreeSharedMemory() and cause a crash. Why it doesn't crash Windows too I have no idea (from reading the documentation for NdisMFreeSharedMemory(), it appears to be a violation of the API). - Implement strstr(), strchr() and MmIsAddressValid(). - Implement IoAllocateWorkItem(), IoFreeWorkItem(), IoQueueWorkItem() and ExQueueWorkItem(). (This is the second biggest change.) - Make NdisScheduleWorkItem() call ExQueueWorkItem(). (Note that the ExQueueWorkItem() API is deprecated by Microsoft, but NDIS still uses it, since NdisScheduleWorkItem() is incompatible with the IoXXXWorkItem() API.) - Change if_ndis.c to use the NdisScheduleWorkItem() interface for scheduling tasks. With all these changes and fixes, the AirGo MIMO driver for the Belkin F5D8010 Pre-N card now works. Special thanks to Paul Robinson (paul dawt robinson at pwermedia dawt net) for the loan of a card for testing.
* Throw the switch on the new driver generation/loading mechanism. Fromwpaul2005-04-246-39/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | here on in, if_ndis.ko will be pre-built as a module, and can be built into a static kernel (though it's not part of GENERIC). Drivers are created using the new ndisgen(8) script, which uses ndiscvt(8) under the covers, along with a few other tools. The result is a driver module that can be kldloaded into the kernel. A driver with foo.inf and foo.sys files will be converted into foo_sys.ko (and foo_sys.o, for those who want/need to make static kernels). This module contains all of the necessary info from the .INF file and the driver binary image, converted into an ELF module. You can kldload this module (or add it to /boot/loader.conf) to have it loaded automatically. Any required firmware files can be bundled into the module as well (or converted/loaded separately). Also, add a workaround for a problem in NdisMSleep(). During system bootstrap (cold == 1), msleep() always returns 0 without actually sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for the NIC's firmware to come to life, and fails to load if NdisMSleep() doesn't actually delay. As a workaround, if msleep() (and hence ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead). This is not really the right thing to do, but we can't really do much else. At the very least, this makes the Intel driver happy. There are probably other drivers that fail in this way during bootstrap. Unfortunately, the only workaround for those is to avoid pre-loading them and kldload them once the system is running instead.
* Now that the GDT has been reorganized and GNDIS_SEL has been reservedwpaul2005-04-171-1/+17
| | | | | for us, use it if it's available, otherwise default to using slot 7 as before.
* When setting up the new stack for a function in x86_64_wrap(), makewpaul2005-04-161-5/+7
| | | | | | | sure to make it 16-byte aligned, in keeping with amd64 calling convention requirements. Submitted by: Mikore Li at sun dot com
* In winx32_wrap.S, preserve return values in the fastcall and regparmwpaul2005-04-111-10/+12
| | | | | wrappers by pushing them onto the stack rather than keeping them in %esi and %edi.
* Create new i386 windows/bsd thunking layer, similar to the amd64 thunkingwpaul2005-04-1111-948/+1697
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | layer, but with a twist. The twist has to do with the fact that Microsoft supports structured exception handling in kernel mode. On the i386 arch, exception handling is implemented by hanging an exception registration list off the Thread Environment Block (TEB), and the TEB is accessed via the %fs register. The problem is, we use %fs as a pointer to the pcpu stucture, which means any driver that tries to write through %fs:0 will overwrite the curthread pointer and make a serious mess of things. To get around this, Project Evil now creates a special entry in the GDT on each processor. When we call into Windows code, a context switch routine will fix up %fs so it points to our new descriptor, which in turn points to a fake TEB. When the Windows code returns, or calls out to an external routine, we swap %fs back again. Currently, Project Evil makes use of GDT slot 7, which is all 0s by default. I fully expect someone to jump up and say I can't do that, but I couldn't find any code that makes use of this entry anywhere. Sadly, this was the only method I could come up with that worked on both UP and SMP. (Modifying the LDT works on UP, but becomes incredibly complicated on SMP.) If necessary, the context switching stuff can be yanked out while preserving the convention calling wrappers. (Fortunately, it looks like Microsoft uses some special epilog/prolog code on amd64 to implement exception handling, so the same nastiness won't be necessary on that arch.) The advantages are: - Any driver that uses %fs as though it were a TEB pointer won't clobber pcpu. - All the __stdcall/__fastcall/__regparm stuff that's specific to gcc goes away. Also, while I'm here, switch NdisGetSystemUpTime() back to using nanouptime() again. It turns out nanouptime() is way more accurate than just using ticks(). On slower machines, the Atheros drivers I tested seem to take a long time to associate due to the loss in accuracy.
* Fix another KeInitializeDpc()/amd64 calling convention issue:wpaul2005-04-011-1/+2
| | | | ndis_intrhand() has to be wrapped for the same reason as ndis_timercall().
* Apparently I'm cursed. ndis_findwrap() should be searching ndis_functbl,wpaul2005-03-311-1/+1
| | | | not ntoskrnl_functbl.
* Fix an amd64 issue I overlooked. When setting up a callout towpaul2005-03-311-3/+26
| | | | | | | | | | | | | | | ndis_timercall() in NdisMInitializeTimer(), we can't use the raw function pointer. This is because ntoskrnl_run_dpc() expects to invoke a function with Microsoft calling conventions. On i386, this works because ndis_timercall() is declared with the __stdcall attribute, but this is a no-op on amd64. To do it correctly, we have to generate a wrapper for ndis_timercall() and us the wrapper instead of of the raw function pointer. Fix this by adding ndis_timercall() to the funcptr table in subr_ndis.c, and create ndis_findwrap() to extract the wrapped function from the table in NdisMInitializeTimer() instead of just passing ndis_timercall() to KeInitializeDpc() directly.
* Fix a possible mutex leak in KeSetTimerEx(): if timer is NULL, wewpaul2005-03-301-2/+2
| | | | | bail out without releasing the dispatcher lock. Move the lock acquisition after the pointer test to avoid this.
* Remove a couple of #ifdef 0'ed code blocks left over from Atheros debugging.wpaul2005-03-301-8/+2
| | | | | | Remember to reset ndis_pendingreq to NULL when bailing out of ndis_set_info() or ndis_get_info() due to miniportadapterctx not being set.
* The filehandle allocated in NdisOpenFile() is allocated usingwpaul2005-03-281-2/+2
| | | | | | ExAllocatePoolWithTag(), not malloc(), so it should be released with ExFreePool(), not free(). Fix a couple if instances of free(fh, ...) that got overlooked.
* Another Coverity fix from Sam: add NULL pointer test inwpaul2005-03-281-0/+5
| | | | NdisMFreeSharedMemory() (if the list is already empty, just bail).
* More additions for amd64:wpaul2005-03-281-0/+20
| | | | | | | | | - On amd64, InterlockedPushEntrySList() and InterlockedPopEntrySList() are mapped to ExpInterlockedPushEntrySList and ExpInterlockedPopEntrySList() via macros (which do the same thing). Add IMPORT_FUNC_MAP()s for these. - Implement ExQueryDepthSList().
* Fix resource leak found by Coverity (via Sam Leffler).wpaul2005-03-281-0/+1
|
* Fix for amd64.wpaul2005-03-282-5/+5
|
* Fix another amd64 issue with lookaside lists: we initialize thewpaul2005-03-281-6/+40
| | | | | | | | alloc and free routine pointers in the lookaside list with pointers to ExAllocatePoolWithTag() and ExFreePool() (in the case where the driver does not provide its own alloc and free routines). For amd64, this is wrong: we have to use pointers to the wrapped versions of these functions, not the originals.
* Tweak to hopefully make lookaside lists work on amd64: in Windows, thewpaul2005-03-282-1/+7
| | | | | | | | | nll_obsoletelock field in the lookaside list structure is only defined for the i386 arch. For amd64, the field is gone, and different list update routines are used which do their locking internally. Apparently the Inprocomm amd64 driver uses lookaside lists. I'm not positive this will make it work yet since I don't have an Inprocomm NIC to test, but this needs to be fixed anyway.
* Spell '0' as 'FALSE' when initializing npp_validcounts. (Doesn't changewpaul2005-03-281-1/+1
| | | | the code, but emphasises that this field is used as a boolean.)
* Unbreak the build: correct the resource list traversal code forwpaul2005-03-281-4/+2
| | | | __FreeBSD_version >= 600022.
* Argh. PCI resource list became an STAILQ instead of an SLIST. Try towpaul2005-03-271-1/+14
| | | | | deal with this while maintaining backards source compatibility with stable.
* Check in ntoskrnl_var.h, which should have been included in thewpaul2005-03-271-2/+18
| | | | previous commit.
* Finally bring an end to the great "make the Atheros NDIS driverwpaul2005-03-274-116/+306
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
* s/SLIST/STAILQ/phk2005-03-181-7/+7
| | | | | | /imp/a\ pointy hat .
* When you call MiniportInitialize() for an 802.11 driver, it willwpaul2005-03-072-51/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | at some point result in a status event being triggered (it should be a link down event: the Microsoft driver design guide says you should generate one when the NIC is initialized). Some drivers generate the event during MiniportInitialize(), such that by the time MiniportInitialize() completes, the NIC is ready to go. But some drivers, in particular the ones for Atheros wireless NICs, don't generate the event until after a device interrupt occurs at some point after MiniportInitialize() has completed. The gotcha is that you have to wait until the link status event occurs one way or the other before you try to fiddle with any settings (ssid, channel, etc...). For the drivers that set the event sycnhronously this isn't a problem, but for the others we have to pause after calling ndis_init_nic() and wait for the event to arrive before continuing. Failing to wait can cause big trouble: on my SMP system, calling ndis_setstate_80211() after ndis_init_nic() completes, but _before_ the link event arrives, will lock up or reset the system. What we do now is check to see if a link event arrived while ndis_init_nic() was running, and if it didn't we msleep() until it does. Along the way, I discovered a few other problems: - Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL. ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation wrong.) - Similarly, the NDIS interrupt handler, which is essentially a DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask() has been fixed accordingly. - MiniportQueryInformation() and MiniportSetInformation() run at DISPATCH_LEVEL, and each request must complete before another can be submitted. ndis_get_info() and ndis_set_info() have been fixed accordingly. - Turned the sleep lock that guards the NDIS thread job list into a spin lock. We never do anything with this lock held except manage the job list (no other locks are held), so it's safe to do this, and it's possible that ndis_sched() and ndis_unsched() can be called from DISPATCH_LEVEL, so using a sleep lock here is semantically incorrect. Also updated subr_witness.c to add the lock to the order list.
* MAXPATHLEN is 1024, which means NdisOpenFile() and ndis_find_sym() werewpaul2005-03-032-17/+60
| | | | | | | | | | | both consuming 1K of stack space. This is unfriendly. Allocate the buffers off the heap instead. It's a little slower, but these aren't performance critical routines. Also, add a spinlock to NdisAllocatePacketPool(), NdisAllocatePacket(), NdisFreePacketPool() and NdisFreePacket(). The pool is maintained as a linked list. I don't know for a fact that it can be corrupted, but why take chances.
* In windrv_load(), I was allocating the driver object usingwpaul2005-03-011-17/+17
| | | | | | | | malloc(sizeof(device_object), ...) by mistake. Correct this, and rename "dobj" to "drv" to make it a bit clearer what this variable is supposed to be. Spotted by: Mikore Li at Sun dot comnospamplzkthx
* Don't need to do MmInitializeMdl() in ndis_mtop() anymore:wpaul2005-02-261-1/+0
| | | | | IoInitializeMdl() does it internally (and doing it again here messes things up).
* MDLs are supposed to be variable size (they include an array of pageswpaul2005-02-263-18/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | that describe a buffer of variable size). The problem is, allocating MDLs off the heap is slow, and it can happen that drivers will allocate lots and lots of lots of MDLs as they run. As a compromise, we now do the following: we pre-allocate a zone for MDLs big enough to describe any buffer with 16 or less pages. If IoAllocateMdl() needs a MDL for a buffer with 16 or less pages, we'll allocate it from the zone. Otherwise, we allocate it from the heap. MDLs allocate from the zone have a flag set in their mdl_flags field. When the MDL is released, IoMdlFree() will uma_zfree() the MDL if it has the MDL_ZONE_ALLOCED flag set, otherwise it will release it to the heap. The assumption is that 16 pages is a "big number" and we will rarely need MDLs larger than that. - Moved the ndis_buffer zone to subr_ntoskrnl.c from kern_ndis.c and named it mdl_zone. - Modified IoAllocateMdl() and IoFreeMdl() to use uma_zalloc() and uma_zfree() if necessary. - Made ndis_mtop() use IoAllocateMdl() instead of calling uma_zalloc() directly. Inspired by: discussion with Giridhar Pemmasani
* Add macros to construct Windows IOCTL codes, and to extract functionwpaul2005-02-251-0/+19
| | | | codes from an IOCTL. (The USB module will need them later.)
* Fix a couple of callback instances that should have been wrapped withwpaul2005-02-252-2/+3
| | | | | | MSCALLx(). Add definition for STATUS_PENDING error code.
* Compute the right length to use with bzero() when initializing an IRPwpaul2005-02-251-1/+1
| | | | | in IoInitializeIrp() (must use IoSizeOfIrp() to account for the stack locations).
* - Correct one aspect of the driver_object/device_object/IRP framework:wpaul2005-02-245-6/+237
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
OpenPOWER on IntegriCloud