Hi Eric, On Sun, Apr 06, 2008 at 04:10:49AM +0200, Eric Auer wrote: > > 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?
Bochs bios is compiled with "bcc" and "as86". I've ported it to "gcc" and "gas". I did convert most of the assembler to C code. I briefly outlined my reasons for doing this at: http://sourceforge.net/mailarchive/forum.php?thread_name=20080222155930.GA7310%40double.lan&forum_name=bochs-developers Info on obtaining the code is at: http://sourceforge.net/mailarchive/forum.php?thread_name=20080330153030.GA1402%40ohio.lan&forum_name=bochs-developers [...] > > 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. The hard drive is accessed via PIO mode, so enabling irqs isn't required for correct hd operation. I'm guessing bochs bios turns on irqs so that the system ticks and other timers don't go unanswered while the hard drive is reading/writing data. (The hard drive could take multiple seconds for an access - if irqs are off I think it would lead to lost timer ticks.) I have commented out the irq enable for testing, and I can confirm that the problems stop occuring. Unfortunately, when I enable irqs and put tests in the bios ISR routines, I don't see them getting called with low stack space. This adds a new wrinkle - how much stack space does the freedos ISR routines need.. > > 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. Thanks, I'll try this. > > 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...? Yeah, I thought it was odd too, but it is correct. From "mem", it appears that EMM386 is installing a wrapper around int 13 calls: 0317 3,616 (4K) EMM386 device driver BTW, I'm using freedos 1.0 - everything installed from the standard cd download. > 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. [...] Great info. Thanks! > 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 ..." Okay. I'm emulating with qemu. It can dump memory areas to a file, and it also allows one to attach gdb to the virtual machine. No lbacache: 03a6:00cd = 00d1:0e68 (stack start at 00d1:0d60) I believe stack starts at 0d60 because I see 48 consecutive 00 values starting there. lbacache: 03a6:00cd = 0401:2be0 (stack start at 0401:2afc) I guess stack starts at 2afc because I see 18 consecutive 20 values. (This is with "INSTALL=lbacache.com 6000" added to fdconfig.sys.) lbacache tuns: 03a6:00cd = 03fa:00ec (stack start at 03fa:0000) I see 26 consecutive 20 values. (This is with "INSTALLHIGH=lbacache.com 6000 TUNS" added to fdconfig.sys - I see similar behavior with "loadhigh lbacache 6000 tuns" run from command line.) > 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. If I dump all of memory, I see the "90" pattern at (absolute) 0x1330, 0x1630, 0x1cba. However, I don't see those areas in use on int 13 calls. There is plenty of free space at those addresses (0x1c0, 0x50, 0x164 respectively). > Quite long examples, but I hope they help you to get some more > insights about your stack usage :-). Thanks Eric - I appreciate the examples you provided. -Kevin ------------------------------------------------------------------------- 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
