X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-Id: <5.1.0.14.0.20020301080427.009ec730@mail.dfsi.net> X-Sender: impala AT mail DOT dfsi DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Mar 2002 08:06:00 -0600 To: opendos AT delorie DOT com From: Dr Who? Subject: Re: Problems with DRDOS 7.03 In-Reply-To: <000001c1c10d$22595520$c03dfea9@atlantis> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g21E5fU01689 Reply-To: opendos AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: opendos AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk hmmm vellie strange but vellie inkstrinking nice move om! At 03:07 PM 2/28/02 +0100, you wrote: >On 2002-02-27, Joe Smith wrote: > >Thanks for posting your configuration data here. Although >the CONFIG.SYS looks harmless at the first glance, there >are many strange things happening here. Letīs have a look >at the memory listing first: > > > 70:016E ?:-B: Built-in device driver > >This is unusual, the first drive letter should be A: and the >last one should be the last one of your hard disk, depending >on how many volumes you have. > >Thereīs definitely something going seriously wrong here, but >right now, Iīm not sure what it is - weīll have to try out >a few things to track this down. > > > 100:006D DR DOS 200h, 512 1 Disk buffers > >[...] > > 9FFF:0000 DR DOS 28010h, 163,856 System > > > > A858:AA6C DR DOS 200h, 512 1 Disk buffers > >[...] > > FFFF:A430 DR DOS 200h, 512 1 Disk buffers > >This is very unusual as well. You specified four buffers in >CONFIG.SYS, but I can only find three in your MEM /A output. > >Also, the buffers should be either in the HMA, or in UMBs, >or in conventional memory, depending on where you load >the kernel. One buffer may remain in conventional memory, >but this is not listed as such by MEM. It is very unusual >to have buffers in both, the HMA and this "some strange kind >of" UMB at the same time... >The third strange thing is, that the buffer at A858h:AA6Ch >is in the middle of the video memory range; if this buffer >would be actually used by the system, it would be a direct >trip into the desaster area, probably causing a crash or >corrupted data on the disk. In particular when you fire up >programs which use an EGA or VGA video adapter - and the >Norton Utilities certainly do this. > >I can see no reason, how the buffer could be placed there, >your configuration of EMM386.EXE does not give any indication >that you forced some UMB memory to be in the video memory >address range (which /is/ possible when only text only applications >are used, but it requires a special setup, either with /VIDEO >or with /USE depending on if you want to use that memory as >part of an extended TPA (Transient Program Area) with MEMMAX +V >or as UMB memory). > > > 35C:0000 COMMAND 810h, 2,064 Environment > > > > 3DD:0000 COMMAND 140h, 320 Data > > > > 3F1:0000 COMMAND 150h, 336 Data > > > > 406:0000 COMMAND F0h, 240 Data > > > > 415:0000 COMMAND 1F0h, 496 Program > > > > 434:0000 COMMAND 810h, 2,064 Environment > >[...] > > CD17:0000 COMMAND 2090h, 8,336 Data > >[...] > > FFFF:00E0 COMMAND 2080h, 8,320 Program > >Very unusual as well, COMMAND.COM does not normally use a >8 Kb data area. To me this looks as if you had two copies >of COMMAND.COM running, when you took this MEM snapshot... >Have you shelled out from a program to a secondary command >shell when you issued the MEM /A? > > > E800:0000 EMS 10000h, 65,536 ---------- EMS memory > > > > FD00:0000 -------- 1000h, 4,096 ---------- Shadow ROM > >The page frame at E800h is a special setup (/FRAME=E800 /USE=F000- >F7FF), which will work in most cases, but you should avoid it, >as long as you still have enough free UMB memory. Also the small >Shadow ROM area in between the remaining F800h-FFFFh ROM BIOS area >is a little bit odd. > >Finally, I did not found the BIOS and BDOS kernel areas and some >other DOS structures listed anywhere in the listing, either the >system or MEM must have been totally confused... > >Well, having a look at your CONFIG.SYS file I could find a >few oddities there as well, and one of the settings probably >causes this odd behaviour. I already have a few suspicions, >but to address the problem properly, I will need to know more >details about your system first: > >Which exact version of DR-DOS are you booting? Toggle Scrollock >on before the "Starting DR-DOS..." message is shown. The kernel >will then display some additional internal build info at startup. >Just to make it sure, you are not using some patched issues >of the kernel? And you are not mixing kernel files from different >versions, just the normal files from the offical distribution? > >I could also need a listing of the system files in the root >of drive C:\ so check the file sizes and date stamps, for example >created by issueing a DIR c:\*.* /S or /AS. > >The cause of the problem could also be located in AUTOEXEC.BAT, >could you post this file as well, please? > >Finally, can you describe your system in better details? >Do you know the brand and model of the mainboard, the manufacturer >of the chipset on the mainboard? Is this an Intel CPU or >a compatible one? What brand, version, and date is the ROM-BIOS >and the Video BIOS? What kind of video card do you have installed >in your system? Is there anything special with that machine, >say, is it a mobile system, an industry device, or an embedded >PC? Probably not, but if so, this info might be useful to know >as well. > >Well, now to your CONFIG.SYS file. There are a several unusual >things in there, but only few actual mistakes. > >I would like to track down what exactly caused this strange >MEM output, so we better do not change too many things at the >same time. Otherwise we may solve the problem, but still donīt >know what has actually caused it... ;-) > > > DEVICE=C:\DRDOS\EMM386.EXE DPMI=OFF FRAME=E800 USE=E800-F7FF AUTO > > MULTI=OFF ROM=AUTO > >Please remove the FRAME=E800 and USE=E800-F7FF and replace this >simply by FRAME=AUTO for now. Also remove the ROM=AUTO and AUTO >switches for testage: > >DEVICE=c:\drdos\emm386.exe /DPMI=OFF /MULTI=OFF /FRAME=AUTO /VERBOSE=DEBUG > > > DEVICE=C:\DRDOS\DPMS.EXE > > DEVICEHIGH=C:\DRDOS\NWCACHE.EXE /E 7680 1024 /LEND=ON /DELAY=5000 /FLUSH=ON > > /BE=16 /CHECK > >Well, if you want to use DPMS via XMS, you must not force NWCACHE to >use EMS memory. NWCACHE will have a larger DOS memory footprint when >using DPMS, but using DPMS will dramatically increase the performance. >So change this line to: > >DEVICEHIGH=c:\drdos\nwcache.exe 7680 1024 /MUX /LEND=ON /DELAY=5000 > /FLUSH=ON /BU=16 /CHECK > > > DEVICEHIGH=C:\DRDOS\VDISK.SYS 2000 /X > > SHELL=C:\COMMAND.COM C:\/P:AUTOEXEC.BAT /E:2048 /MH > >This is not error, but it is safer to use the COMMAND.COM in >the DR-DOS directory. So copy (not move) the command.com from >the root into c:\drdos\ (if it is not already there) and change >this line to: > >SHELL=c:\drdos\command.com c:\drdos\ /E:2048 /MH /P:autoexec.bat > >The /P parameter must always be the last parameter for compatibility >with some programs. You probably donīt need 2 Kb of environment >space, /E:512 will be sufficient in most cases, but optimization >comes after trouble-shooting... > > > DOS=UMB,HIGH > >Change this into > >DOS=HIGH,UMB > > > FILES=20 > > BUFFERS=4 > > FASTOPEN=0 > > FCBS=4,4 > > FASTOPEN=0 > >You can remove the second FASTOPEN=0 here. > > > BREAK=ON > > HISTORY=ON,256,ON, OFF, OFF > > VERIFY=OFF > > LASTDRIVE=Z > > COUNTRY=044,,C:\DRDOS\COUNTRY.SYS > >Change this to: > >COUNTRY=44,437,c:\drdos\country.sys > > > INSTALLHIGH=c:\drivers\mouse\ctmouse.com > >Which version of CTMOUSE are you using? > >OK, some of the changes are experimental only, and there are >a few more settings, which I did not change in this round, >because I want to track down the actual cause of the problem. > >Can you post your remaining configuration files and a MEM /A >after applying these changes? Thanks. > >Greetings, > > Matthias > >-- >; >http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org