summaryrefslogtreecommitdiffstats
path: root/sys/compat/ndis/kern_ndis.c
Commit message (Collapse)AuthorAgeFilesLines
* Stop embedding struct ifnet at the top of driver softcs. Instead thebrooks2005-06-101-3/+3
| | | | | | | | | | | | | | | | | | | | 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
* 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.
* Add support for NdisMEthIndicateReceive() and MiniportTransferData().wpaul2005-05-151-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Avoid sleeping with mutex held in kern_ndis.c.wpaul2005-05-051-26/+31
| | | | | | | | | | | | | | | 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.
* This commit makes a bunch of changes, some big, some not so big.wpaul2005-05-051-369/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Create new i386 windows/bsd thunking layer, similar to the amd64 thunkingwpaul2005-04-111-39/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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().
* 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.
* 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.
* Finally bring an end to the great "make the Atheros NDIS driverwpaul2005-03-271-60/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-071-48/+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.
* 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-261-15/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* - Correct one aspect of the driver_object/device_object/IRP framework:wpaul2005-02-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Couple of lessons learned during USB driver testing:wpaul2005-02-241-1/+2
| | | | | | | | | | | | | | | | - In kern_ndis.c:ndis_unload_driver(), test that ndis_block->nmb_rlist is not NULL before trying to free() it. - In subr_pe.c:pe_get_import_descriptor(), do a case-insensitive match on the import module name. Most drivers I have encountered link against "ntoskrnl.exe" but the ASIX USB ethernet driver I'm testing with wants "NTOSKRNL.EXE." - In subr_ntoskrnl.c:IoAllocateIrp(), return a pointer to the IRP instead of NULL. (Stub code leftover.) - Also in subr_ntoskrnl.c, add ExAllocatePoolWithTag() and ExFreePool() to the function table list so they'll get exported to drivers properly.
* Add support for Windows/x86-64 binaries to Project Evil.wpaul2005-02-161-48/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
* Next step on the road to IRPs: create and use an imitation of thewpaul2005-02-081-153/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
* Begin the first phase of trying to add IRP support (and ultimatelywpaul2005-01-241-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB device support): - Convert all of my locally chosen function names to their actual Windows equivalents, where applicable. This is a big no-op change since it doesn't affect functionality, but it helps avoid a bit of confusion (it's now a lot easier to see which functions are emulated Windows API routines and which are just locally defined). - Turn ndis_buffer into an mdl, like it should have been. The structure is the same, but now it belongs to the subr_ntoskrnl module. - Implement a bunch of MDL handling macros from Windows and use them where applicable. - Correct the implementation of IoFreeMdl(). - Properly implement IoAllocateMdl() and MmBuildMdlForNonPagedPool(). - Add the definitions for struct irp and struct driver_object. - Add IMPORT_FUNC() and IMPORT_FUNC_MAP() macros to make formatting the module function tables a little cleaner. (Should also help with AMD64 support later on.) - Fix if_ndis.c to use KeRaiseIrql() and KeLowerIrql() instead of the previous calls to hal_raise_irql() and hal_lower_irql() which have been renamed. The function renaming generated a lot of churn here, but there should be very little operational effect.
* Fix a problem reported by Pierre Beyssac. Sometinmes when ndis_get_info()wpaul2005-01-141-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | calls MiniportQueryInformation(), it will return NDIS_STATUS_PENDING. When this happens, ndis_get_info() will sleep waiting for a completion event. If two threads call ndis_get_info() and both end up having to sleep, they will both end up waiting on the same wait channel, which can cause a panic in sleepq_add() if INVARIANTS are turned on. Fix this by having ndis_get_info() use a common mutex rather than using the process mutex with PROC_LOCK(). Also do the same for ndis_set_info(). Note that Pierre's original patch also made ndis_thsuspend() use the new mutex, but ndis_thsuspend() shouldn't need this since it will make each thread that calls it sleep on a unique wait channel. Also, it occured to me that we probably don't want to enter MiniportQueryInformation() or MiniportSetInformation() from more than one thread at any given time, so now we acquire a Windows spinlock before calling either of them. The Microsoft documentation says that MiniportQueryInformation() and MiniportSetInformation() are called at DISPATCH_LEVEL, and previously we would call KeRaiseIrql() to set the IRQL to DISPATCH_LEVEL before entering either routine, but this only guarantees mutual exclusion on uniprocessor machines. To make it SMP safe, we need to use a real spinlock. For now, I'm abusing the spinlock embedded in the NDIS_MINIPORT_BLOCK structure for this purpose. (This may need to be applied to some of the other routines in kern_ndis.c at a later date.) Export ntoskrnl_init_lock() (KeInitializeSpinlock()) from subr_ntoskrnl.c since we need to use in in kern_ndis.c, and since it's technically part of the Windows kernel DDK API along with the other spinlock routines. Use it in subr_ndis.c too rather than frobbing the spinlock directly.
* Start each of the license/copyright comments with /*-imp2005-01-051-1/+1
|
* Make the Texas Instruments 802.11g chipset work with the NDISulator.wpaul2004-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was tested with a Netgear WG311v2 802.11b/g PCI card. Things that were fixed: - This chip has two memory mapped regions, one at PCIR_BAR(0) and the other at PCIR_BAR(1). This is a little different from the other chips I've seen with two PCI shared memory regions, since they tend to have the second BAR ad PCIR_BAR(2). if_ndis_pci.c tests explicitly for PCIR_BAR(2). This has been changed to simply fill in ndis_res_mem first and ndis_res_altmem second, if a second shared memory range exists. Given that NDIS drivers seem to scan for BARs in ascending order, I think this should be ok. - Fixed the code that tries to process firmware images that have been loaded as .ko files. To save a step, I was setting up the address mapping in ndis_open_file(), but ndis_map_file() flags pre-existing mappings as an error (to avoid duplicate mappings). Changed this so that the mapping is now donw in ndis_map_file() as expected. - Made the typedef for 'driver_entry' explicitly include __stdcall to silence gcc warning in ndis_load_driver(). NOTE: the Texas Instruments ACX111 driver needs firmware. With my card, there were 3 .bin files shipped with the driver. You must either put these files in /compat/ndis or convert them with ndiscvt -f and kldload them so the driver can use them. Without the firmware image, the NIC won't work.
* More minor cleanups and one small bug fix:wpaul2004-08-041-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | - In ntoskrnl_var.h, I had defined compat macros for ntoskrnl_acquire_spinlock() and ntoskrnl_release_spinlock() but never used them. This is fortunate since they were stale. Fix them to work properly. (In Windows/x86 KeAcquireSpinLock() is a macro that calls KefAcquireSpinLock(), which lives in HAL.dll. To imitate this, ntoskrnl_acquire_spinlock() is just a macro that calls hal_lock(), which lives in subr_hal.o.) - Add macros for ntoskrnl_raise_irql() and ntoskrnl_lower_irql() that call hal_raise_irql() and hal_lower_irql(). - Use these macros in kern_ndis.c, subr_ndis.c and subr_ntoskrnl.c. - Along the way, I realised subr_ndis.c:ndis_lock() was not calling hal_lock() correctly (it was using the FASTCALL2() wrapper when in reality this routine is FASTCALL1()). Using the ntoskrnl_acquire_spinlock() fixes this. Not sure if this actually caused any bugs since hal_lock() would have just ignored what was in %edx, but it was still bogus. This hides many of the uses of the FASTCALLx() macros which makes the code a little cleaner. Should not have any effect on generated object code, other than the one fix in ndis_lock().
* Big mess 'o changes:wpaul2004-08-011-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Give ndiscvt(8) the ability to process a .SYS file directly into a .o file so that we don't have to emit big messy char arrays into the ndis_driver_data.h file. This behavior is currently optional, but may become the default some day. - Give ndiscvt(8) the ability to turn arbitrary files into .ko files so that they can be pre-loaded or kldloaded. (Both this and the previous change involve using objcopy(1)). - Give NdisOpenFile() the ability to 'read' files out of kernel memory that have been kldloaded or pre-loaded, and disallow the use of the normal vn_open() file opening method during bootstrap (when no filesystems have been mounted yet). Some people have reported that kldloading if_ndis.ko works fine when the system is running multiuser but causes a panic when the modile is pre-loaded by /boot/loader. This happens with drivers that need to use NdisOpenFile() to access external files (i.e. firmware images). NdisOpenFile() won't work during kernel bootstrapping because no filesystems have been mounted. To get around this, you can now do the following: o Say you have a firmware file called firmware.img o Do: ndiscvt -f firmware.img -- this creates firmware.img.ko o Put the firmware.img.ko in /boot/kernel o add firmware.img_load="YES" in /boot/loader.conf o add if_ndis_load="YES" and ndis_load="YES" as well Now the loader will suck the additional file into memory as a .ko. The phony .ko has two symbols in it: filename_start and filename_end, which are generated by objcopy(1). ndis_open_file() will traverse each module in the module list looking for these symbols and, if it finds them, it'll use them to generate the file mapping address and length values that the caller of NdisOpenFile() wants. As a bonus, this will even work if the file has been statically linked into the kernel itself, since the "kernel" module is searched too. (ndiscvt(8) will generate both filename.o and filename.ko for you). - Modify the mechanism used to provide make-pretend FASTCALL support. Rather than using inline assembly to yank the first two arguments out of %ecx and %edx, we now use the __regparm__(3) attribute (and the __stdcall__ attribute) and use some macro magic to re-order the arguments and provide dummy arguments as needed so that the arguments passed in registers end up in the right place. Change taken from DragonflyBSD version of the NDISulator.
* Make NdisReadPcmciaAttributeMemory() and NdisWritePcmciaAttributeMemory()wpaul2004-07-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | actually work. Make the PCI and PCCARD attachments provide a bus_get_resource_list() method so that resource listing for PCCARD works. PCCARD does not have a bus_get_resource_list() method (yet), so I faked up the resource list management in if_ndis_pccard.c, and added bus_get_resource_list() methods to both if_ndis_pccard.c and if_ndis_pci.c. The one in the PCI attechment just hands off to the PCI bus code. The difference is transparent to the NDIS resource handler code. Fixed ndis_open_file() so that opening files which live on NFS filesystems work: pass an actual ucred structure to VOP_GETATTR() (NFS explodes if the ucred structure is NOCRED). Make NdisMMapIoSpace() handle mapping of PCMCIA attribute memory resources correctly. Turn subr_ndis.c:my_strcasecmp() into ndis_strcasecmp() and export it so that if_ndis_pccard.c can use it, and junk the other copy of my_strcasecmp() from if_ndis_pccard.c.
* Add another 5.2.1 source compatibility tweak: acquire Giant before callingwpaul2004-06-071-0/+3
| | | | kthread_exit() if FreeBSD_version is old enough.
* Take advantage of the dev sysctl tree.des2004-06-041-0/+12
| | | | Approved by: wpaul
* Explicitly #include <sys/module.h> instead of depending on <sys/kernel.h>wpaul2004-06-011-0/+1
| | | | to do it for us.
* Ok, _really_ fix the Intel 2100B Centrino deadlock problems this time.wpaul2004-04-221-12/+27
| | | | | | | | | | | | | | | | (I hope.) My original instinct to make ndis_return_packet() asynchronous was correct. Making ndis_rxeof() submit packets to the stack asynchronously fixes one recursive spinlock acquisition, but it's also possible for it to happen via the ndis_txeof() path too. So: - In if_ndis.c, revert ndis_rxeof() to its old behavior (and don't bother putting ndis_rxeof_serial() back since we don't need it anymore). - In kern_ndis.c, make ndis_return_packet() submit the call to the MiniportReturnPacket() function to the "ndis swi" thread so that it always happens in another context no matter who calls it.
* - Use memory barrier with atomic operations in ntoskrnl_lock_dpc() andwpaul2004-04-161-1/+1
| | | | | | | | | | | | | | ntoskrnl_unlocl_dpc(). - hal_raise_irql(), hal_lower_irql() and hal_irql() didn't work right on SMP (priority inheritance makes things... interesting). For now, use only two states: DISPATCH_LEVEL (PI_REALTIME) and PASSIVE_LEVEL (everything else). Tested on a dual PIII box. - Use ndis_thsuspend() in ndis_sleep() instead of tsleep(). (I added ndis_thsuspend() and ndis_thresume() to replace kthread_suspend() and kthread_resume(); the former will preserve a thread's priority when it wakes up, the latter will not.) - Change use of tsleep() in ndis_stop_thread() to prevent priority change on wakeup.
* Continue my efforts to imitate Windows as closely as possible bywpaul2004-04-141-34/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
* In ndis_convert_res(), initialize the head of our temporary listwpaul2004-04-071-1/+2
| | | | | | | before calling BUS_GET_RESOURCE_LIST(). Previously, the list head would only be initialized if BUS_GET_RESOURCE_LIST() succeeded; it needs to be initialized unconditionally so that the list cleanup code won't trip over potential stack garbage.
* - The MiniportReset() function can return NDIS_STATUS_PENDING, in whichwpaul2004-04-051-16/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
* Add missing cprd_flags member to partial resource structure inwpaul2004-03-291-0/+10
| | | | | | | | | | | | | resource_var.h. In kern_ndis.c:ndis_convert_res(), fill in the cprd_flags and cprd_sharedisp fields as best we can. In if_ndis.c:ndis_setmulti(), don't bother updating the multicast filter if our multicast address list is empty. Add some missing updates to ndis_var.h and ntoskrnl_var.h that I forgot to check in when I added the KeDpc stuff.
* - In subr_ndis.c:ndis_init_event(), initialize events as notificationwpaul2004-03-251-2/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | objects rather than synchronization objects. When a sync object is signaled, only the first thread waiting on it is woken up, and then it's automatically reset to the not-signaled state. When a notification object is signaled, all threads waiting on it will be woken up, and it remains in the signaled state until someone resets it manually. We want the latter behavior for NDIS events. - In kern_ndis.c:ndis_convert_res(), we have to create a temporary copy of the list returned by BUS_GET_RESOURCE_LIST(). When the PCI bus code probes resources for a given device, it enters them into a singly linked list, head first. The result is that traversing this list gives you the resources in reverse order. This means when we create the Windows resource list, it will be in reverse order too. Unfortunately, this can hose drivers for devices with multiple I/O ranges of the same type, like, say, two memory mapped I/O regions (one for registers, one to map the NVRAM/bootrom/whatever). Some drivers test the range size to figure out which region is which, but others just assume that the resources will be listed in ascending order from lowest numbered BAR to highest. Reversing the order means such drivers will choose the wrong resource as their I/O register range. Since we can't traverse the resource SLIST backwards, we have to make a temporary copy of the list in the right order and then build the Windows resource list from that. I suppose we could just fix the PCI bus code to use a TAILQ instead, but then I'd have to track down all the consumers of the BUS_GET_RESOURCE_LIST() and fix them too.
* - In kern_ndis.c, implement ndis_unsched(), the complement to ndis_sched(),wpaul2004-03-251-0/+33
| | | | | | | | | | | | | | which pulls a job off a thread work queue (assuming it hasn't run yet). This is needed for KeRemoveQueueDpc(). - In subr_ntoskrnl.c, implement KeInsertQueueDpc() and KeRemoveQueueDpc(), to go with KeInitializeDpc() to round out the API. Also change the KeTimer implementation to use this API instead of the private timer callout scheduler. Functionality of the timer API remains unchanged, but we get a couple new Windows kernel API routines and more closely imitate the way thing works in Windows. (As of yet I haven't encountered any drivers that use KeInsertQueueDpc() or KeRemoveQueueDpc(), but it doesn't hurt to have them.)
* I'm a dumbass: the test in the MOD_SHUTDOWN case in ndis_modevent()wpaul2004-03-221-1/+1
| | | | that checks to see if any devices are still in the devlist was reversed.
* The Intel 2200BG NDIS driver does an alloca() of about 5000 byteswpaul2004-03-221-2/+4
| | | | | | | | | | | | | | | | | when it associates with a net. Because FreeBSD's kstack size is only 2 pages by default, this blows the stack and causes a double fault. To deal with this, we now create all our kthreads with 8 stack pages. Also, we now run all timer callouts in the ndis swi thread (since they would otherwise run in the clock ithread, whose stack is too small). It happens that the alloca() in this case was occuring within the interrupt handler, which was already running in the ndis swi thread, but I want to deal with the callouts too just to be extra safe. NOTE: this will only work if you update vm_machdep.c with the change I just committed. If you don't include this fix, setting the number of stack pages with kthread_create() has essentially no effect.
* - Rewrite the timer and event API routines in subr_ndis.c so that theywpaul2004-03-201-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are actually layered on top of the KeTimer API in subr_ntoskrnl.c, just as it is in Windows. This reduces code duplication and more closely imitates the way things are done in Windows. - Modify ndis_encode_parm() to deal with the case where we have a registry key expressed as a hex value ("0x1") which is being read via NdisReadConfiguration() as an int. Previously, we tried to decode things like "0x1" with strtol() using a base of 10, which would always yield 0. This is what was causing problems with the Intel 2200BG Centrino 802.11g driver: the .inf file that comes with it has a key called RadioEnable with a value of 0x1. We incorrectly decoded this value to '0' when it was queried, hence the driver thought we wanted the radio turned off. - In if_ndis.c, most drivers don't accept NDIS_80211_AUTHMODE_AUTO, but NDIS_80211_AUTHMODE_SHARED may not be right in some cases, so for now always use NDIS_80211_AUTHMODE_OPEN. NOTE: There is still one problem with the Intel 2200BG driver: it happens that the kernel stack in Windows is larger than the kernel stack in FreeBSD. The 2200BG driver sometimes eats up more than 2 pages of stack space, which can lead to a double fault panic. For the moment, I got things to work by adding the following to my kernel config file: options KSTACK_PAGES=8 I'm pretty sure 8 is too big; I just picked this value out of a hat as a test, and it happened to work, so I left it. 4 pages might be enough. Unfortunately, I don't think you can dynamically give a thread a larger stack, so I'm not sure how to handle this short of putting a note in the man page about it and dealing with the flood of mail from people who never read man pages.
* Fix mind-o: sanity check in ndis_disable_ndis() is not sane.wpaul2004-03-111-1/+1
|
* Add preliminary support for PCMCIA devices in addition to PCI/cardbus.wpaul2004-03-071-47/+0
| | | | | | | | | | | | if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
* kthread_exit() no longer requires Giant, so don't force callers to acquirejhb2004-03-051-1/+0
| | | | | | Giant just to call kthread_exit(). Requested by: many
* Fix a problem with the way we schedule work on the NDIS worker threads.wpaul2004-02-141-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Am1771 driver will sometimes do the following: - Some thread-> NdisScheduleWorkItem(some work) - Worker thread -> do some work, KeWaitForSingleObject(some event) - Some other thread -> NdisScheduleWorkItem(some other work) When the second call to NdisScheduleWorkItem() occurs, the NDIS worker thread (in our case ndis taskqueue) is suspended in KeWaitForSingleObject() and waiting for an event to be signaled. This is different from when the worker thread is idle and waiting on NdisScheduleWorkItem() to send it more jobs. However, the ndis_sched() function in kern_ndis.c always calls kthread_resume() when queueing a new job. Normally this would be ok, but here this causes KeWaitForSingleObject() to return prematurely, which is not what we want. To fix this, the NDIS threads created by kern_ndis.c maintain a state variable to indicate whether they are running (scanning the job list and executing jobs) or sleeping (blocked on kthread_suspend() in ndis_runq()), and ndis_sched() will only call kthread_resume() if the thread is in the sleeping state. Note that we can't just check to see if the thread is on the run queue: in both cases, the thread is sleeping, but it's sleeping for different reasons. This stops the Am1771 driver from emitting various "NDIS ERROR" messages and fixes some cases where it crashes.
* Add yet more bulletproofing. This is to guard against the case thatwpaul2004-02-111-31/+52
| | | | | ndis_init_nic() works one during attach, but fails later. Many things will blow up if ndis_init_nic() fails and we aren't careful.
* Add some bulletproofing: don't allow the ndis_get_info() or ndis_set_info()wpaul2004-02-101-0/+7
| | | | | | | | | | routines to do anything except return error if the miniport adapter context is not set (meaning we either having init'ed the driver yet, or the initialization failed). Also, be sure to NULL out the adapter context along with the miniport characteristics pointers if calling the MiniportInitialize() method fails.
* Add a whole bunch of new stuff to make the driver for the AMD Am1771/Am1772wpaul2004-02-071-22/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 802.11b chipset work. This chip is present on the SMC2602W version 3 NIC, which is what was used for testing. This driver creates kernel threads (12 of them!) for various purposes, and required the following routines: PsCreateSystemThread() PsTerminateSystemThread() KeInitializeEvent() KeSetEvent() KeResetEvent() KeInitializeMutex() KeReleaseMutex() KeWaitForSingleObject() KeWaitForMultipleObjects() IoGetDeviceProperty() and several more. Also, this driver abuses the fact that NDIS events and timers are actually Windows events and timers, and uses NDIS events with KeWaitForSingleObject(). The NDIS event routines have been rewritten to interface with the ntoskrnl module. Many routines with incorrect prototypes have been cleaned up. Also, this driver puts jobs on the NDIS taskqueue (via NdisScheduleWorkItem()) which block on events, and this interferes with the operation of NdisMAllocateSharedMemoryAsync(), which was also being put on the NDIS taskqueue. To avoid the deadlock, NdisMAllocateSharedMemoryAsync() is now performed in the NDIS SWI thread instead. There's still room for some cleanups here, and I really should implement KeInitializeTimer() and friends.
* Implement support for single packet sends. The Intel Centrino driverwpaul2004-02-031-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
OpenPOWER on IntegriCloud