> On Fri, 11 Nov 2005 05:42:07 +0000 (GMT) > wpaul_at_FreeBSD.ORG (Bill Paul) wrote: > > > > Ran into a few problems with ndisgen today. > > > > > > I have to edit every instance of the following out to get it to > > > convert. > > > Magic Packet = "Magic Packet" > > > Pattern Match = "Pattern Match" > > > Mag Pack Patt Match = "Magic Packet & Pattern Match" > > > Link Change = "Link Change" > > > > > > > > > Upon loading the driver I get... > > > no match for ExUnregisterCallback > > > no match for ZwPowerInformation > > > no match for ExRegisterCallback > > > no match for ExCreateCallback > > > no match for ZwUnmapViewOfSection > > > no match for ZwMapViewOfSection > > > no match for ZwOpenSection > > > no match for wcslen > > > > > > Any chance of getting this working or any suggestions? > > > > > > > Ok, had I read the subject line of your mail fully I'd have known > > what driver it was. I'm a dolt and I've clearly had too long of a > > day. > > > > Here are the problems: > > > > - I don't know exactly what driver image you have. Unless you > > provide the URL for where you got it to put a copy somewhere, > > I can't really analyze it. > > http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6 > > IIRC the installer dumps it Program Files/Marvell It is where I > grabbed the .sys and . I can probably unscramble it with Wine. I've had pretty good luck with it with other driver distribution. > > - The .inf parser is not perfect. It's actually much stricter > > about syntax than Windows is. Stuff that works ok for Windows > > may be flagged as a syntax error by ndiscvt. If someone wants > > to help fix this, they're welcome to. (No kernel hacking > > required.) > > Cool, any suggested reads? The Microsoft MSDN site is the canonical source for documentation, such as it is. I would start with something like: http://www.microsoft.com/whdc/archive/W2inf.mspx The .INF syntax is very subtle: it's evolved a lot over time and you can use it to produce many strange effects. For example, it's possible to create a .INF file that can figure out if you're on a Win98, Win2K or WinXP system and install a different driver for each one. Another major source of complication is registry key specifications. NDIS drivers tend to specify only a few keys that need to be created at install time, but it's possible to create large numbers of them for various purposes. I've seen a Conexant modem driver that uses its .INF file to store a bunch of special keys containing some kind of binary patch tables that are used by the driver at runtime. There's also different patch tables for different chipsets. > > - I have no earthy idea why Marvell is referencing these functions > > in their driver. They're totally outside the NDIS spec. I'd be > > rather surprised that such a driver was able to get WHQL > > certification. (Assuming it did.) Some investigation shows that they're probably using ExRegisterCallback() and its ilk to obtain notification about power state events. And I think they're using ZwMapViewOfSection() to basically do 'vtophys(),' i.e. map a physical address to a virtual one, probably so they can access some card resident RAM that's mapped into the host. (Actually, ZwMapViewOfSection() lets you read from the \Devices\PhysicalMemory device, so really it's the equivalent of grovelling around in /dev/mem.) I'm unsure why they're doing this. I was under the impression you were supposed to have a MiniportPnpEvent() method to handle power event notifications. As for the physical/virtual address translation thing, they could have used NdisMMapIoSpace() or maybe even MmMapIoSpace() instead. Who knows. > > - This is Marvell. Given the rotten treatment I've had from them > > in the past, I'm not inclined to do them any favors now, so I'm > > not exactly inclined to fix this anytime soon. > > Fun, what happened, if I may ask? Back when the patches to support the Yukon with sk(4) were first merged in, and people were having problems with multicast, I asked one of my SysKonnect contacts (who had now been assimilated by Marvell) for the Yukon manuals so I could fix it. They told me that I would need to sign both an NDA, and a software license agreement. I thought this was strange since I wasn't licensing them my software and they weren't licensing me theirs, but I told them I wanted official recognition of the fact that this was an open source project and that's what they came up with. I said "ok, send me both documents so I can read them." They sent me the NDA, but not the software license agreement. I wanted both before I would sign anything, and kept prodding my contact to send the license agreement, but he kept begging off and promising to talk with the right people. Finally after about a month of this, I finally got an e-mail from someone else telling me that they had decided they were going to produce their own binary driver (actually, they had been working on it all along) and because of that they saw no need to give me the manuals now. But they did offer me some free sample cards. I told them I was terminating any further involvement with SysKonnect and Marvell and they could keep their cards. I still have the e-mails from them archived somewhere. Some time later (I'm not sure how long, maybe a month or two), I was contacted via e-mail by a SysKonnect/Marvell engineer in Germany who wanted to know if we could make the sk(4) driver optional so that their customers could use their binary only driver without having to recompile the kernel. I told him flatly that I wasn't on speaking terms with his company anymore and that he was out of luck. I was startled to receive a phone call from him shortly after. He was rather taken aback and curious to know why I had become so unhappy with his company, so I explain to him how his Marvell overlords had stonewalled me earlier. He was very surprised and disappointed. He seemed like a nice fellow and I told him while I had nothing against him personally, but I was not about to make Marvell's life easier when they had made mine so miserable. During our conversation, I found out that he had been tasked with developing the Yukon driver for FreeBSD. Then it was my turn to be taken aback, when he admitted to me that he hadn't actually read the Yukon manual: instead, he had been provided with an API library for communicating with the card and was essentially producing a wrapper for that library to interface it with FreeBSD. Now, this technique is not new: Broadcom and other vendors have been using it for a long time. But even so, I would like to think that library or no, the engineers writing the drivers are actually familiar with the hardware. So you can understand why I'm not in any hurry to do anything nice for them. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul_at_windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================Received on Sat Nov 12 2005 - 03:36:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:47 UTC