Hi Kevin, (sorry everybody for the long mail :-p Otoh, Kevin keeps CCing the mailing list - and Alain thinks always CCing the list is a good way to let people know that DOS is alive. oh well... ;-))
> > Hmmm I thought Bochs already uses a LGPL BIOS...? :-) > > Yes - I am working on the bochs bios. Specifically, > I have ported bochs bios to gcc. You mean from Assembly language to C...? Why that? > I confused another report with the lbacache case. The disk accesses > that are causing stack overflows for me are being called with 236 > bytes of stack. Although this is notably larger, it still seems > small to me. Yes, because lbacache gives you "300 or 320 bytes minus what it uses itself" while the FreeDOS kernel gives you "384 bytes minus what it uses itself". If you use lbacache, then lbacache will use a bit of the 384 bytes of the kernel, but will mostly use its own 300 or 320 bytes, and lbacache will let the bios use the rest of the 300 or 320 bytes, no matter how much is used/free on the stack provided by the freedos kernel to lbacache... Having 236 bytes of free stack for your bios probably seems small because a "high level" language such as C is not efficient in stack use... It will often use stack instead of CPU registers for local variable storage in functions, for example. > That is interesting. I don't think the int 13 handler is directly > exceeding the stack - instead I think the int 13 handler uses part > of the stack and turns on irqs. This turning on of irqs I think > leads to the stack being overflowed. Very useful theory! I think you should only enable the one irq which is triggered by the harddisk, not all irq in general, in your int 13 handler. Various irq handlers might use varying amounts of stack if you enable them and int 13 gets the "wrong" moment: ps2, timer, net, usb, anything. On the other hand, you should only use "enable only the irq for the disk" if you know which one it is and if the risk of side effects of the 8259 irq controller reprogramming is low enough. Doing some STI, wait for disk irq, CLI sequence admittedly is easier. Try to keep the time with all IRQ enabled short in that case and try to reduce the risk of other IRQ being handled while your own disk IRQ handler is active. In other words, do not STI inside your IRQ handler. > If FreeDOS has separate stacks for irqs, does this mean the > above shouldn't be happening? You can enable such stacks with STACKS=16,512 (for example) which gives the first 16 IRQs each 512 bytes of stack. I am not sure about whether that is 512 bytes per handler or a shared pool of 16*512 bytes for all handlers in FreeDOS. > With lbacache on, TUNS on: 03a6:00cd = 03fa:00ec > > That is "cs:ip = ss:sp" for "int 13". The stack represents the > position prior to the six bytes for "int" overhead being added. Thats a sort of implausible value. Having cs:ip=3a6:cd both with lbacache on AND off...? > Without lbacache??: 03a6:00cd = 00d1:0e68 > With lbacache TUNS: 0751:0561 = 0751:2be6 (no emm386) > With lbacache??: 03a6:00cd = cd3c:2be0 ?? > With lbacache: 0751:0561 = 0751:2be6 (no emm386) > Without lbacache: ffff:a01c = 00d1:0e6e (no emm386) Well you see two things here: no emm386 causes loading lbacache higher in RAM as less RAM is free. And TUNS does only make a difference if: 1. emm386 is loaded and 2. you do load lbacache as "loadhigh lbacache tuns ...". Without the loadhigh, tuns cannot make a difference for / help you. If no lbacache is loaded, you get the FreeDOS kernel stack. There are error, disk, and char stacks (..._tos pointers) which are set up in globals.h / entry.asm / kernel.asm: The stacks have a very "exact" location in the kernel RAM, for MS DOS compatibility: Error stack first, disk stack is 384 bytes later, char stack is last. Overflowing from disk to error stack might be okay if no error happens during the disk access? Block and clock device drivers also have their own stacks, 384 and 128 bytes respectively. The char stack seems to be only for int 21 funcs 01..0c, the error stack only for error handling, and the disk stack for all other int 21, 25 and 26 handling. ABSOLUTE values of stack pointers do not tell you much: If your int 13 sees "ss:sp = 00d1:0e6e" then you may still only have 16 bytes of USEABLE stack if 00d1:0000 to 00d1:0e5e contain other data which must not be overwritten. So you cannot say "if sp=e6e then I have e6e bytes stack free". > I don't know much about DOS - I assume disabling LOADHIGH > is equivalent to disabling EMM386. No - LOADHIGH has no effect if EMM386 is missing, but you only get LOADHIGH if you explicitly use LOADHIGH and have loaded EMM386 before using LOADHIGH. The 3 cases I am interested in are: - no lbacache at all (kind of obvious but a bit tricky to find out how much stack you actually have free here) - lbacache loaded without using loadhigh (tuns has no effect here) - emm386 active, lbacache loaded using "loadhigh lbacache tuns ..." In the last 2 cases, you can check how much stack is "never used" with the help of debug. Here is an example: C:\>mem /d | find /i lbacache 037d 320 (0K) LBACACHE data area c3cf 7,088 (7K) LBACACHE program C:\>debug -d 37e:0 l 140 037E:0000 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20 ... 037E:00C0 20 20 20 20 20 20 20 20-69 0B D0 C3 7E 03 00 02 ... 037E:0130 00 00 00 00 01 02 00 00-62 19 46 30 20 20 20 20 You see that the area from 37e:0 to 37e:c7 still contains the 20 20 ... filler bytes which lbacache puts there at init to make it easy to see which part of the stack really is used. The area 37e:c8 to 37e:13b, on the other hand, contains mixed data which shows that this area actually got used for stack data while lbacache and bios were busy with disk access stuff. An example without tuns, for lbacache 18jan2008: 03b1 7,392 (7K) LBACACHE program There is no separate stack memory block, but for the 18jan2008 version, the stack happens to be from 3b2:1b9c to 3b2:1cc8 or maybe 1cdf. It cannot go further, because: -d 3b1:0 l 10 03B1:0000 4D B2 03 CE 01 BF 06 00-4C 42 41 43 41 43 48 45 ...the memory block is 1ce:10 = 1ce0 bytes, so it ends at 1cdf. Where exactly the stack ends is not so interesting, the real question is where it starts: It starts at the place where all those 20 20 ... bytes start, so you can easily see it with a tool like debug. -d 3b2:1b9c l 144 03B2:1B90 - 20 20 20 20 ... 03B2:1C50 20 20 20 20 20 20 20 20-20 20 20 20 69 0B B2 03 ... So you see that in this example, the area 1b9c to 1c5b is not yet actually used, so there are c0 unused bytes. Which is 8 fewer than in the TUNS example but still 192 bytes. The USED part is "what lbacache uses for itself plus what the dosemu bios uses for itself (plus no irq stack use?)". In other words, in dosemu, lbacache could provide a stack which is 192 bytes smaller than the ca 300 or 320 bytes it provides now and it still would work :-). Finding the amount of never used stack in the FreeDOS kernel works as follows: Find an area filled with 90 90 ... bytes before (lower offset) the point where the ss:sp is when your int 13 gets called, and check how many 90 90 are there. Note that only consecutive 90 90 do count, as if you go further to even lower offsets, you get the area of unused error stack, not of unused disk stack. Using a very recent FreeDOS kernel (one with fastboot int19 warm reboot support, for example rugxulo.googlepages.com) you get for example: 00D4:0610 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00D4:0620 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ... it is typical that our stacks start at kerneldataseg:620 ... ... there are 1ce bytes of unused stack at the moment, as we had ... no errors handled yet (error stack at 620 to 79f not yet used) ... of the disk stack, 7a0 to 920, is mostly used: only the area ... from 7a0 to 7fd (5e bytes) never got used yet. However, I guess ... some overflowing into the error stack would be okay anyway... 00D4:07F0 90 90 90 90 90 90 90 90-90 90 90 90 90 90 02 32 ... this is the used part of the disk stack, 7fe to 91f, 122 bytes ... this includes both stack used by the kernel for all sorts of ... disk / file / ... handling and stack used for int 13 calls. 00D4:0910 40 52 C7 02 9D 03 A3 4F-9D 03 2D 02 40 52 9D 03 00D4:0920 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ... the area 920 to 9c3 of the char stack never got used yet, a4 bytes 00D4:09C0 90 90 90 90 8C 01 70 00-06 32 5A 03 D4 00 70 00 ... the area 9c4 to a9f of the char stack did already get used 00D4:0A90 44 52 C7 02 9D 03 A3 4F-9D 03 2D 02 44 52 9D 03 The int 21 stacks end at d4:a9f. Quite long examples, but I hope they help you to get some more insights about your stack usage :-). Eric ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
