Hardware & Devices

fat_boy15-Dec-08 22:55

15-Dec-08 22:55

sharp81 wrote:
Its taking the MAC-Address as 0's in the driver initialisation with memcpy and OID parameters

At some stage the code should get the MAC address off the card. Search the code for any place where the variable that holds the MAC address gets written to.

sharp81 wrote:
How can I do a HW reset so that I can check if that's where the problem lies

That will be device dependent but would probably involove a write of a byte to a port.

Morality is indistinguishable from social proscription

sharp8114-Dec-08 6:14

14-Dec-08 6:14

I want to check if the problem is actually lying in the firmware or the software. Do you know how I can get traces from the firmware to check where the problem might be lying. I know there are some trace tools that I can couple with Windbg but dont know if it can do a firmware trace.

Thanks for your help again.

Sharp

fat_boy15-Dec-08 22:56

15-Dec-08 22:56

sharp81 wrote:
how I can get traces from the firmware

Again that is device dependent. You might need an external bit of HW that plugs into the card, or there could be some SW that can do it. I dont know, but windbgg wont be able to onits own.

Morality is indistinguishable from social proscription

sharp817-Jan-09 23:00

7-Jan-09 23:00

Thanks again. I think here the firmware is not resetting on a warm boot. But actually we dont want a firmware reset either. Could this also be a synchronisation problem? When I do a cold reset and then do a disable and enable of the device it still works. I guess it should be pretty much the same when we warm boot or?

fat_boy8-Jan-09 0:05

8-Jan-09 0:05

Best thing is to read the address of the FW. If it returns a valid address, it was a cold boot, so the driver can then write that address somewhere usefull in the registry. Then, when it next boots, if it reads a zero off the FW it can get the address from the registry and use that.

Morality is indistinguishable from social proscription

sharp818-Jan-09 0:54

8-Jan-09 0:54

could you please let me know how i can write this address to the registry and later read it from there?

Thanks

fat_boy8-Jan-09 1:08

8-Jan-09 1:08

Hey, come on, dont be so lazy, look in the DDK. Smile | :)

Morality is indistinguishable from social proscription

sharp818-Jan-09 5:28

8-Jan-09 5:28

... yeah, i guess you are right ... i will do some reading and try to find the solution.
Btw I would prefer rather than spoofing the MAC to actually figure out the exact location of the problem.
In my case when I try to enable and disable the driver after a cold boot I still see the correct MAC but with the warm start its still the same problem no reaction at all. I dont how the driver initializes in case of disabling and enabling but isnt it similar to the way its warm booted?

What would be your suggestion without having to use the registry to find the error?

And thanks for all the support

fat_boy8-Jan-09 5:50

8-Jan-09 5:50

Well, it IS a FW/HW problem. Its coming out of a warm boot into some kind of bad state. Probably due to capacitance on the card still. You either need to have some clear down HW so the caps get discharged or have a HW reset feature in FW.

But, you can use the approach I mentioned to over come this since you arent spoofing the addresss, merely remembering it from a cold boot where the driver can read it correctly.

Morality is indistinguishable from social proscription

sharp818-Jan-09 23:28

8-Jan-09 23:28

I tried a firmware trace and it tries to get the multicast address but with the wrong values. That's the reason I wonder if it is either a sync problem or if this could do something with the SW. How can I make sure it is a FW/HW problem?

fat_boy9-Jan-09 2:52

9-Jan-09 2:52

If your driver reads the address off a particular port on the card and it gets a zero after a warm boot then its a HW/FW issue.

And I assume you have verified this in windbg or some such?

Morality is indistinguishable from social proscription

sharp819-Jan-09 3:09

9-Jan-09 3:09

I tried to debug in Windbg for the error. I tried to set the bp on the driver initialize function. I think it did go through the driver init but still obtained the 0's.
I will do the debug again and provide you the results. But how could it work when I disable and enable the driver in the device manager? Isnt it the same as a warm start?

fat_boy9-Jan-09 4:12

9-Jan-09 4:12

sharp81 wrote:
But how could it work when I disable and enable the driver in the device manager? Isnt it the same as a warm start?

