Re: [Freedos-devel] Re: Performance problem with FORMAT 0.91r
Well, this is embarrassing. I downgraded to 0.91o and it is no faster. I could have sworn it got slower when I upgraded to 0.91r... But maybe I am just crazy and it was never as fast as I remember. I apologize for the false alarm. - Pat --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
It sounds like you guys managed to figure this out (thanks, Tom!). Can I get a copy of a new kernel to try? When/where? Thanks! - Pat P.S. http://freedos.sourceforge.net/kernel/README.html is inaccessible. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
Erwin Veermans [EMAIL PROTECTED] writes: Wild guess: Did you try switches=/E in config.sys? Some people were reporting issues with latest kernel that could be reverted with the /E-switch. Browse this list for more info ... No effect. Also, this happens with both the 2.0.33 and 2.0.34 kernel releases. - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)
Johnson Lam [EMAIL PROTECTED] writes: You report faster than me. I got the same problem when trying MSCLIENT, it does work under FDXXMS+UMBPCI (try it), but fail with HIMEM+EMM386. I'm quite sure the memory manager and hardware not so compatible especially Network Interface Card. I tried it with *no* memory manager at all; no himem, no fdxms, no umbpci, no emm386... And I still get an illegal opcode fault. I just finished trying all combination including NOEMS, EMS, VDS ... still not working, and I'm better than you. The 3COM 3c905tx-b only fail to BIND and report hardware error. I can still access FreeDOS without hangup. This is with Intel PRO/1000 hardware, not 3com hardware. I strongly suspect you and I are seeing independent problems. - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
In the last major release of my project (http://unattended.sourceforge.net/), I changed my network boot disk to use FreeDOS instead of MS-DOS. Now, my users are reporting that the boot disk no longer works on machines which have Intel gigabit (PRO/1000) networking hardware. I have one machine with such hardware, and I can confirm that Intel's DOS network driver (e1000.dos) appears to be incompatible with FreeDOS. You can download the latest version of this driver from Intel's site: http://downloadfinder.intel.com/scripts-df/File_Filter.asp?FileName=PRODOS2.EXE Or you can download my boot disk itself as a 1.44M floppy image: http://unattended.sourceforge.net/testing/ e1000.img Although the problem is only reproducible if you have PRO/1000 network hardware... Here is what I have observed. If I use a config.sys which is empty except for DEVICE=\net\ifshlp.sys, the driver loads fine. But when the boot disk tries to use the driver to obtain a DHCP lease, it gets an illegal opcode followed by a reboot. The reboot happens too quickly for me to record the hex values. If I add these lines to config.sys: DOS=HIGH,UMB DEVICE=himem64.exe The same thing happens. If I further add: DEVICE=emm386.exe NOEMS (where HIMEM64 and EMM386 were downloaded from ftp://ftp.devoresoft.com/downloads/ yesterday) ...it still happens, only I see this: Illegal Instruction occurred CS=3046 IP=08CC SS=00CF SP=08B8 DS= ES=DC11 EAX= EBX=0F8C ECX=0003 EDX=0AE4 ESI= EDI=000F EBP= Opcodes @CS:IP 63 20 00 00 00 00 00 00 Aborting program ...and it hangs, letting me record the values. Finally, if I change the emm386.exe invocation in config.sys like this: DEVICE=emm386.exe ...then the e1000.dos driver refuses to load at all! It probes the hardware correctly (printing the MAC address etc.), but then it says: Error: Unsuppored Memory Manager Present Unable to initialize protected mode services Action: -Remove all memory managers from this configuration Failure: Driver did not load, NDIS environment invalid (By the way, the same thing happens if I only load himem64.exe and load cwsdpmi before loading the driver. Obviously, the e1000.dos driver does not play nicely with DPMI providers.) This behavior is with the FreeDOS kernel from ke2033_32. I tried one or two of the above permutations under ke2034_32 with the same results. Obviously, the e1000.dos driver is doing something very strange. However, the exact same boot disk used to work fine under MS-DOS (with or without himem.sys), so from my point of view this is a FreeDOS bug. Any ideas? If I were to offer to send someone a PRO/1000 card to experiment with, would any of you be interested? Or do you have any other suggestions? Thanks! - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS
Michael Devore [EMAIL PROTECTED] writes: Since you're failing without HIMEM or EMM386 loaded, you have to be hitting a kernel compatibility, agreed? It can't be a UMB conflict or a p-mode conflict or something failing in EMS/XMS/VCPI/DPMI calls. That actually narrows the field of suspects quite a lot. Yes. Just to be sure, you've tried the bare driver CONFIG.SYS on an MS-DOS system and it worked correctly? The info is a required data point in case the driver normally requires or expects HIMEM, etc. I just double-checked, even booting from physical floppies instead of network boot + memdisk. (Wow, floppies are slow...) My config.sys has: LASTDRIVE=Z DEVICEHIGH=\net\ifshlp.sys FILES=30 (Since I am not loading any memory manager, I presume DEVICEHIGH=... is equivalent to DEVICE=... ?) With MS-DOS, the e1000.dos driver works fine. With FreeDOS (ke2034_32), it crashes as I described: The driver loads, but when tinyrfc.exe tries to obtain a DHCP lease, it gets an invalid opcode. Actually, I think it may successfully obtain the lease; it pauses for a while before crashing. And the floppy itself spins up again. This time, the system did not reboot; instead, it printed the following three messages with about 2-3 seconds between each: Invalid opcode at FFA7 1100 0212 00CF 0070 0800 04B0 0005 0005 01EC 04B0 143F Invalid opcode at 0212 A73B 0886 0202 0E9E 1038 347F 0012 0001 0033 0001 Invalid opcode at 0032 0800 0093 00F3 3D72 B4C3 2851 11B0 1A92 2851 3CFA 4688 2851 At this point I pressed ctrl+pause, and after that the machine was non-responsive (even to ctrl+alt+del). I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. I know you know assembly language pretty well, plus I can walk you through some basic tests there (obviously a suboptimal situation, but better than nothing). I can (usuall) read other people's code and make trivial changes. It would be a lot nicer if someone intimate with FreeDOS internals could look at this... But I will do what I have to, time permitting. I could test a card here, but since the FreeDOS machine isn't normally hooked into any network, I'm not sure it would do much good. Yeah, the problems don't start until after you actuall use the driver. (Weird about about failing with EMM386 without NOEMS, though. But we can maybe fix that later.) Maybe, but some Google searching suggests that the same thing happens with MS EMM386. The e1000.dos driver really does not like seeing a DPMI provider. Who knows why. - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: Intel PRO/1000 driver fails under FreeDOS
Michael Devore [EMAIL PROTECTED] writes: I don't do kernel work, but depending on how much you want to dig in the guts of the problem, you might want to grab the 386SWAT debugger and load it immediately after the driver, with nothing else. It should catch the exception and throw you into the 386SWAT debugger. After paring down my boot disk, I got 386SWAT to fit (with 2K to spare). And by invoking it with DEVICE=A:\386swat.lod TRAPINV, I actually get thrown into the debugger where I used to get invalid opcode + reboot. So it's a start. But I really have no idea what I am looking at... - Pat --- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Re: [syslinux] Problem with FreeDOS + himem64 + PXELINUX + memdisk
Blaauw,Bernd B. [EMAIL PROTECTED] writes: (are you using UNDI driver btw for PXE, instead of DOS network drivers?) I am using 3com's universal NDIS-over-UNDI driver. But I am not even getting that far... could you leave everything identical on the bootdisk but use a MSDOS kernel on that machine? (dos 7.10 for example)? I do not have MS-DOS 7.10, but I do have MS-DOS 6.22. Here are the results. MS-DOS + MS himem.sys: Works MS-DOS + FreeDOS himem64.exe: Works for a while, but the keyboard tends to lock up FreeDOS + FreeDOS himem64.exe: As reported (instant reboot) FreeDOS + MS himem.sys: Very weird... Screen goes blank, laptop beeps four times at one-second intervals, hard drive activity light comes on, machine is totally non-responsive. My preference for himem above fdxms is the cooperation with emm386 (included in the same package as himem at above emm386 link). I cannot use emm386.exe because it is incompatible with CWSDPMI, so I plan to use umbpci instead. But I am not loading it for this test; only the XMS provider. - Pat ___ SYSLINUX mailing list Submissions to [EMAIL PROTECTED] Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[syslinux] Re: [Freedos-devel] re: Problem with FreeDOS + himem64 + PXELINUX + memdisk
Eric Auer [EMAIL PROTECTED] writes: Hi Pat, your patches and/or MEMDISK have the problem that they do not DETECT which A20 setting styles work and which not! - PS/2: port 92h - or 2 to enable, and ~2 to disable A20 - 8042: command d1 / port 60 ... here, too, ONLY bit 1 should be messed with (or 2 / and ~2). It is important to do wait until 8042 is ready and wait until A20 actually switched. 8042 is slow! - BIOS: your BIOS call may or may not function, depending on the BIOS. So you should try PS/2 first. If this does not work, try BIOS. Finally, try 8042. The BIOS authors know better than anybody how to handle the A20 gate on their hardware. So I think we should always try the BIOS first. In other words, I think the order used by memdisk is correct: First try BIOS, then 8042, then PS/2 (aka. 92h gate). Then keep using only the tested and working access method. Some hardware has the A20 stuck to enabled, should not be a problem. Just display a warning. The memdisk code handles this as well, I believe. My intention was basically to steal it (should be no problem since everything is GPL, right?). Finally, MEMDISK hooks int 15.87? No, but MEMDISK does invoke 15.87 and needs the A20 gate to be saved and restored. And I do think that this is a SYSLINUX problem, so CCing them. I'll let HPA respond to this part :-). Anyway, I am willing to do this work. Unless one of the FreeDOS folks wants to step up to the plate? - Pat P.S. Is there any reason NOT to save/restore A20 around INT15/AH=87 ? ___ SYSLINUX mailing list Submissions to [EMAIL PROTECTED] Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64 testing info/requests
Michael Devore [EMAIL PROTECTED] writes: We're still running into a shortage of testers and I think the best approach may be to soon release a cleaned-up version of the HIMEM we have into the wild, then modify as necessary afterwards. Sounds perfectly reasonable to me. Oh, a final question for you: do you know if any of the Linux code listed is even remotely tied up with all that SCO garbage? Obviously SCO's case is utterly bogus, but as you know, unlike IBM we cannot afford to play chicken with their lawyers. Hard to be sure since SCO refuses to identify which code is infringing. But I doubt it; the contentious code is supposedly based on Unix copyrights, which would almost certainly be referring to C code. I believe the Linux A20 code was contributed by the SYSLINUX author, who definitely never worked for IBM. It is, however, covered by GPL... - Pat --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64 testing info/requests
Michael Devore [EMAIL PROTECTED] writes: Great. Now that HIMEM is getting wider distribution to the eager hundreds or thousands, I've additionally collected problem reports with buggy BIOS support for BIOS method and a failing A20 always on method. It's like a dam busted somewhere upstream. I do not envy you. It sounds like you cannot trust the BIOS status code, so you need to test whether it really enabled/disabled the gate. Or, just tell the user their BIOS is buggy and to get a new machine. :-) What do you mean by failing A20 always on method? Do you mean that A20 is always on but it is not detected as such? (Would that imply that the test_a20 procedure is broken?) I am considering dropping the the KBC method since KBC-2 seems to replace it without problems on all reported machines. This is not too surprising. The Linux kernel initialization code enables A20. Granted that it only has to enable A20 and it only runs once, but it is known to work on millions of machines... In HIMEM64 parlance, the Linux code tries always on, BIOS, KBC-2, and fast, in that order. There are some slight differences. Linux tests the actual state of A20 for every method. In KBC-2, Linux has a longer (or at least different) delay where you have pulse output port. In the test_a20 code, Linux has delays (outb ...) all over the place, possibly to deal with instruction reordering issues (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg00023.html), or possibly not. In general, the Linux code is almost identical to what HIMEM64 does now, except that it does not even try the KBC method, and it tries KBC-2 before fast. For the record, your latest HIMEM64 and EMM386 work great on all of my test systems. Thank you for all the hard work! - Pat --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64 testing info/requests
Michael Devore [EMAIL PROTECTED] writes: I added enable/disable test, but the report was that it still fails, after working for the startup test. Which either means the BIOS is bugged and fails under stress, or there is something very weird going on. Like the test_a20 code failing... The solution for second situation is to try port 92h without the MCA check. Unfortunately there are machines reliably documented as locking up if you goof with port 92h when they don't support that method. If the port 92h test comes at the tail end of the test chain, maybe it doesn't matter because you're going to fail if it fails anyway. Perhaps this is why Linux tries 92h last. I don't know how else to test always on other than to try other methods first, The A20 gate defaults to disabled. So, assuming HIMEM64 is the first program which tries to manipulate the gate, you can make always on the FIRST test just by checking the state of A20. This is what the Linux setup code does. Of course, the Linux setup code is guaranteed to be running pretty early. Whether the same can be said for HIMEM64 is a design choice, I suppose. - Pat --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HIMEM64 testing info/requests
Michael Devore [EMAIL PROTECTED] writes: Of course, I should say enabled here, rather than disabled. I think disabled is correct, assuming disabled is a synonym for closed. (As in, the gate is closed, so it does not pass anything, so the A20 line is disabled and fixed at 0.) Actually, I think the terminology is confusing. As long as we both know what we mean :-). Ultimately, though, the basic question is can we always a assume a known A20 state under all the potentially external to- or pre-HIMEM environments? The whole point of the A20 mechanism is to provide support for ancient software which assumes the A20 address line is always zero. So any machine, whether real or virtual (VMware/Bochs), which supports the gate at all must initialize it to the closed state. After all, ancient software does not know about the gate to begin with, so it could hardly be expected to close it! Only modern software which actually wants to use A20 could even know about the gate. So it is that software's responsibility to open it. So only a machine which does not support the gate at all could initialize it to open. It might be reasonable to say that HIMEM64 owns the A20 gate, and therefore must be the first program to manipulate it. If this fails to work under some emulated environment, that environment is arguably broken... I just took a peek at the memdisk (from SYSLINUX) code, and it disables the A20 gate before booting the virtual machine. I think. I can test under memdisk and VMware if you want to give this a whirl. Your call. - Pat --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: GPL and other licenses
Michael Devore [EMAIL PROTECTED] writes: Logically this fails as a false analogy. Actually, it is quite sound. Every objection you raise has nothing to do with the logic of the analogy, which is to show how restricting your freedom can enhance everybody else's. But fine, forget driving. Pick ANY law whatsoever. By your logic, we would be more free if that law did not exist; therefore, a society with no laws is the most free society possible. And anybody who claims that, say, democracy is more free than anarchy is a zealot. Do you honestly believe that? In your other reply, you wrote, GPL forces ABC developer to do things he or she may not want to do. That, in a nutshell, is not giving your ABC developer full freedom. Well, duh. Everybody has to do things he or she may not want to do. (Do you pay taxes?) Nobody has full freedom. In particular, you do not have the freedom to violate MY RIGHTS. The GPL authors believe that modifying and sharing information is a natural right, like breathing or the freedom of speech. You may disagree with them, but that does not mean they are irrational zealots. In this view, the GPL states simply, You may use my code for anything you like, but not to deprive other people of their freedom. Which I happen to think is a good thing, and I am glad that FreeDOS is licensed under the GPL. - Pat --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
