Re: [Freedos-user] FreeDOS FDISK another partition problem
On Thu, 28 Jul 2005 19:56:40 +0100, you wrote: Hi Gerry, But you didn't tell it to write an MBR? FDISK should automatic update the MBR when quit (or I'm wrong?) OK, but if there was no MBR, this may not create one. That's what my earlier post was all about. Can you try this (all data will be lost) 1. Boot FreeDOS on a floppy (or whatever) Make sure FDISK is 1.3.x or above 2. FDISK /CLEARALL 1 Ha ha ... some days ago I've tried already ... failed. After the MS-DOS FDISK, I feel strange that only 8GB (Eric explained it's cause by CHS), okay ... try again with FreeDOS ... this time works! (that's a number one assuming your physical drive number is one) 3. FDISK /MBR Also tried. 4. FDISK /PRI:2000 What is it? After it works, I can't fail it again (or I can try break and rebuild the RAID), next week I'll try again. 5. Reboot it 6. FORMAT C: /S 7. Reboot it again What happens now? Please wait a few days, I'll try it Monday afternoon. Yes, that's what I'm thinking. The problems will arise when you can't do multi-tasking and multi-threading, and utilizing full power of load balancing on dual XEON:( yeah ... Dual CPU will have problem, wasting one of the CPU. Too bad there's no more Desqview I love it. Rgds, Johnson. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
Hi Michael: Well, what's trying to use it is the FreeCOM VOL command! (Or something else in FreeCOM). I doubt that there are any explicit calls to VDS functions there. The kernel may be more likely. This appears to be the same bug that caused FDISK to wipe out the MBR, so it at least appears that just initializing the VDS functions is trashing something in memory. I could ship you this laptop if you believe that will help or I can run any test routines you can think of! Mark Bailey At 11:53 PM 7/28/2005 +, Mark wrote: Do I need VDS? :-) What does it do? How can I help identify the problem? I do have the Haunted HP Pavilion (TM)! Turn it off if everything works without it. It's just for upper memory reporting of true physical address instead of logical address for DMA purposes. Maybe something is trying to use a function that isn't supported or ignoring a return code that a sub-function is not supported. You don't see any feedback messages when it's present do you? VDS will write to display a line about unsupported functions, but can't help if a program tries to use a subfunction that returns an unsupported code. Without the machine that croaks, though, not much chance I can tell you what's going on with the VDS problem. Could be the fault of either VDS support, or what's trying to use VDS. And no way of knowing here what or how to fix/work around it. I was going to make VDS a default, maybe I shouldn't. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 10:13 AM 7/29/2005 +, Mark Bailey wrote: This appears to be the same bug that caused FDISK to wipe out the MBR, so it at least appears that just initializing the VDS functions is trashing something in memory. No such thing. VDS functions just are, they don't initialize. Only thing that VDS actively changes is that INT 4Bh is revectored and a bit is set at 40:7bh. Ha! That's it. Some SCSI BIOS uses INT 4BH. It must be passing the register value that VDS interprets as a VDS function, which means AH = 81h. Hmm, let me look things over to see if there's a way to resolve the conflict by further determining the difference or if it's inherently incompatible. --- 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] VOL Command hangs HP Pavilion with EMM386
At 12:42 PM 7/29/2005 -0500, I wrote: Ha! That's it. Some SCSI BIOS uses INT 4BH. It must be passing the register value that VDS interprets as a VDS function, which means AH = 81h. Hmm, let me look things over to see if there's a way to resolve the conflict by further determining the difference or if it's inherently incompatible. Okay, this looks like the smoking gun. Now to figure out a workaround: INT 4B - Common Access Method SCSI interface (draft revision 1.9) ES:DI - CAM Control Block (see #03229 at INT 4F/AX=8100h) InstallCheck: test for the string SCSI_CAM eight bytes past the INT 4Bh handler Notes: the CAM committee moved the interface to INT 4F after revision 1.9 to avoid conflicting with the IBM SCSI interface and the Virtual DMA specification the only driver to date reported to use the CAM interface on INT 4B instead of INT 4F is from Future Domain (which has drivers for CAM on either interrupt) INT 4F - Common Access Method SCSI interface rev 2.3 - SEND CCB TO XPT/SIM AX = 8100h ES:BX - CAM Control Block (CCB) (see #03229) Return: AH = status 00h successful 01h invalid CCB address (h:h) Note: the SCSI Interface Module (SIM) may complete the requested function --- 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] Important ... about FD-EMM386 VDS
Hi, Jack R. Ellis have message: - I have read all the comments on FD-User re: Mark Bailey's problem using the FD-EMM386 VDS parameter. I also noted Mike DeVore's reply, that using VDS only enables 32-bit physical addresses to be reported for upper-memory addresses, that he thought of making VDS a default, and he now wonders if this should NOT be so. First, any DMA device whose hardware uses physical 32-bit address values REQUIRES that its DOS driver is able to INITIALIZE its own internal addresses. The 32-bit address is found by a VDS lock on a given memory space. Thus, if ANY upper memory is active, a VDS lock and VDS unlock (in case drivers decide NOT to load!) MUST ALSO BE ACTIVE, or any driver/TSR loaded in upper memory may initialize itself IMPROPERLY and may CRASH!!! Second, EMM386/QEMM/386MAX/etc. WERE NOT cooked-up only to create upper memory! Windows 3.1 and other multi-task DOS environments switch from one task to another using an 80386 memory re-map, NOT a (slow) disk swap as some MISTAKENLY believe! Any active device drivers ought not be part of re-mapping, or system speed will suffer. Any active DMA buffers MUST NOT be re-mapped, or the system can CRASH! To avoid buffer re-mapping, DMA drivers use a VDS lock on user buffers before DMA begins and use a VDS unlock on user buffers after DMA ends. This ALSO requires that VDS lock and VDS unlock calls MUST BE IMPLEMENTED when needed i.e. whenever ANY upper memory is used! I AM NOT saying this only on behalf of UDMA2! Other DMA drivers ARE ALSO written to follow Microsoft's unwritten RULES, in MS-DOS V4.49 EMM386 (on my MS-DOS V6.22) and likely in ALL MS-DOS EMM386 drivers DESPITE their documentation! These unwritten RULES are: A) If ANY upper-memory will be used when MS-DOS EMM386 loads, VDS calls are always ACTIVE! Thereafter, upper-memory and VDS calls can NEVER be DISABLED! B) If upper-memory WILL NOT be used when MS-DOS EMM386 loads, VDS calls are left INACTIVE! Thereafter, upper-memory and VDS calls can NEVER be ENABLED! As may be seen in the preceding two paragraphs, THERE ARE REASONS why MS-DOS EMM386 drivers run on such unwritten and STRICT rules! Ordinary users MUST NOT have control on the presence or absence of VDS lock/unlock calls, or CRASHES which those users CANNOT debug WILL HAPPEN! Say what-you-will of Microsoft; but they DID learn NOT to let ordinary users TRIP over their own appendages! As I noted to Jim Hall and Bernd Blaauw in an E-Mail during 2004, FD-EMM386 must implement the same rules as MS-DOS EMM386, QEMM or other available DOS Expanded Memory Managers! If not, FreeDOS can expect UDMA2 and all other DMA drivers written to Microsoft's [POORLY understood] standards sooner-or-later WILL CRASH!!! --- 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] VOL Command hangs HP Pavilion with EMM386
Hi Michael: Does this provide a means of easily identifying the affected machines? How do I check the Haunted HP Pavilion? :-) Mark Michael Devore wrote: At 12:42 PM 7/29/2005 -0500, I wrote: Ha! That's it. Some SCSI BIOS uses INT 4BH. It must be passing the register value that VDS interprets as a VDS function, which means AH = 81h. Hmm, let me look things over to see if there's a way to resolve the conflict by further determining the difference or if it's inherently incompatible. Okay, this looks like the smoking gun. Now to figure out a workaround: INT 4B - Common Access Method SCSI interface (draft revision 1.9) ES:DI - CAM Control Block (see #03229 at INT 4F/AX=8100h) InstallCheck: test for the string SCSI_CAM eight bytes past the INT 4Bh handler Notes: the CAM committee moved the interface to INT 4F after revision 1.9 to avoid conflicting with the IBM SCSI interface and the Virtual DMA specification the only driver to date reported to use the CAM interface on INT 4B instead of INT 4F is from Future Domain (which has drivers for CAM on either interrupt) INT 4F - Common Access Method SCSI interface rev 2.3 - SEND CCB TO XPT/SIM AX = 8100h ES:BX - CAM Control Block (CCB) (see #03229) Return: AH = status 00h successful 01h invalid CCB address (h:h) Note: the SCSI Interface Module (SIM) may complete the requested function --- 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] VOL Command hangs HP Pavilion with EMM386
At 02:58 PM 7/29/2005 -0400, Mark wrote: Does this provide a means of easily identifying the affected machines? How do I check the Haunted HP Pavilion? :-) Here's what to do: Go to ftp.devoresoftware.com/downloads/emm386 and download EMMBLORT.ZIP. Try that version of EMM386.EXE with your machine using VDS. I changed EMM386 to not report an error with function 0 on a VDS call. It's normally reserved and gives a VDS error condition, now it just chains it through with the carry flag set. Hopefully that won't upset things. Let me know if that fixes or modifies the current behavior with VDS parameter. (Oh yeah, lest it not be obvious, EMMBLORT is not an official release of EMM386. It is for testing purposes only.) --- 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] VOL Command hangs HP Pavilion with EMM386
Michael Devore schreef: Go to ftp.devoresoftware.com/downloads/emm386 and download Let me know if that fixes or modifies the current behavior with VDS parameter. no change in VMware Workstation 4.5.2 (PC emulator, Intel P4 processor) booting from BIOS directly to harddisk. Maybe a floppy would be better :) We're keeping this on the user-list or going to 'devel' list? scenario 1 (works) HIMEM EMM386.EXE (no VDS) scenario 2 (works) HIMEM UDMA2 EMM386 scenario 3 (fails, complains about missing SHELL) HIMEM EMM386.EXE VDS scenario 4 (works) HIMEM UDMA2 EMM386 VDS scenario 5 (fails at accessing C:\FDOS\BIN\UDMA2.SYS because that requires accessing the harddisk to retrieve the file): HIMEM EMM386 VDS UDMA2 What's still strange is that UDMA2 somehow sets the right conditions for EMM386's VDS parameter to work without any troubles. Bernd c:\config.sys: SWITCHES=/F/N COUNTRY=031,858,C:\FDOS\BIN\COUNTRY.SYS SET LANG=NL LASTDRIVE=Z BUFFERS=20 FILES=40 DOS=HIGH,UMB DOSDATA=UMB SET DIRCMD=/OGN /4 MENUCOLOR=7,0 MENUDEFAULT=1,5 MENU 1 - Load FreeDOS with maximum RAM free, using EMM386 MENU 2 - Load FreeDOS including HIMEM XMS-memory driver 12?DEVICE=C:\FDOS\BIN\HIMEM.EXE 1?DEVICE?=C:\FDOS\BIN\UDMA2.SYS 1?DEVICE?=C:\EMM386.EXE NOEMS X=TEST VDS 1?DEVICE?=C:\FDOS\BIN\UDMA2.SYS 12?SHELL=C:\COMMAND.COM C:\ /D /P=c:\autoexec.bat --- 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] VOL Command hangs HP Pavilion with EMM386
At 10:05 PM 7/29/2005 +0200, Bernd Blaauw wrote: Michael Devore schreef: Go to ftp.devoresoftware.com/downloads/emm386 and download Let me know if that fixes or modifies the current behavior with VDS parameter. no change in VMware Workstation 4.5.2 (PC emulator, Intel P4 processor) booting from BIOS directly to harddisk. Different issue entirely. Don't know what's going on in VMware, it may just not like VDS. --- 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] VOL Command hangs HP Pavilion with EMM386
Michael Devore schreef: Different issue entirely. Don't know what's going on in VMware, it may just not like VDS. very probably, yes, Michael. Mark, can you try loading UDMA2.SYS anyway (in front of EMM386)? DEVICE=HIMEM.EXE DEVICE=UDMA2.SYS DEVICE=EMM386.EXE VDS other_options if that works, then finally what happens for me in VMware isn't specifically a VMware bug :) for the record, the emulator uses a 'Phoenixbios 4.0 release 6'. wish I could load a proper Linuxbios bios imagefile, then see DOS fail miserably :) http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/udma/devel/Udma2_25.zip Bernd --- 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] FreeDOS FDISK another partition problem
Hi Johnson, Something doesn't add up here. As I understand it, we are ONLY trying to fix the problem of it not booting at this stage - is that right? The 8Gb thing is a different problem. Are you sure you followed the exact steps, in the exact order I listed? If you did, and it didn't boot, then this doesn't make sense to me. Johnson Lam wrote: On Thu, 28 Jul 2005 19:56:40 +0100, you wrote: Hi Gerry, But you didn't tell it to write an MBR? FDISK should automatic update the MBR when quit (or I'm wrong?) OK, but if there was no MBR, this may not create one. That's what my earlier post was all about. Can you try this (all data will be lost) 1. Boot FreeDOS on a floppy (or whatever) Make sure FDISK is 1.3.x or above 2. FDISK /CLEARALL 1 Ha ha ... some days ago I've tried already ... failed. After the MS-DOS FDISK, I feel strange that only 8GB (Eric explained it's cause by CHS), okay ... try again with FreeDOS ... this time works! (that's a number one assuming your physical drive number is one) 3. FDISK /MBR Also tried. 4. FDISK /PRI:2000 What is it? After it works, I can't fail it again (or I can try break and rebuild the RAID), next week I'll try again. 5. Reboot it 6. FORMAT C: /S 7. Reboot it again What happens now? Please wait a few days, I'll try it Monday afternoon. Yes, that's what I'm thinking. The problems will arise when you can't do multi-tasking and multi-threading, and utilizing full power of load balancing on dual XEON:( yeah ... Dual CPU will have problem, wasting one of the CPU. Too bad there's no more Desqview I love it. Rgds, Johnson. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- 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] re: FreeDOS FDISK another partition problem
Eric Auer wrote: 2. FDISK /CLEARALL 1 3. FDISK /MBR 4. FDISK /PRI:2000 That would be dangerous, I think. The bug report was just it does not boot after fdisk and sys, not I want to kill all my data. The solution FDISK /MBR will already be enough. He's testing on a new server, that's soon going to be rebuilt. I think this is a more concise series of steps. I made it clear in my post that all data will be lost. If you use a multitasking operating system, then the kernel controls the network drivers, and it will be able to give several programs at the same time access to the network, by managing connection queues and whatnot. That's the one! You explained it much better:) -- 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] re: FreeDOS FDISK issue with Windows Build
Hi Eric, previous o/s. To fix it requires changing attribs on BOOT.INI, editing it, then re-apply attribs... You could write a small batch script to automate that... I explained in an earlier post why that is not practical nor desirable. FreeDOS Beta9sr1: ... 4. reboot 5. FORMAT C: Did you verify that the reboot is needed? I know we recommend it, but you never know... Well probably do DO need it. Just wondering ;-). Yes! The reason is not really related to FreeDOS though. The reason is that when I first boot my hardware with FreeDOS CD, the hard drive either has no partitions at all, or only has NTFS partitions. This means that my RAMDISK ends up as C. If I create a partition on the first physical drive and then type FORMAT C:, it will try to format the RAMDRIVE! Rebooting fixes this, suddenly you get a FAT16/32 C: drive and your RAMDRIVE is on D: Default boot sector of FreeDOS FORMAT probably. Windows decides that this is not the default Windows or MS DOS boot sector, so it takes the safe route and assumes that anything other than Windows is another OS. Yes, why does Windows have to be so helpful! I would recommend two things: Use FAT32/LBA partition type, and format with FORMAT C: /A for easier conversion to NTFS. I'm already doing that, but note that the CONVERT.EXE program supplied with Windows 2000 cannot convert to NTFS on 4K boundaries, it FORCES 512b as I stated in my earlier post. This will also be a good test whether our FAT32 format is Windows compatible even for convert. It is, but you lose the 4K cluster size unless you use the updated CONVERT.EXE supplied with XP's deployment tools and I don't know if it can be hacked to work with Windows 2000. You could zap it, but you could try if running MS DOS SYS C: to put a MS DOS boot sector on the drive makes Windows behave more as intended Yes, but if I have to use MS-DOS it defeats the whole purpose of having a build environment that's both open-source and free from Microsoft. I do need to try FreeDOS SYS to see if it fixes the problem. It's a bit strange having to force an o/s onto a C: drive in order to get Windows to see it as NOT having an o/s:) (assuming that it will not suggest Windows users to boot MS DOS ;-)). Well, I guess our users could be given the option to boot into FreeDOS, but they'd start whining about not being able to run Outlook and Word:) the MS DOS boot sector. As MS DOS does not support FAT32, you can use Win98 DOS SYS instead. Yikes! The dreaded Win98! -- 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] re: New FreeDOS install CD
Hi, Eric Auer escribió: Could be used with software with restrictive licenses. Okay, I get it. Read: Antivirus stuff and VIDE-CDD. What else? By the way, Bernd just never got a reply from Acer about the driver, but they never said that you cannot put it on CD either. What is the license of ACRODOS, for those that have used it? Aitor --- 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] FreeDOS FDISK another partition problem
On Fri, 29 Jul 2005 23:00:50 +0100, you wrote: Hi Gerry, Something doesn't add up here. As I understand it, we are ONLY trying to fix the problem of it not booting at this stage - is that right? The 8Gb thing is a different problem. Yes. Are you sure you followed the exact steps, in the exact order I listed? If you did, and it didn't boot, then this doesn't make sense to me. I remember the procedure clearly, it's really doesn't make sense to me also. Luckily some parts not yet arrive and I can still spend some time to play with it, I'll break the RAID and try again, following your step. And see what happen. 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
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 03:07 AM 7/30/2005 +, Mark Bailey wrote: VOL C: works normally. Without device=a:\udma2.sys, vol c: hangs and forces a reboot. (That's the old behavior which I checked to make sure of the test case). This does not appear to be a seperate issue. Actually it muddies the waters by introducing another low-level driver into the test mix. I really need feedback on the test EMM386 without UDMA2 or something else in there. Basic clean room testing approach before expanding the universe. --- 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] VOL Command hangs HP Pavilion with EMM386
Hi Michael: OK, I have done so. The new version still reports version 2.04, July 6, 2005, but is much larger! I see no difference at all with that version, either with the development kernel/command.com or the stable kernel/ command.com. Specifically, with device=a:\himem.exe device=a:\emm386.exe x=test memcheck vds vol c: hangs. Remove vds, it works normally. (development) With stable kernel, I get screenfulls of garbage I can't read (no newlines) with VDS, normal operation without. UDMA2 still appears to fix it! I reported this before, but EMM386 reports the following: selected page frame e000 not available, searching automatically using PAGEFRAME e000: That looks a bit odd... Thanks very much for all of your help! Mark Bailey At 02:58 PM 7/29/2005 -0400, Mark wrote: Does this provide a means of easily identifying the affected machines? How do I check the Haunted HP Pavilion? :-) Here's what to do: Go to ftp.devoresoftware.com/downloads/emm386 and download EMMBLORT.ZIP. Try that version of EMM386.EXE with your machine using VDS. I changed EMM386 to not report an error with function 0 on a VDS call. It's normally reserved and gives a VDS error condition, now it just chains it through with the carry flag set. Hopefully that won't upset things. Let me know if that fixes or modifies the current behavior with VDS parameter. (Oh yeah, lest it not be obvious, EMMBLORT is not an official release of EMM386. It is for testing purposes only.) --- 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
