X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f Message-ID: From: "da Silva, Joe" To: "'opendos'" Subject: RE: NE2000 driver, DPMS (was: PNW, etc.) Date: Tue, 1 Feb 2005 10:54:26 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id j0VNo3lV010515 Reply-To: opendos AT delorie DOT com Please see below ... Joe. > -----Original Message----- > From: Michal H. Tyc [SMTP:mht AT bttr-software DOT de] > Sent: Saturday, January 29, 2005 6:06 AM > To: opendos AT delorie DOT com > Subject: Re: PNW vs NetWare (and NE2000 drivers, Client32) > > So, it seems there is a bug (actually, two bugs, as you > > will see) with the VLM ODI NE2000 driver. It performs > > some sort of test to check if the network is correctly > > terminated, but then misinterprets this as a hardware > > configuration conflict. Furthermore (and this is the second > > bug I alluded to), it then neglects to restore the interrupt > > vector for the card's IRQ, even though it isn't loading. As > > a result, attaching a cable or terminating resistor to the > > card's BNC connector will subsequently invoke a call to > > this interrupt vector, resulting in a hung PC - nasty! > > Interesting... I'm using an NE2000 clone (Genius IIRC) in one > machine and it was happening from time to time that the cabling > was broken somewhere outside my room, or that I had to disconnect > the cable to use it with another machine. The driver loaded and > I didn't experience any problems of this kind, just observed > a noticeable delay during startup. > [Joe da Silva] Interesting indeed. Well, since my original posting, I've acquired a NE2000 clone (no brand name, model no. or FCC ID, so no way to find configuration software for it;-). Although you didn't say explicitly, I presumed you tried the V2.10 driver, as supplied with DR-DOS 7.XX PNW (as you will recall, the older V1.XX driver didn't exhibit the above problem). So, I did a quick check last night with the NE2000 clone and the V2.10 driver - no "hardware configuration conflict" error with the network disconnected! It seems this problem only occurs with an original Novell NE2000 card, not with clones (well, at least, not with this or your clone card). It appears Novell either never tested the driver with an original NE2000 card or didn't try it with the network disconnected (to ensure the driver didn't misbehave as above). From a bit more experimentation, my theory is that the V2.10 driver performs some sort of test to see if the IRQ setting of the card is correct. An original NE2000 card doesn't seem to generate an interrupt if unconnected to a network (ie. unterminated), so the driver assumes the IRQ is wrong. It then fails to restore the interrupt vector. > -----Original Message----- > From: Michal H. Tyc [SMTP:mht AT bttr-software DOT de] > Sent: Saturday, January 29, 2005 6:05 AM > To: opendos AT delorie DOT com > Subject: Re: protman.dos and DR DOS > > Of the various components used in PNW, only the server component > > seems to make use of DPMS, so if you aren't using DPMS with > > any other driver/TSR, don't bother loading it for a client-only boot. > > NWCACHE and NWCDEX are the most commonly used DPMS clients. > [Joe da Silva] Yes, although since Novell created DPMS, it's a shame they didn't use it more extensively with their VLM/ODI stuff, which would certainly have benefited from it. NWCACHE and NWCDEX are indeed the main DPMS clients, but if you need EMS for other applications anyway, you have the option to use this for them instead of DPMS. ------------------------------------------------------------------------------------------------------- This email (including any attachment) is confidential. If you are not the intended recipient, you must not disclose or use this email or the information contained herein for any purpose. If you have received this email in error, please immediately advise us by reply and delete this email. This email may not be altered, forwarded or re-issued without our consent. AMPY Email Metering is not responsible for any changes made to this email or the effect of any changes on the email’s meaning. It is the responsibility of the recipient to scan this email for viruses and faults prior to processing. AMPY Email Metering shall not be liable for any loss or damage caused by this email from transmission, viruses, faults or the use of data accompanying this message. AMPY Email Metering reserves all its rights, including copyright,in this email.