Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
At 01:08 AM 7/31/2005 +0100, Gerry Hickman wrote: Oh good grief. EMM386 doesn't have the code or capability to mess with disk partitions. Period. But if drive geometry is being misreported or misunderstood under EMM386 with VDS (which appears to be the case), then my guess is that it would be dangerous to run any kind of disk tool while the system is in that state? Even writing a file to a disk could cause corruption. In the same way that a keyboard driver could be dangerous to run with a disk tool if there were a bug in it, or if it caused a normally hidden bug in the disk tool to activate. DOS system code is wide open to corruption from any driver or application, a situation generally regarded as one of its biggest faults. Without a system which displays the symptoms -- which I don't have -- it's almost impossible for me to say what's going on. Likeliest candidate for causing the problem is that there is still a conflict with some SCSI interfaces and an active VDS (4bh) interrupt. We know that at least one SCSI spec directly conflicted with VDS. However, other candidates cannot be ruled out, or even marginalized. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
Hi Michael, My main point was that the FDISK bug may have been _triggered_ by EMM386 with VDS, and that if he hadn't been running EMM386 his FDISK tests would not have caused a bad partition table. You were saying this: Oh good grief. EMM386 doesn't have the code or capability to mess with disk partitions. Period. Hehe, so who knows:) Anyway, regarding the VDS and SCSI tests, I posted my findings and SysConfig earlier in this thread, and can also test the new EMM386 to see if there's any change. -- Gerry Hickman (London UK) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] BIOS, SCSI, 8Gb and TUNS
Hi, I tried some rough tests today with BIOS, SCSI and TUNS. Here's are some results. In an eariler post I said I'd seen drive sizes reported as 8Gb with SCSI when the drives are actually much bigger. I thought it was related to not using a SCSI driver and BIOS (INT13) reporting wrong size, and Eric said it wasn't. I think Eric is right, but my BIOS has been updated since I last seen this problem, so it's impossible to say what caused it. I tested today, FreeDOS Beta9 SR1, but with updated HIMEM and EMM386, two physical SCSI drives of 36Gb each on Adaptec 29160N controller. SCSI BIOS has both INT13 support enabled, and also INT13 support for drives larger than 1Gb enabled. Asus AV333 motherboard, AMD Athlon 2100+ Test1 (this is really two tests): Load FreeDOS with HIMEM only; first WITH SCSI driver, then WITHOUT SCSI driver. Result1: Drive size is reported correctly in both FDISK and PQMAGIC in both cases. However, enter EMM386 and ALL BETS ARE OFF! I mean total meltdown, with both FDISK and PQMAGIC saying the drives were not partitioned and giving totally crazy readings for disk sizes. The EMM386 line was this: DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose When I tried to load my SCSI driver after EMM386 and it just hung. I then tested all the above with UMBPCI and everything worked perfectly. Testing TUNS: I now had a stable system, so decided to test loading LBACACHE high, both with and without TUNS. If I don't have UMBPCI loaded, it's a bit silly because LBACACHE won't load high, and I don't know if TUNS makes any difference. Output was as follows: DISK 0X80 HEADS 0255 SECTORS 0063 DISK 0X81 HEADS 0255 SECTORS 0063 [DONE] I then tested with UMBPCI loaded, and told LBACACHE to INSTALLhigh without TUNS, it did exactly as it was told (checked mem /c /p), and there were no timeouts. It gave the exact same output DISK 0X80 HEADS 0255 SECTORS 0063 DISK 0X81 HEADS 0255 SECTORS 0063 [DONE] Here is my FDConfig.SYS file: ;device=special\fdxms.sys DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X ;DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose device=other\umbpci.sys rem Load the SCSI for 29160N card ;device=other\aspi8u2.sys /d rem UDMA hard drives ;DEVICE=DRIVER\UDMA2.SYS DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e ;devicehigh=OTHER\ifshlp.sys rem lbacache tuns switch is needed for SCSI and UMBPCI INSTALLhigh=DRIVER\LBACACHE.COM SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT DOSDATA=UMB DOS=high,UMB FILES=20 BUFFERS=20 LASTDRIVE=Z -- Gerry Hickman (London UK) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
Gerry Hickman wrote: In an eariler post I said I'd seen drive sizes reported as 8Gb with SCSI when the drives are actually much bigger. I thought it was related to not using a SCSI driver and BIOS (INT13) reporting wrong size, and Eric said it wasn't. I think Eric is right, but my BIOS has been updated since I last seen this problem, so it's impossible to say what caused it. After further reading, it seems this kind of thing was originally more of a problem with IDE/ATAPI drives, as opposed to SCSI. Here's an extract from a page talking about INT13: http://www.fixup.net/tips/20gb/20gb.htm --- start here --- Technical Explanation In PC, hard drive is accessed via BIOS Interrupt 13 calls. Old Int13 routines has limit for 500MB, 8GB or 30GB drives. An extension to Int13 has been added to newer BIOS to eliminate the limit. Therefore, newer BIOS has no this limit. For old BIOS, an overlay program, such as MaxBlast II, can be used to load this extension before OS loading, so the Int13 calls are translated into extension calls. Old OSs, including DOS, Win3.xx and NT, were not aware of this extension and therefore always need an overlay program to use large hard drives . Newer OSs, including Linux and Win95/98/Me/2000/XP, are aware of the extension and do not rely on an overlay to access hard drive after OS loading. Therefore, performance and reliability of an overlay program is not an issue once these OSs are started. However, they do matter during OS loading and unloading and that's why some overlay programs (such as IBM DM) cause trouble during standby and hibernation. --- end here --- -- Gerry Hickman (London UK) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
Hi Gerry: Ah, yes, ... :-) Try emm386 without the VDS argument and under no circumstances run FreeDOS FDISK unless you want to risk an erased partition table. Thanks for reporting this. Let us know what happens without the VDS argument to EMM386! Mark Hi, I tried some rough tests today with BIOS, SCSI and TUNS. Here's are some results. In an eariler post I said I'd seen drive sizes reported as 8Gb with SCSI when the drives are actually much bigger. I thought it was related to not using a SCSI driver and BIOS (INT13) reporting wrong size, and Eric said it wasn't. I think Eric is right, but my BIOS has been updated since I last seen this problem, so it's impossible to say what caused it. I tested today, FreeDOS Beta9 SR1, but with updated HIMEM and EMM386, two physical SCSI drives of 36Gb each on Adaptec 29160N controller. SCSI BIOS has both INT13 support enabled, and also INT13 support for drives larger than 1Gb enabled. Asus AV333 motherboard, AMD Athlon 2100+ Test1 (this is really two tests): Load FreeDOS with HIMEM only; first WITH SCSI driver, then WITHOUT SCSI driver. Result1: Drive size is reported correctly in both FDISK and PQMAGIC in both cases. However, enter EMM386 and ALL BETS ARE OFF! I mean total meltdown, with both FDISK and PQMAGIC saying the drives were not partitioned and giving totally crazy readings for disk sizes. The EMM386 line was this: DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose When I tried to load my SCSI driver after EMM386 and it just hung. I then tested all the above with UMBPCI and everything worked perfectly. Testing TUNS: I now had a stable system, so decided to test loading LBACACHE high, both with and without TUNS. If I don't have UMBPCI loaded, it's a bit silly because LBACACHE won't load high, and I don't know if TUNS makes any difference. Output was as follows: DISK 0X80 HEADS 0255 SECTORS 0063 DISK 0X81 HEADS 0255 SECTORS 0063 [DONE] I then tested with UMBPCI loaded, and told LBACACHE to INSTALLhigh without TUNS, it did exactly as it was told (checked mem /c /p), and there were no timeouts. It gave the exact same output DISK 0X80 HEADS 0255 SECTORS 0063 DISK 0X81 HEADS 0255 SECTORS 0063 [DONE] Here is my FDConfig.SYS file: ;device=special\fdxms.sys DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X ;DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose device=other\umbpci.sys rem Load the SCSI for 29160N card ;device=other\aspi8u2.sys /d rem UDMA hard drives ;DEVICE=DRIVER\UDMA2.SYS DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e ;devicehigh=OTHER\ifshlp.sys rem lbacache tuns switch is needed for SCSI and UMBPCI INSTALLhigh=DRIVER\LBACACHE.COM SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT DOSDATA=UMB DOS=high,UMB FILES=20 BUFFERS=20 LASTDRIVE=Z -- Gerry Hickman (London UK) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
Hi Gerry: Yes, I was running emm386. However, FDISK erased my (and at least one other) partition table without any prompt or request at all when only requested to examine the table. It's too risky to run the program at all until that bug is addressed (IMHO). I believe there is a development version floating around with that fix. It is PROBABLY fairly safe to run it without EMM386, but I do not believe it is worth the risk. There are other tools to examine and manipulate disk partitions that won't destroy the partition table when they have been only asked to examine it. Mark Hi Mark Ah, yes, ... :-) Try emm386 without the VDS argument and under no circumstances run FreeDOS FDISK unless you want to risk an erased partition table. Can you clarify; when your partition table became damaged, were you running EMM386 at the time, and have you tried it without? Maybe you already answered this. -- Gerry Hickman (London UK) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
Ah, yes, ... :-) Try emm386 without the VDS argument
and under no circumstances run FreeDOS FDISK unless
you want to risk an erased partition table.
OK I ran the tests again, after taking out VDS everything is working
normally, FDISK /INFO reports the correct partition sizes and luckily my
computer still works (I'm typing this message on it).
Regarding LBACACHE TUNS, it's exactly the same as under UMBPCI, it's
loads high with no problems and no timeouts. Below is the memory map and
the FDCONFIG.SYS
Modules using memory below 1 MB:
Name Total Conventional Upper Memory
SYSTEM 14,928 (15K) 9,696(9K) 5,232(5K)
HIMEM2,544(2K) 2,544(2K) 0(0K)
EMM386 3,360(3K) 3,360(3K) 0(0K)
COMMAND 3,984(4K) 2,944(3K) 1,040(1K)
KEYB 1,760(2K) 1,760(2K) 0(0K)
SHSUCDX 5,808(6K) 5,808(6K) 0(0K)
VIDE-CDD 5,024(5K) 0(0K) 5,024(5K)
RAMDRIVE 1,392(1K) 0(0K) 1,392(1K)
LBACACHE 7,360(7K) 0(0K) 7,360(7K)
DISPLAY 11,648 (11K) 0(0K) 11,648 (11K)
CTMOUSE 3,328(3K) 0(0K) 3,328(3K)
Free 714,896 (698K)627,008 (612K) 87,888 (86K)
Memory TypeTotal Used Free
Conventional 638K26K 612K
Upper 120K34K86K
Reserved 266K 266K 0K
Extended (XMS)261,104K 202,303K58,801K
Total memory 262,128K 202,629K59,499K
Total under 1 MB 758K60K 698K
Largest executable program size 612K (626,720 bytes)
Largest free upper memory block86K ( 87,616 bytes)
FreeDOS is resident in the high memory area.
-- FDCONFIG.SYS STARTS HERE --
;device=special\fdxms.sys
DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X
; rem removed VDS from line below
DEVICE=SPECIAL\EMM386.EXE NOEMS X=TEST /verbose
; rem UMBPCI found to be more stable on every system tested
;device=other\umbpci.sys
rem Load the SCSI for 29160N card
;device=other\aspi8u2.sys /d
rem UDMA hard drives
;DEVICE=DRIVER\UDMA2.SYS
DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD
devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e
;devicehigh=OTHER\ifshlp.sys
rem lbacache tuns switch is needed for SCSI and UMBPCI
INSTALLhigh=DRIVER\LBACACHE.COM
SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT
DOSDATA=UMB
DOS=high,UMB
FILES=20
BUFFERS=20
LASTDRIVE=Z
--
Gerry Hickman (London UK)
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
At 08:23 PM 7/30/2005 +0100, Gerry Hickman wrote: Ah, yes, ... :-) Try emm386 without the VDS argument and under no circumstances run FreeDOS FDISK unless you want to risk an erased partition table. Can you clarify; when your partition table became damaged, were you running EMM386 at the time, and have you tried it without? Maybe you already answered this. Oh good grief. EMM386 doesn't have the code or capability to mess with disk partitions. Period. FDISK was broken in its default behaviors, which allowed a simple problem to escalate to meltdown. This was documented and verified, and is being fixed by another FreeDOS developer. Enough of this sort of thing. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
Hi Michael, Can you clarify; when your partition table became damaged, were you running EMM386 at the time, and have you tried it without? Oh good grief. EMM386 doesn't have the code or capability to mess with disk partitions. Period. But if drive geometry is being misreported or misunderstood under EMM386 with VDS (which appears to be the case), then my guess is that it would be dangerous to run any kind of disk tool while the system is in that state? Even writing a file to a disk could cause corruption. -- Gerry Hickman (London UK) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
On Sat, 30 Jul 2005 17:43:04 +0100, you wrote: Hi Gerry, Old OSs, including DOS, Win3.xx and NT, were not aware of this extension and therefore always need an overlay program to use large hard drives . That means Win98 FDISK ignore the INT13 extension. Thanks for the information. Rgds, Johnson. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