I guess not. DOnt forget a warm boot leaves the device depowerted for a very short time, far shorter than you can click disable and enable in device manager

Morality is indistinguishable from social proscription

sharp819-Jan-09 4:36

9-Jan-09 4:36

So when i do a warm boot and then disable and enable in device manager it doesnt work becoz at this point the device already has a wrong MAC-address. One more test I tried out was to disable the device in device manager and enable it again after a warm start but it still doesnt work on that case. In windbg I used the locals to check for the MAC-address value. Is this the only place to do this or what other options would you recommend to check for the MAC-Address changes?

Thanks

fat_boy9-Jan-09 4:58

9-Jan-09 4:58

Does the device depower when disabled in device manager?

Anyway, the best solution is the one I have suggested. Read the MAC address and if its not zero, store it in the registry. Of it is zero, then get it from the registry.

Morality is indistinguishable from social proscription

sharp819-Jan-09 5:06

9-Jan-09 5:06

I think it does not depower but i am not totally sure either. Becoz if it does depower then it should work just like a cold start. So I guess it doesnt depower and just takes the value available. Though I could see from the debugger that on enabling in device manager it starts the driver initialization again.

You mentioned with a cold start it depowers very fast and is back up again. So why do you think its not a sync problem?

I think i like your solution but the thing I have to make sure changing the code is that there arent any errors. Are there any code snippets for reading and writing Address to registry?

fat_boy9-Jan-09 5:10

9-Jan-09 5:10

sharp81 wrote:
I think it does not depower but i am not totally sure either. Becoz if it does depower then it should work just like a cold start.

Yes. Unless some other perverse logic is involved, which is possible.

sharp81 wrote:
Though I could see from the debugger that on enabling in device manager it starts the driver initialization again

It always will.

sharp81 wrote:
I think i like your solution but the thing I have to make sure changing the code is that there arent any errors. Are there any code snippets for reading and writing Address to registry?

If you want to be a kernel programmer you are gong to roll your sleves up and get your hands dirty. The DDK might have some samples, but better than to cut and paste, whcih can create all kinds of errors, just read the docs and go for it.

Since its Ethernet, and hence Ndis, look at NdisOpenConfiguration (or NdisOpenConfigurationEx for an ndis 6 driver (ie for vista only))

Its quite simple. You call this from MiniportInitialise (you cant call it at any other time, you get a BSOD if you do) andf then NdisReadConfiguration.

Morality is indistinguishable from social proscription

sharp8112-Jan-09 23:19

Re: Ethernet card - Device Driver [modified]

12-Jan-09 23:19

I would be really glad if you could let me know how i can get the print of dbgprint commands on my windbg command window. With !dbgprint I am not seeing anything.

sharp8113-Jan-09 1:31

13-Jan-09 1:31

I managed to setup the dbgprint for windbg and to check for the print logs. During the warm start the system hung up when getting the OID's. And the log from the intialiaze function says "failed to connect to the FW. Timeout exceeded"
Any ideas?

modified on Tuesday, January 13, 2009 7:43 AM

fat_boy13-Jan-09 2:00

13-Jan-09 2:00

Sometimes ndis throws an exception on start but you can just continue this, it isnt a BSOD stop error.

As for the FW failure it looks like you found the issue, the FW seems to fail to boot on a warm boot. Looks like you have to go back to the HW team or manufacturer and show them what you have seen.

Morality is indistinguishable from social proscription

sharp8113-Jan-09 2:18

13-Jan-09 2:18

actually it doesnt continue .. it just stalls and i need to turn off and turn on the system again. So from the "communication with FW failed error" can I surely say the problem is with FW or?

fat_boy13-Jan-09 2:21

13-Jan-09 2:21

does the driver hang on to an OID for a long time? If so it should return pending and complete it later. I wouldnt expect this to hang the system though.

As for the FW yes, it is failing to respond to the driver so it looks lke an electrical/FW boot problem. Perhaps the FW crashes?

Morality is indistinguishable from social proscription

sharp8113-Jan-09 2:47

13-Jan-09 2:47

interestingly it booted once without the communication failed error. But still gives wrong MAC address. I am totally confused what's happening

fat_boy13-Jan-09 2:54