Supporting thread for the Forcedeth ethernet port (http://www.os2world.com/content/view/14612/71/) bounty.
There was some suggestions made regarding this port that it should be expanded to involvde Nvidia chipset for all NICs; due to our weekly disk problems (http://www.os2world.com/content/view/14614/81/); we lost 24 hours of data... So it would be great if we just could take this once more?
Hi all,
here's the ramp-up on what was posted in the meanwhile before the data loss:
- Paul suggested to turn the bounty into "driver for nForce built-in NICs" instead of "port of forcedeth". He said that HOW it's done doesn't matter as long as we get a driver for the NICs
- I (Thomas) had replied that I agree and that we need the driver because we won't have MoBos with "enough" PCI slots in the long term that give us the chance to plug in PCI NICs and deactivate the onboard ones
- Cris has agreed and already paid money to the bounty. He suggested the port because he thought that it was the only option to go in order to get adriver
Conclusion:
Yes, turn the bounty from "port of forcedeth" into "driver for nForce chipset NICs".
I will add money to the bounty as well (nForce is my preferred chipset and I would welcome a driver for the NICs)
Regards,
Thomas
Hi Kim,
basically the request was to modify the bounty in this way: do not request a port of focedeth, instead request a way to enable the NIC of the nForce chipset under OS/2, whichever this way is.
The forcedeth port can remain as a suggestion (useful for those who don't know about this driver or as a starting point), but the bounty should not discriminate among solutions.
I agree with the suggestion (made by Paul Smedley). We want the NIC to work, we don't want to force a particular development path.
Thankyou!
Bye
Cris
Excellent! I'll update the bounty task either today or during the weekend. But, I agree with the idea (I did read the earlier posting from Thomas and Paul) and support this change of the bounty.
Kim,
are you going to update the bounty? I see nobody is adding money to it, probably waiting for it to be updated...
Thank you
Bye
Cris
Sorry for the delay, but been away for couple of days. But, I've changed the bounty name to Pauls recommendation and I think that the rest of the text works out.
Also, when it comes to update the bounty text, I'm actually think that it might be an good idea to set the person who suggested the bounty as owner of the article. In this case it's Cris and that would make sure that the suggester and as well the other staff can assist in updating material. An idea to aprove?
Hi Kim,
good idea! Would that be feasible for the other (past but still open) bounties as well?
That would give me the chance to add more descriptive text for example.
Regards,
Thomas
Quote from: warpcafe on 2007.06.21, 14:48:17
good idea! Would that be feasible for the other (past but still open) bounties as well?
That would give me the chance to add more descriptive text for example.
To keep this thread clean I've posted splitted the topic and follow-up can be found here (http://www.os2world.com/component/option,com_smf/Itemid,63/topic,230.0/).
If I had time to look at this, the first thing I would look into is whether there is already any network driver ported from Linux, because its source could be used as a basis. If not, I would then look for any open source network driver.
The answer would probably be useful to anyone who might want to try. Does anyone know?
Hi,
there already is a driver in development by a Russian developer (nickk).
He does not have the hardware, so he is relying on beta testers to debug the driver.
If you have a COM port, another computer, and a null modem cable, you can participate in testing (he is routing debug messages through the COM port). I am testing it already.
Bye
Cris
I don't have this hardware. My intent was to offer a bit of advice because I am interested in seeing a long-term solution for porting such drivers now and in the future, not just one driver for one device.
Hi all
nickk had made a claim request for this bounty.
Please, sponsors and people that have the hardware, try the driver at:
http://hobbes.nmsu.edu/pub/incoming/nveth-0.0.1.zip
(soon to be moved to http://hobbes.nmsu.edu/pub/os2/system/drivers/network/nveth-0.0.1.zip )
Regards.
My only observation, since I don't have that hardware, is that the driver source code should be also uploaded to hobbes.
martin.
Bounty rules can be found here: http://www.os2world.com/bounties/rules.php
Hi all,
the driver is working beautifully for me, so I am in favor of awarding the bounty to nickk.
Since driver development is a difficult process, it would be nice if a public warning about the impending closure of the bounty was issued, like it was done with Paul Smedley's Gnash bounty claim, so that the bounty amount is (hopefully) increased and nickk is well rewarded for his work (I did a lot of testing with him, and at times he was sending me more than a build per day).
One thing people need to be aware of: the latest ACPI builds include by default an experimental implementation of OEMHLP functions. This experimental functions substitute IBM's original implementation, but due to bugs they make the driver fail. There is a documented way to re-enable IBM's original implementation, but on my system it DISABLES ACPI. So I am now forced to choose among having ACPI or having a functional NIC.
I have notified the ACPI developers about the problem, but still haven't had a reply (please see http://forum.ecomstation.ru/viewtopic.php?t=6200 and ask for a fix if you have the problem too).
Bye
Cris
If this is based on Forcedeth it is GPL and must have the source available.
I love that bounties are being awarded, and I think Nickk is deserving.
I have one network device driver test that is worth posting, and I hope that someone with the hardware can do this one.
Connect via NetBIOS both ways, sharing and connecting. Copy a files adding up to 10 GB from one machine to another. There are four possibilities, depending on pushing and pulling from each machine.
If the driver is faulty (and many current OS/2 drivers are), then you will hit a kernel trap. You will possibly see the trap in NetBIOS, but that is wrong -- it's the fault of the device driver. I don't know the reason for the trap, but somewhere along the line, wrong source code was distributed, and that's why many drivers have the trap.
Good luck nickk!
Quote from: Cristiano Guadagnino on 2007.07.23, 13:42:22
One thing people need to be aware of: the latest ACPI builds include by default an experimental implementation of OEMHLP functions. This experimental functions substitute IBM's original implementation, but due to bugs they make the driver fail. There is a documented way to re-enable IBM's original implementation, but on my system it DISABLES ACPI. So I am now forced to choose among having ACPI or having a functional NIC.
I have notified the ACPI developers about the problem, but still haven't had a reply (please see http://forum.ecomstation.ru/viewtopic.php?t=6200 and ask for a fix if you have the problem too).
I wonder if this is why the driver didn't work for me. It loaded OK but TCPIP couldn't bind to it.......
Quote from: Paul Smedley on 2007.07.23, 23:57:50
I wonder if this is why the driver didn't work for me. It loaded OK but TCPIP couldn't bind to it.......
If you have an nforce1 (PCI 10de:01c3) then it's a bug in the driver itself. Nickk sent me
a fix that I will test this afternoon.
Also I'm not fully convinced, that Cristiano's statement about the internal OEMHLP$ is correct.
Once the driver loads on my machine, I will have a look at it...
Paul, rudi,
I had the same symptoms: the driver loaded OK but it didn't work.
It was nickk who pointed me to the ACPI problem, and that solved it for me (although the procedure described in the ACPI package to disable the internal OEMHLP$ doesn't work as advertised: it disables ACPI on my hw).
Please see ACPI FAQ Q.64 for a little how-to.
Hope this helps...
Bye
Cris
Hi Cris and Paul,
The updated version Nickk sent me this morning is working for 10de:01c3 devices.
I can now reproduce the ACPI problem and I do have an idea, what it might be. If
my assumption turns out to be true, it's discussable if it's considered to be a bug in
ACPI or in the network driver. However, it will be easy to fix...
Hi
I just downloaded nveth-0.0.1.zip and installed it on an ASUS A7N8X-E Motherboard. This has 2 NICs: the upper is an MCT-T from the nForce 2 chipset (10DE:0066), the lower is an Marwell 88E001 Gigabit NIC (11AB:4320).
Both are working with GenMac 2.0. The nForce 2 also works fine with the nveth-0.0.1. As soon as possible I'll test on an new ASUS M2N-E board with an nForce 570 chipset.
Fritz
Quote from: Cristiano Guadagnino on 2007.07.24, 10:50:53
I had the same symptoms: the driver loaded OK but it didn't work.
It was nickk who pointed me to the ACPI problem,
I think, I've fixed the problem in ACPI's OEMHLP. I also suggested a workaround to Nickk,
so this will be solved in the upcomming versions of both ACPI and NVETH.
Quote from: rudi on 2007.07.28, 11:02:19
Quote from: Cristiano Guadagnino on 2007.07.24, 10:50:53
I had the same symptoms: the driver loaded OK but it didn't work.
It was nickk who pointed me to the ACPI problem,
I think, I've fixed the problem in ACPI's OEMHLP. I also suggested a workaround to Nickk,
so this will be solved in the upcomming versions of both ACPI and NVETH.
I can confirm that the latest ACPI (not publically available yet) fixed my problems with nveth - so I'm also in favour of awarding the bounty to Nickk.
Ok, I removed my last message as it is now working perfectly.
It seems the debug version killed itself when to much data hat to be transfered over the COM port.
The non debug version works perfectly!
Quote from: fho on 2007.07.25, 17:47:35
Hi
I just downloaded nveth-0.0.1.zip and installed it on an ASUS A7N8X-E Motherboard. This has 2 NICs: the upper is an MCT-T from the nForce 2 chipset (10DE:0066), the lower is an Marwell 88E001 Gigabit NIC (11AB:4320).
Both are working with GenMac 2.0. The nForce 2 also works fine with the nveth-0.0.1. As soon as possible I'll test on an new ASUS M2N-E board with an nForce 570 chipset.
Hi all,
has anybody tested the driver with a nForce 570 chipset (10DE:0373)? I tried to install the driver from Hobbes, but I get this error in LANTRAN.LOG:
PRO0021: A general failure occurred when the program tried to bind TCPIP_NIF to NVETH_NIF.
and this seems to me an hardware error.
Bye and thanks
Gabriele
NVETH 0.0.2 version on hobbes. Sources included
Any comments about version 0.0.2 ?
The source code is now included on the driver.
Let us know that is working to close the bounty.
Quote from: miturbide on 2007.08.10, 05:20:54
Any comments about version 0.0.2 ?
The source code is now included on the driver.
Let us know that is working to close the bounty.
Works great for me!
Quote from: miturbide on 2007.08.10, 05:20:54
Any comments about version 0.0.2 ?
The source code is now included on the driver.
Let us know that is working to close the bounty.
Works here without problems (Asus A7N8X-X Nforce2 400).
rbri
Works here as well on my nForce1 (10de:01c3).
Version 0.0.3 is on hobbes.
I forgot to add promiscous mode support, so the VPC virtual switch, which relies on promisc mode to run, didnt work well.
Now it is done and i have one positive feedback on it. If anyone else use VPC with virtual switch, please test new driver and let me know if its ok.
Nick,
Could you explain what the different switches are good for?
Sounds like that the latest version of the drivers works fine and Nickk has made a claim for the bounty; if everything works as it should I think it should be ok to pay out the bounty. Guess that we'll give a couple of days more before the final close.
Works fine here with TCPIP and Netbios over TCPIP and an NVidia MCP55. Great work, thank you Nickk!
Bye
Gabriele
Works fine here. The LAN adapter has TCP/IP, TCPBEUI, and NETBEUI bounds to it, but I haven't been able to test anything but TCP/IP.
One thing that is sorely missing is documentation. What the heck are the switches for exactly and when should one use them?
Quote from: kimhav on 2007.08.20, 10:45:29
Sounds like that the latest version of the drivers works fine and Nickk has made a claim for the bounty; if everything works as it should I think it should be ok to pay out the bounty. Guess that we'll give a couple of days more before the final close.
Hi Kim
I've only switched from GenMAC V2 to this driver a few days ago and it seems to be working fine with my nForce4 onboard nic.
Thanks to Nickk for all his hard work - but I think maybe you should get the documentation updated before paying the bounty :-)
Regards
Pete
Assume that Nickk is reading this thread and I agree that it would be nice to at least to an answer to the switches.
The switches for nveth are documented in nveth.inf file. Here follows some explanations thus people become wondering ;)
MODE switch - i think the nif file gives complete explanations - its the speed to work on
OPTIMIZE - there are two modes of driver work - with throughput optimization and without, this optimization is just a strategy of interrupt processing. It came from forcedeth linux sources and you can study the sources for yourself for more info. I do not have the hardware to test the driver, so its you to try which setting suits best for you.
TIMER - nvidia adapter has special interrupt driven by its internal timer. This switch switches on and off enabling of this interrupt. Switching off will reduce the number of interrupts generating by the driver thus lowering system load, but it also could increase the latency in processing the rx/tx queues. Its up to you to find out whats is the best for you ;)
LINK_TIMER - if on driver periodically queries HW chip for the actual link speed and resetup the chip according to it.
RXCHAIN - the os/2 ndis drivers has two methods to pass received data to the protocol (tcpip and others) - receive chain and receive lookahead. The first one should be better. This option was introduced for testing reasons, now driver seems to work fine in both ways, so you can safely leave the switch as is.
The general recomendation - turn the swicthes if only you got any problems.
The 0.0.4 version of nveth driver at hobbes. It includes detailed switches explanations ;)
Hi all,
what's up here? Did we pay the money to nickk or not?
Is there something that needs to be done before we can reward nickk for his efforts?
Thanks for letting me know... cheers,
Thomas
Hi all.
Well, I happen to talk to Roderick on the phone and we somehow ended up discussing networking things and then I took the chance to ask him what he thinks of nickk's port. He said that besides very, very rare cases, the vast majority of nVidia chipsets are supported by nickks driver/port as far as he can judge from the bugtrackers and boards... well.
I repeat the question:
Is there any objection to the idea of making nickk get the bounty paid?
This might also positively impact on his motivation to do more or continue to support the drivers since I assume nVidia will not cease creating new chipsets in the near future :)
Q1: Was there an official "claim" of the bounty by nickk?
Q2: Is there anything that needs to happen in matters of doc/license?
Q3: Am I the only one to read this thread? :)
@nickk:
In case you read this, please drop a comment to tell me if you have approached os2world's bounty manager ot claim the money or not... this will help me in understanding the status quo of this bounty. Thank you!
Cheers,
Thomas
Hi Thomas
I seem to have been using nveth since 0.0.3 without problems on 3 systems here and am currently using 0.0.6 happily - if that helps clarify whether nickk should be paid the bounty.
Regards
Pete
Pete, he already has the money ;) The driver works in a nice way and maybe he should get another favor :)
I reported a minor bug to Nick what goes wrong if you have a dual Nvidia NIC.
The drivers second instance is looking for nvidia1$. But the IBM standard is that a second instance is called
nvidia2$. He is aware of this and told me he would release a new build.
Other then that the driver seems to work on most of the chipsets. Seems to have a working rate of over 90%...
(About 10 people in total tested the NIC on different Nvidia NIC chipsets).
Roderick Klein
Mensys