<FONTSIZE="2">(15:55:54) </FONT><B>thefreak:</B></FONT> darkito<B>:</B> grieg for his beautifull music, bach for his great mathematical compositions, mozart cause he can make the simple sound great, etc.
<FONTSIZE="2">(15:59:33) </FONT><B>***darkito</B></FONT> listens to schubert - rosamunda "intermezzo"
<BR>
<FONTSIZE="2">(15:59:34) </FONT><B>thefreak:</B></FONT> It's a pulitzer winning book discussing number theory, mathematics and A.I. A classical great book in that field, large parts written in dialouge form and it contains great references to G<>del, the mathematician, Escher, the artist with those wierd scetches, and Bach with fugues.
<FONTSIZE="2">(16:04:11) </FONT><B>wli:</B></FONT> did I miss it yet?
<BR>
<FONTSIZE="2">(16:04:32) </FONT><B>bryce2:</B></FONT> Has anyone found any problems that didn't exist before? or new features that should work but don't?
<BR>
<FONTSIZE="2">(16:04:38) </FONT><B>thefreak:</B></FONT> I'm must say that i'm rather impressed on the ratio between number of downloads and bug reports, does this mean that i don't see them, that people don't even bother to file a bug report or that they never build it? (it's unfair that darkito got the last note, metalast note)
<BR>
<FONTSIZE="2">(16:05:02) </FONT><B>wli:</B></FONT> Did I miss the discussion?
<BR>
<FONTSIZE="2">(16:05:08) </FONT><B>bryce2:</B></FONT> wli: no we just started
<FONTSIZE="2">(16:13:05) </FONT><B>bryce2:</B></FONT> How about keyboard mapping? Has Christophe's keymap code solved the problems of using bochs on a non-US keyboard?
<BR>
<FONTSIZE="2">(16:13:40) </FONT><B>wli:</B></FONT> I've got a Sun Type 6 keyboard and it sometimes doesn't recognize scancodes.
<BR>
<FONTSIZE="2">(16:14:00) </FONT><B>wli:</B></FONT> then again that goes for Linux and XF86 as well
<BR>
<FONTSIZE="2">(16:14:02) </FONT><B>thefreak:</B></FONT> I'm not quite satisfied with it, I might fix a swedish one one day, but it haven't bugged me enough yet though.
<BR>
<FONTSIZE="2">(16:14:11) </FONT><B>bryce2:</B></FONT> wli: what are some of the keys that don't work?
<BR>
<FONTSIZE="2">(16:15:57) </FONT><B>wli:</B></FONT> the crescent moon, the volume keys, and the stop/again/props/undo/front/copy/open/paste/find/cut, and help.
<BR>
<FONTSIZE="2">(16:16:09) </FONT><B>wli:</B></FONT> OTOH I've NFI what it would do with them...
<BR>
<FONTSIZE="2">(16:16:35) </FONT><B>bryce2:</B></FONT> wli: you will probably need to figure out the keysyms of the missing keys (using output of xev or something) and add a line in gui/x.cc to handle them
<BR>
<FONTSIZE="2">(16:16:39) </FONT><B>bryce2:</B></FONT> that's a point. :)
<BR>
<FONTSIZE="2">(16:16:42) </FONT><B>slowcoder:</B></FONT> bryce2: I haven't been able to get VBE (+linear patches) working with the RH6.2 image thats on the site.. It appears to set the video-mode, and then after a few secs, it panics.. I'm running stock 1.4, would the CVS version help ?
<BR>
<FONTSIZE="2">(16:16:57) </FONT><B>wli:</B></FONT> I patched XF86 so it wouldn't crap the bed and now it passes along keycodes that 0 apps understand...
<FONTSIZE="2">(16:17:30) </FONT><B>slowcoder:</B></FONT> japj: Did you get that ?
<BR>
<FONTSIZE="2">(16:17:34) </FONT><B>japj:</B></FONT> I will need to check the RH6.2 image on the site
<BR>
<FONTSIZE="2">(16:17:47) </FONT><B>bryce2:</B></FONT> slowcoder: and we'll need to know what is the panic message.
<BR>
<FONTSIZE="2">(16:18:08) </FONT><B>wli:</B></FONT> probably should be all separate patches
<BR>
<FONTSIZE="2">(16:18:14) </FONT><B>slowcoder:</B></FONT> I'm at another location right now, so I can't check it.. Sorry..
<BR>
<FONTSIZE="2">(16:18:17) </FONT><B>japj:</B></FONT> slowcoder: I hate to ask, but can you submit a bug on the sourceforge bug tracker on this?
<BR>
<FONTSIZE="2">(16:18:36) </FONT><B>bryce2:</B></FONT> hooray for the SF bug tracker
<BR>
<FONTSIZE="2">(16:18:47) </FONT><B>slowcoder:</B></FONT> japj: Sure, np.. I'll get some more info, and submit it
<BR>
<FONTSIZE="2">(16:19:38) </FONT><B>bryce2:</B></FONT> I tried to make "Paste" work in the precompiled binaries. Any luck with that?
<BR>
<FONTSIZE="2">(16:19:56) </FONT><B>bryce2:</B></FONT> Copy and Snapshot should work everywhere, but to get paste working you must turn on keyboard_mapping.
<BR>
<FONTSIZE="2">(16:21:12) </FONT><B>wli:</B></FONT> a copy key?
<BR>
<FONTSIZE="2">(16:21:21) </FONT><B>wli:</B></FONT> I think it's like SunCopy or something
<BR>
<FONTSIZE="2">(16:21:31) </FONT><B>bryce2:</B></FONT> wli: those little toolbar buttons on the top, ya know?
<FONTSIZE="2">(16:22:31) </FONT><B>thefreak:</B></FONT> We might be able to create a guestOS kit (daemons which talks to the emulator) in order to make cut and paste work between guest and host in a proper way...
<BR>
<FONTSIZE="2">(16:22:45) </FONT><B>japj:</B></FONT> bryce2: btw, why can't I do "bochs some_bochsrc_file"
<BR>
<FONTSIZE="2">(16:23:04) </FONT><B>japj:</B></FONT> and have bochs read the rc file
<BR>
<FONTSIZE="2">(16:23:34) </FONT><B>bryce2:</B></FONT> at one time, all command line options were treated just like bochsrc options
<BR>
<FONTSIZE="2">(16:23:54) </FONT><B>bryce2:</B></FONT> like bochs 'boot: c' 'vgaromimage: bios/VGABIOS-elpin-2.40'
<BR>
<FONTSIZE="2">(16:24:22) </FONT><B>bryce2:</B></FONT> I don't even know if it still works.
<BR>
<FONTSIZE="2">(16:24:36) </FONT><B>japj:</B></FONT> btw, I still get wxmain.cc:960:28: gdk/gdkkeysyms.h: No such file or directory .. do I need some gdk dev package?
<BR>
<FONTSIZE="2">(16:24:45) </FONT><B>bryce2:</B></FONT> it would make sense though
<BR>
<FONTSIZE="2">(16:25:22) </FONT><B>bryce2:</B></FONT> (he's talking about wxwindows if you're wondering)
<BR>
<FONTSIZE="2">(16:25:36) </FONT><B>bryce2:</B></FONT> japj: my gdk/gdkkeysyms.h is provided by a package gtk+-devel-1.2.6-7
<BR>
<FONTSIZE="2">(16:25:40) </FONT><B>japj:</B></FONT> (the bochs cpanel brand)
<BR>
<FONTSIZE="2">(16:26:18) </FONT><B>bryce2:</B></FONT> try grep GDK_Alt_L /usr/include/*/*.h to find it
<BR>
<FONTSIZE="2">(16:26:33) </FONT><B>bryce2:</B></FONT> if it's in a different directory or something
<BR>
<FONTSIZE="2">(16:26:48) </FONT><B>japj:</B></FONT> it's in /usr/include/gtk-1.2/gdk/gdkkeysyms.h
<BR>
<FONTSIZE="2">(16:27:15) </FONT><B>cbothamy:</B></FONT> There is one "bug" when you press the config button. The default answer is "10. Instruction tracing", i'd prefer it be "11. Continue"
<BR>
<FONTSIZE="2">(16:27:16) </FONT><B>bryce2:</B></FONT> ah I bet we need gtk-config --cflags or something
<BR>
<FONTSIZE="2">(16:27:29) </FONT><B>bryce2:</B></FONT> cbothamy: haha good point
<BR>
<FONTSIZE="2">(16:28:05) </FONT><B>cbothamy:</B></FONT> bryce2: i think it comes from the added "keyboard paste delay" option
<BR>
<FONTSIZE="2">(16:29:08) </FONT><B>bryce2:</B></FONT> cbothamy: I'll fix it.
<BR>
<FONTSIZE="2">(16:30:48) </FONT><B>cbothamy:</B></FONT> Has anybody had "keyboard stuck" problem with dos 6.2 ? Or is it just french dos 6.2 ?
<FONTSIZE="2">(16:31:22) </FONT><B>bryce2:</B></FONT> When I install freedos and run the edit program, it starts up and displays just fine, but then it doesn't respond to any key I press. Meanwhile, the clock down in the lower right is ticking away, but there is absolutely nothing I can do except reboot.
<FONTSIZE="2">(16:31:58) </FONT><B>japj:</B></FONT> the keyboard is 'systematicly' not responding in certain cases
<BR>
<FONTSIZE="2">(16:32:03) </FONT><B>cbothamy:</B></FONT> I fixed two missings functions in the bios yesterday because of this problem.
<BR>
<FONTSIZE="2">(16:32:32) </FONT><B>japj:</B></FONT> (or mabye 'was' not responding ... need to recheck after those changes)
<BR>
<FONTSIZE="2">(16:32:50) </FONT><B>bryce2:</B></FONT> cbothamy: do you have any suggestions on how to debug stuck keyboards?
<BR>
<FONTSIZE="2">(16:33:09) </FONT><B>cbothamy:</B></FONT> bryce2: can you check with current bios ? you will have to recompile it though
<BR>
<FONTSIZE="2">(16:33:10) </FONT><B>eks:</B></FONT> bryce2: do a trace on the keyboard port and keyboard functions
<BR>
<FONTSIZE="2">(16:33:16) </FONT><B>japj:</B></FONT> bryce2: I can boot that debian image, what was the idea?
<BR>
<FONTSIZE="2">(16:34:11) </FONT><B>bryce2:</B></FONT> eks: I have tried that, and everything looks the same when the keyboard works and when it's stuck.
<BR>
<FONTSIZE="2">(16:34:41) </FONT><B>bryce2:</B></FONT> japj: the idea was to install XFree4 in that image and try to run it with VBE
<BR>
<FONTSIZE="2">(16:34:51) </FONT><B>eks:</B></FONT> bryce2: the only other thing I see that could make it "stuck" is if the IRQ line was not lowered/raised under certain circonmstances
<BR>
<FONTSIZE="2">(16:34:54) </FONT><B>slowcoder:</B></FONT> japj: (With regards to the VBE "issue") would the CVS version have any improvements compared to the 1.4 release ?
<BR>
<FONTSIZE="2">(16:35:43) </FONT><B>japj:</B></FONT> current cvs has LFB patched already applied, 1.4 doesn't (but they both need the additional vbebios from patches/ somefile.tar.gz)
<BR>
<FONTSIZE="2">(16:35:44) </FONT><B>wli:</B></FONT> logging how irq's are raised/lowered
<FONTSIZE="2">(16:36:07) </FONT><B>slowcoder:</B></FONT> japj: Ok, but there hasn't been any changes in the code ?
<BR>
<FONTSIZE="2">(16:36:08) </FONT><B>cbothamy:</B></FONT> bryce2: no, i never had such problems before. Anyway, the fix is just for the key.com dos program
<BR>
<FONTSIZE="2">(16:36:19) </FONT><B>bryce2:</B></FONT> when I tried to debug the keyboard stuck problem (unsucessfully) I wrote everything I tried in http://sourceforge.net/tracker/index.php?func=detail&aid=466292&group_id=12580&atid=112580
<BR>
<FONTSIZE="2">(16:36:25) </FONT><B>japj:</B></FONT> what's vfb.o (in /lib/modules/.../video , is it a vesa framebuffer driver?
<FONTSIZE="2">(16:40:27) </FONT><B>slowcoder:</B></FONT> bryce2: There's an issue with it.. The root-password is unknown.. I had to mess around with it quite a bit..
<FONTSIZE="2">(16:49:11) </FONT><B>wli:</B></FONT> As far as I'm concerned the simulation speed (or lack thereof) is an artifact of doing pure software emu, and I'd rather have the control than the speed.
<BR>
<FONTSIZE="2">(16:49:15) </FONT><B>japj:</B></FONT> nope, that won't work, but 1-3 people should definitely be looking at it
<BR>
<FONTSIZE="2">(16:49:25) </FONT><B>bryce2:</B></FONT> or something. We know that emulation is slow compared to virtualization
<BR>
<FONTSIZE="2">(16:50:06) </FONT><B>bryce2:</B></FONT> Kevin chose to move to an entirely different architecture, rather than try to squeeze another 2x out of the existing bochs architecture. He's studied the problem more than any of us I expect.
<BR>
<FONTSIZE="2">(16:50:44) </FONT><B>wli:</B></FONT> I've got an idea of how many JIT back ends I feel like writing and it's a natural number strictly less than 1.
<BR>
<FONTSIZE="2">(16:50:48) </FONT><B>cbothamy:</B></FONT> Well, virtual PC can do it...
<BR>
<FONTSIZE="2">(16:51:12) </FONT><B>bryce2:</B></FONT> does virtual PC try to compile on 10 platforms?
<BR>
<FONTSIZE="2">(16:51:19) </FONT><B>japj:</B></FONT> slowcoder: yep that was it, so it's not actually a 512 mb image then?
<BR>
<FONTSIZE="2">(16:51:25) </FONT><B>thefreak:</B></FONT> wli<B>:</B> if you write 0.9 of it, we'll do the rest :)
<FONTSIZE="2">(16:53:24) </FONT><B>slowcoder:</B></FONT> japj: Guess again
<BR>
<FONTSIZE="2">(16:53:51) </FONT><B>thefreak:</B></FONT> wli<B>:</B> any problem is simple enough when you've learned how to break it down properly.. :)
<BR>
<FONTSIZE="2">(16:54:02) </FONT><B>bryce2:</B></FONT> slowcoder: we should make it into a split disk image. That's what I wrote it for. The boot track can be one file, the first partition can be another. :)
<BR>
<FONTSIZE="2">(16:54:39) </FONT><B>slowcoder:</B></FONT> japj: After the fsck'ing, reboot and at the lilo-prompt, type: 'linux single init=/bin/sh' , and edit the /etc/passwd from there..
<BR>
<FONTSIZE="2">(16:54:47) </FONT><B>japj:</B></FONT> bryce2: I would like to have 'incremental write' images
<BR>
<FONTSIZE="2">(16:55:17) </FONT><B>japj:</B></FONT> but then a lot of tools won't work anymore
<BR>
<FONTSIZE="2">(16:55:20) </FONT><B>bryce2:</B></FONT> me too. [ 433171 ] patch disk image mode
<BR>
<FONTSIZE="2">(16:55:26) </FONT><B>slowcoder:</B></FONT> japj: That would be _great_ for trying out fses for experimental-oses.
<FONTSIZE="2">(16:55:31) </FONT><B>wli:</B></FONT> thefreak: an interpreter targets a virtual machine and simulates the virtual machine. JIT is targeting native hardware and doing dynamic code loading... so you've got a compiler, assembler, linker, runtime dynamic linker, and still more strange runtime issues, and still hairier issues to deal with involving debugging things that are getting auto-generated and vaporize out from under you when you look at them...
<BR>
<FONTSIZE="2">(16:55:55) </FONT><B>wli:</B></FONT> thefreak: and you repeat the entire process once for every arch
<BR>
<FONTSIZE="2">(16:55:59) </FONT><B>eks:</B></FONT> bryce2: seems like the keyboard problem is present even in console mode, as soon as you press "ALT"...
<BR>
<FONTSIZE="2">(16:56:02) </FONT><B>wli:</B></FONT> thefreak: this is a true nightmare
<BR>
<FONTSIZE="2">(16:56:41) </FONT><B>bryce2:</B></FONT> eks: interesting. I hadn't noticed that one.
<BR>
<FONTSIZE="2">(16:56:51) </FONT><B>japj:</B></FONT> slowcoder: the redhat6 image root password is 'redhat'
<FONTSIZE="2">(16:57:06) </FONT><B>eks:</B></FONT> that's why it seems to freeze in edit, since you most likely want to access ALT+F to open a new file or such..
<BR>
<FONTSIZE="2">(16:57:28) </FONT><B>bryce2:</B></FONT> Here's an idea for simulation performance improvement. Let me know what you think...
<BR>
<FONTSIZE="2">(16:57:55) </FONT><B>bryce2:</B></FONT> Theory: bochs cannot run fast even on fast machines because it is absolutely full of branches which cannot be predicted right.
<BR>
<FONTSIZE="2">(16:57:56) </FONT><B>thefreak:</B></FONT> wli<B>:</B> can we get better speed in another way? Writing os/specific optimiztion is one other way..?
<BR>
<FONTSIZE="2">(16:58:12) </FONT><B>wli:</B></FONT> heck I don't know
<BR>
<FONTSIZE="2">(16:58:13) </FONT><B>japj:</B></FONT> how do I turn off mousegrabbing under linux? (in windows it's F12?)
<BR>
<FONTSIZE="2">(16:58:28) </FONT><B>bryce2:</B></FONT> When running code that is very frequently used, like a loop that executes over and over,
<BR>
<FONTSIZE="2">(16:58:54) </FONT><B>slowcoder:</B></FONT> japj: Third mousebutton
<BR>
<FONTSIZE="2">(16:59:23) </FONT><B>bryce2:</B></FONT> we "generate code" which is just the implementation of each instruction of the loop appended together
<BR>
<FONTSIZE="2">(16:59:25) </FONT><B>japj:</B></FONT> as far as I can see the redhat6 XFree, doesn't use VBE. It uses the standard vga adapter to display things
<FONTSIZE="2">(17:00:01) </FONT><B>bryce2:</B></FONT> with no branches in between. Does anyone think that would make a difference?
<BR>
<FONTSIZE="2">(17:00:17) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> is the loop detection trivial?
<BR>
<FONTSIZE="2">(17:00:34) </FONT><B>wli:</B></FONT> Is this like tabulating function pointers by instruction address?
<BR>
<FONTSIZE="2">(17:01:12) </FONT><B>bryce2:</B></FONT> I'm thinking we identify regions of code memory that are used constantly, and spend some time (at runtime) trying to speed them up.
<BR>
<FONTSIZE="2">(17:01:19) </FONT><B>***eks</B></FONT> wonders why freedos is stuck in a loop reprogramming the PIT after he presses ALT..
<FONTSIZE="2">(17:01:32) </FONT><B>slowcoder:</B></FONT> japj: I was booting the kernel with 'linux vga=????' to enable a framebuffer-console
<BR>
<FONTSIZE="2">(17:01:45) </FONT><B>bryce2:</B></FONT> wli: no I want to eliminate branches in the simulation, except for the branches in the guest code
<BR>
<FONTSIZE="2">(17:01:47) </FONT><B>wli:</B></FONT> I thought it was something different to avoid going through the decoder
<BR>
<FONTSIZE="2">(17:01:51) </FONT><B>bryce2:</B></FONT> for tight loops
<BR>
<FONTSIZE="2">(17:01:51) </FONT><B>japj:</B></FONT> as soon as we get >8bpp colors, I think lots of recent distros will be able to show nice installation gfx (some use hardcoded 16bpp modes during setup, instead of allowing 8bpp support)
<BR>
<FONTSIZE="2">(17:02:46) </FONT><B>japj:</B></FONT> I can't type ? in bochs :)
<BR>
<FONTSIZE="2">(17:03:00) </FONT><B>japj:</B></FONT> how do I turn it on?
<BR>
<FONTSIZE="2">(17:03:01) </FONT><B>bryce2:</B></FONT> japj: you need to write a keymap file for yourself
<BR>
<FONTSIZE="2">(17:03:32) </FONT><B>slowcoder:</B></FONT> japj: Wrong keymapping.. It's on '-' with a danish keyboard (if I recall correctly)
<FONTSIZE="2">(17:03:46) </FONT><B>thefreak:</B></FONT> btyce2: I like the idea of trying to detect frequently used code and optimize it.
<BR>
<FONTSIZE="2">(17:04:09) </FONT><B>bryce2:</B></FONT> The reason I suggest this is that I was learning how event-driven simulators can often be replaced by
<BR>
<FONTSIZE="2">(17:04:23) </FONT><B>slowcoder:</B></FONT> japj: When I got the problem, I booted the kernel with 'linux vga=771', which indicates a 800x600x256 framebuffer
<BR>
<FONTSIZE="2">(17:05:03) </FONT><B>bryce2:</B></FONT> a very long string of instructions, when the compiler KNOWS the order the simulated events should occur in. This allows very fast simulation because you don't have to spend time deciding what to do next at every stage.
<BR>
<FONTSIZE="2">(17:05:51) </FONT><B>cbothamy:</B></FONT> bryce2: is this like transforming CISC to RISC microcode ?
<FONTSIZE="2">(17:06:48) </FONT><B>bryce2:</B></FONT> but I think we can use the compiler+assembler to produce the "microcode" in the form of native instructions on your machine
<BR>
<FONTSIZE="2">(17:07:13) </FONT><B>darkito:</B></FONT> hi
<BR>
<FONTSIZE="2">(17:08:00) </FONT><B>***wli</B></FONT> wants lots of cpu's =)
<FONTSIZE="2">(17:08:17) </FONT><B>bryce2:</B></FONT> most modern processors are multiple issue per cycle, out of order machines, and they can go fast if they aren't mispredicting branches or waiting for cache misses all the time.
<BR>
<FONTSIZE="2">(17:08:20) </FONT><B>japj:</B></FONT> slowcoder: I get the linux fb penguin in the left upper corner (running under gdb)
<BR>
<FONTSIZE="2">(17:08:26) </FONT><B>***darkito</B></FONT> wants tons of knowledgements
<BR>
<FONTSIZE="2">(17:08:37) </FONT><B>japj:</B></FONT> slowcoder: (so it doesn't kill itself right away)
<BR>
<FONTSIZE="2">(17:08:59) </FONT><B>slowcoder:</B></FONT> japj: I didn't get that.. It just changed the size of the bochs-window, and everything was black..
<BR>
<FONTSIZE="2">(17:09:11) </FONT><B>japj:</B></FONT> bryce2: how do I turn on debug symbols?
<BR>
<FONTSIZE="2">(17:09:15) </FONT><B>slowcoder:</B></FONT> japj: And that's with the CVS version?
<FONTSIZE="2">(17:09:35) </FONT><B>bryce2:</B></FONT> japj: if using .conf.linux to configure, edit it and add "-g" to the CFLAGS/CXXFLAGS
<BR>
<FONTSIZE="2">(17:09:38) </FONT><B>slowcoder:</B></FONT> japj: Okay.. Looks like I brainfarted somewhere then..
<BR>
<FONTSIZE="2">(17:09:52) </FONT><B>bryce2:</B></FONT> otherwise export CFLAGS=-g; export CXXFLAGS=-g before running configure.
<BR>
<FONTSIZE="2">(17:10:11) </FONT><B>japj:</B></FONT> slowcoder: no, not entirely :) .. it still crashes (but using gdb, I saw the initial logo drawn correcltly ... after that it segfaults)
<BR>
<FONTSIZE="2">(17:10:20) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> do you have any theory pointers on it? Have you thought about practical implementation - how to assure that we don't spend more time on trying to optimeze than what we win...?
<BR>
<FONTSIZE="2">(17:10:43) </FONT><B>slowcoder:</B></FONT> japj: Still want me to submit the bug to sf ?
<BR>
<FONTSIZE="2">(17:11:00) </FONT><B>japj:</B></FONT> yep, especially mentioning the vga=711 things
<BR>
<FONTSIZE="2">(17:11:13) </FONT><B>bryce2:</B></FONT> thefreak: nothing about simulating virtual machines this way. I bet there are papers on JIT compilers for java that talk about it
<BR>
<FONTSIZE="2">(17:11:22) </FONT><B>slowcoder:</B></FONT> japj: Will do... (Tomorrow)
<BR>
<FONTSIZE="2">(17:11:26) </FONT><B>wli:</B></FONT> for 32-way SMP all you need is clustered APIC mode, more xAPIC stuff in odd places, and *goat's blood*.
<BR>
<FONTSIZE="2">(17:11:30) </FONT><B>japj:</B></FONT> I'm going to rerun lilo on the image (so I won't have to type it in everytime :)
<BR>
<FONTSIZE="2">(17:11:50) </FONT><B>bryce2:</B></FONT> thefreak: but no I don't have anything to back me up. (YET) :)
<BR>
<FONTSIZE="2">(17:12:08) </FONT><B>wli:</B></FONT> any idea why the local APIC timer would wig out?
<BR>
<FONTSIZE="2">(17:12:21) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> as java has overused the JIT acronym, it's hard to find anything theoretical enough in all the junk out on the net :)
<BR>
<FONTSIZE="2">(17:12:39) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> don't drop the idea
<BR>
<FONTSIZE="2">(17:12:43) </FONT><B>bryce2:</B></FONT> cbothamy: should we talk about the ideas for I/O device plugins?
<BR>
<FONTSIZE="2">(17:13:32) </FONT><B>bryce2:</B></FONT> cbothamy: and how to get shared code between bochs and plex?
<BR>
<FONTSIZE="2">(17:13:48) </FONT><B>cbothamy:</B></FONT> bryce2: ok
<BR>
<FONTSIZE="2">(17:14:13) </FONT><B>thefreak:</B></FONT> Is there a need to make the device-loading in devices.cc more dynamic, so that you don't have to recompile when you change configuration?
<BR>
<FONTSIZE="2">(17:14:19) </FONT><B>bryce2:</B></FONT> thefreak: I personally think bochs should most of its spend its time worrying about correctness rather than speed.
<BR>
<FONTSIZE="2">(17:15:03) </FONT><B>bryce2:</B></FONT> Christophe Bothamy and Volker Ruppert have been working on porting the bochs devices that we've been working on for a year into plex86.
<BR>
<FONTSIZE="2">(17:15:47) </FONT><B>wli:</B></FONT> me too
<BR>
<FONTSIZE="2">(17:16:36) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> well, I fully respect that, but I want speed! :) (i can't force you to do it for me though...)
<BR>
<FONTSIZE="2">(17:17:19) </FONT><B>bryce2:</B></FONT> cbothamy: I think you mentioned in an email that you think we can get identical code to work as a bochs device and as a plex device, using a few macro definitions for inter-device communications such as raising interrupts, log messages, etc.
<BR>
<FONTSIZE="2">(17:18:01) </FONT><B>cbothamy:</B></FONT> Log messages are ok
<BR>
<FONTSIZE="2">(17:18:34) </FONT><B>cbothamy:</B></FONT> The idea for plugins is to remove all direct inter-device access.
<BR>
<FONTSIZE="2">(17:20:05) </FONT><B>cbothamy:</B></FONT> In plex this is done by "registering" a plugin global function for each inter-device operation, (ie raise IRQ)
<BR>
<FONTSIZE="2">(17:20:05) </FONT><B>thefreak:</B></FONT> how much inter-device access is there today?
<BR>
<FONTSIZE="2">(17:20:05) </FONT><B>wli:</B></FONT> real hw rarely does that anyway
<BR>
<FONTSIZE="2">(17:21:12) </FONT><B>cbothamy:</B></FONT> thefreak: cmos, timers are accessed by a few devices, IRQ by nearly all,
<BR>
<FONTSIZE="2">(17:21:27) </FONT><B>thefreak:</B></FONT> cbothamy<B>:</B> what about dma?
<BR>
<FONTSIZE="2">(17:21:46) </FONT><B>japj:</B></FONT> how do I display a local variable in gdb? (I'm used to VC6 :)
<BR>
<FONTSIZE="2">(17:22:01) </FONT><B>bryce2:</B></FONT> japj: print n
<BR>
<FONTSIZE="2">(17:22:15) </FONT><B>cbothamy:</B></FONT> thfreak: yes, dma as well for devices using dma ;-)
<BR>
<FONTSIZE="2">(17:22:25) </FONT><B>japj:</B></FONT> bryce2: how can I print it in hex?
<BR>
<FONTSIZE="2">(17:22:31) </FONT><B>japj:</B></FONT> or signed?
<BR>
<FONTSIZE="2">(17:22:34) </FONT><B>bryce2:</B></FONT> japj: printf "%x\n", n
<FONTSIZE="2">(17:23:46) </FONT><B>eks:</B></FONT> bryce2: some code sends a "keyboard disable" command to the emulated keyboard, but never re-enables it
<BR>
<FONTSIZE="2">(17:24:05) </FONT><B>cbothamy:</B></FONT> thefreak: In Bochs, the access is done by directly referencing methods on the objects.
<BR>
<FONTSIZE="2">(17:24:11) </FONT><B>eks:</B></FONT> bryce2: problem is, the code that sends the keyboard disable (0xAD) to port 0x64 is in the bios....
<BR>
<FONTSIZE="2">(17:24:57) </FONT><B>cbothamy:</B></FONT> thefreak: example BX_FD_THIS devices->pic->lower_irq(6);
<BR>
<FONTSIZE="2">(17:25:03) </FONT><B>thefreak:</B></FONT> cbothamy<B>:</B> i personally think the bochs way is awful compared to the pluginmode, it generates lots of depencies which we really don't need.
<FONTSIZE="2">(17:25:39) </FONT><B>thefreak:</B></FONT> cbothamy<B>:</B> i've had a few such problems when trying to implement 3c509 support, eth and ne2k is separated, but not completely.. for example.
<BR>
<FONTSIZE="2">(17:25:48) </FONT><B>bryce2:</B></FONT> thefreak: I think we should be replacing "BX_FD_THIS devices->pic->lower_irq(6)"
<BR>
<FONTSIZE="2">(17:26:13) </FONT><B>bryce2:</B></FONT> with a macro call such as BX_LOWER_IRQ(6) or something
<BR>
<FONTSIZE="2">(17:26:45) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> AAAAHHHRRRGG!!! If we're going to use an oo language, why not use the features on it instead on ugly macros?
<BR>
<FONTSIZE="2">(17:26:56) </FONT><B>bryce2:</B></FONT> I don't even mind if the macro is defined to do the exact same thing as before, but it would make the interface clean.
<BR>
<FONTSIZE="2">(17:27:07) </FONT><B>bryce2:</B></FONT> thefreak: plex86 is a C program
<BR>
<FONTSIZE="2">(17:27:18) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> point taken
<BR>
<FONTSIZE="2">(17:27:32) </FONT><B>bryce2:</B></FONT> thefreak: bochs is a C++ program which doesn't use many features of C++
<BR>
<FONTSIZE="2">(17:28:13) </FONT><B>bryce2:</B></FONT> thefreak: for better or for worse. In fact some features are deliberately short-circuited because they caused a performance loss. Such as the most basic of all: member functions.
<BR>
<FONTSIZE="2">(17:28:16) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> I've actually wondered about that, why did you choose c++ when you're hardly using many of it features?
<BR>
<FONTSIZE="2">(17:28:25) </FONT><B>bryce2:</B></FONT> history
<BR>
<FONTSIZE="2">(17:28:31) </FONT><B>bryce2:</B></FONT> Kevin regrets changing to C++
<BR>
<FONTSIZE="2">(17:28:45) </FONT><B>bryce2:</B></FONT> but it's done and I don't think there's good enough reason to change back.
<BR>
<FONTSIZE="2">(17:29:19) </FONT><B>cbothamy:</B></FONT> If we use macros, the code could be shared as is between the two projects.
<BR>
<FONTSIZE="2">(17:29:35) </FONT><B>bryce2:</B></FONT> Using macros is very flexible. Anybody who wants to use our PIT can
<BR>
<FONTSIZE="2">(17:29:41) </FONT><B>cbothamy:</B></FONT> If we use macros, we can easily move to a plugin architecture
<BR>
<FONTSIZE="2">(17:29:42) </FONT><B>japj:</B></FONT> bryce2: I think I fixed the redhat6 fbdev bug (using linux vga=771 that slowcoder mentioned)
<BR>
<FONTSIZE="2">(17:29:47) </FONT><B>thefreak:</B></FONT> Implementing a emulator in oo-languages would lead to a beautiful implementation, but awfully slow.. And as I said I want speed! :)
<BR>
<FONTSIZE="2">(17:29:59) </FONT><B>bryce2:</B></FONT> just look at the header file, define the macros to do something reasonable in his simulation, and use it.
<BR>
<FONTSIZE="2">(17:30:47) </FONT><B>bryce2:</B></FONT> japj: sorry I wasn't following that conversation :) but I'm glad you found it.
<BR>
<FONTSIZE="2">(17:31:39) </FONT><B>bryce2:</B></FONT> cbothamy: do you and Volker need help with Macro-izing the devices, or do you have it under control?
<BR>
<FONTSIZE="2">(17:31:53) </FONT><B>wli:</B></FONT> the receive stimulus / transition between states / wait paradigm is fine
<BR>
<FONTSIZE="2">(17:32:07) </FONT><B>cbothamy:</B></FONT> bryce2: i guess we can handle it ;-)
<BR>
<FONTSIZE="2">(17:32:09) </FONT><B>wli:</B></FONT> OO is good for that
<BR>
<FONTSIZE="2">(17:32:15) </FONT><B>bryce2:</B></FONT> I think it makes sense to get the macros working in bochs&plex first
<BR>
<FONTSIZE="2">(17:32:30) </FONT><B>bryce2:</B></FONT> then start to add plugin support to Bochs
<BR>
<FONTSIZE="2">(17:32:33) </FONT><B>thefreak:</B></FONT> wli<B>:</B> agreed, interfaces and inheritance is also convenient.
<BR>
<FONTSIZE="2">(17:32:46) </FONT><B>japj:</B></FONT> I'm going to bed now (23:37 over here and I need to work early tomorrow)
<BR>
<FONTSIZE="2">(17:32:53) </FONT><B>bryce2:</B></FONT> (which will require a redefinition of the macros to make them more like plex's definitions)
<FONTSIZE="2">(17:34:06) </FONT><B>thefreak:</B></FONT> BTW. If you're interested... Linux now detects my 3c509 card, it doesn't actually do everything it should though..
<BR>
<FONTSIZE="2">(17:34:07) </FONT><B>bryce2:</B></FONT> we haven't talked about the testing framework ideas yet
<BR>
<FONTSIZE="2">(17:34:09) </FONT><B>wli:</B></FONT> thefreak too
<BR>
<FONTSIZE="2">(17:34:18) </FONT><B>bryce2:</B></FONT> thefreak: cool :) that's the first step!
<FONTSIZE="2">(17:35:05) </FONT><B>bryce2:</B></FONT> regression testing should be a part of any sort of complex model, and we have absolutely nothing.
<BR>
<FONTSIZE="2">(17:35:32) </FONT><B>wli:</B></FONT> booting Linux is the closest thing I have
<BR>
<FONTSIZE="2">(17:35:44) </FONT><B>wli:</B></FONT> kind of imprecise
<BR>
<FONTSIZE="2">(17:35:58) </FONT><B>bryce2:</B></FONT> There are lots of different ways to approach it, from writing out a large log file of memory and I/O references
<BR>
<FONTSIZE="2">(17:36:08) </FONT><B>thefreak:</B></FONT> bryce2<B>:</B> yepps, it's much cleaner interface, one i/o port, and one interrupt. Thank you for the historic lessons on OO-decisions, it will help me keeping a c-style instead of an oop aproach. See ya
<BR>
<FONTSIZE="2">(17:36:09) </FONT><B>wli:</B></FONT> should be a bunch of executives around with canned tests
<BR>
<FONTSIZE="2">(17:36:19) </FONT><B>bryce2:</B></FONT> and comparing output from different versions
<BR>
<FONTSIZE="2">(17:37:06) </FONT><B>wli:</B></FONT> a full OS will generate quite a large trace
<BR>
<FONTSIZE="2">(17:37:08) </FONT><B>bryce2:</B></FONT> to writing guest OS code that searches for problems and returns a pass/fail, like wli just said
<BR>
<FONTSIZE="2">(17:38:15) </FONT><B>bryce2:</B></FONT> or periodically writing out some kind of MD5 checksum of what has been going on (machine state plus memory state) that is likely to differ if some part of the emulation has changed.
<BR>
<FONTSIZE="2">(17:38:33) </FONT><B>bryce2:</B></FONT> The full log is most useful for debugging, because yes it gets very long, but it's better than nothing!
<BR>
<FONTSIZE="2">(17:39:00) </FONT><B>bryce2:</B></FONT> Kevin also used simultaneous simulations of two bochses at once, doing comparison every once in a while, which he called co-simulation.
<BR>
<FONTSIZE="2">(17:39:06) </FONT><B>bryce2:</B></FONT> Any of these interest people?
<BR>
<FONTSIZE="2">(17:40:40) </FONT><B>bryce2:</B></FONT> Since we have a model of an Intel machine, and access to lots of real intel machines, for some kinds of testing we should be systematically comparing bochs results to physical machines.
<BR>
<FONTSIZE="2">(17:40:54) </FONT><B>wli:</B></FONT> um
<BR>
<FONTSIZE="2">(17:41:10) </FONT><B>wli:</B></FONT> the results from physical machines need logic analyzers to obtain
<BR>
<FONTSIZE="2">(17:41:27) </FONT><B>bryce2:</B></FONT> I mean results that can be detected using code
<BR>
<FONTSIZE="2">(17:41:31) </FONT><B>wli:</B></FONT> or circuit-level simulation of the verilog/whatever
<FONTSIZE="2">(17:42:29) </FONT><B>wli:</B></FONT> some of this is BIOS-dependent as well
<BR>
<FONTSIZE="2">(17:42:54) </FONT><B>bryce2:</B></FONT> for example, if you wanted to really get the PIC model right, you could write some test code that logs the PIC activity, and run it on both your PC and on bochs.
<BR>
<FONTSIZE="2">(17:43:07) </FONT><B>bryce2:</B></FONT> figure out what's different, and adjust Bochs accordingly.
<BR>
<FONTSIZE="2">(17:43:36) </FONT><B>wli:</B></FONT> e.g. on NUMA-Q NMI's do stuff basically like startup IPI's in the BIOS
<BR>
<FONTSIZE="2">(17:43:48) </FONT><B>wli:</B></FONT> other boxen probably have other weird BIOS hacks
<BR>
<FONTSIZE="2">(17:43:59) </FONT><B>bryce2:</B></FONT> granted it doesn't work for everything
<BR>
<FONTSIZE="2">(17:44:20) </FONT><B>bryce2:</B></FONT> if would be great for testing accuracy of our floating point multiply or something.
<BR>
<FONTSIZE="2">(17:44:40) </FONT><B>wli:</B></FONT> that can be done in userspace anyway
<BR>
<FONTSIZE="2">(17:44:42) </FONT><B>bryce2:</B></FONT> or almost any other user-level instruction
<BR>
<FONTSIZE="2">(17:45:03) </FONT><B>wli:</B></FONT> singleshot instructions aren't a good example because there's an easy trapdoor =)
<BR>
<FONTSIZE="2">(17:45:25) </FONT><B>bryce2:</B></FONT> it would still be valuable to be able to test them!
<FONTSIZE="2">(17:45:37) </FONT><B>bryce2:</B></FONT> even if it's not a challenge
<BR>
<FONTSIZE="2">(17:45:45) </FONT><B>wli:</B></FONT> userspace test harness for them etc.
<BR>
<FONTSIZE="2">(17:46:37) </FONT><B>bryce2:</B></FONT> talking about regression tests seems to have put nearly everyone to sleep, or driven them away :)
<BR>
<FONTSIZE="2">(17:47:49) </FONT><B>wli:</B></FONT> well
<BR>
<FONTSIZE="2">(17:47:52) </FONT><B>bryce2:</B></FONT> Did anybody see the wxwindows screen shot at http://bochs.sourceforge.net/tmp/wxwindows/wxbochs4.gif ?
<BR>
<FONTSIZE="2">(17:48:15) </FONT><B>wli:</B></FONT> any chance I can sneak in my ulterior motives / blatant plugs / whatever?
<FONTSIZE="2">(17:49:37) </FONT><B>wli:</B></FONT> there are 2 things, 1 more important than the other
<BR>
<FONTSIZE="2">(17:49:40) </FONT><B>bryce2:</B></FONT> for worst case races and things
<BR>
<FONTSIZE="2">(17:49:47) </FONT><B>wli:</B></FONT> #1 is tons of cpu's -- i.e. races right
<BR>
<FONTSIZE="2">(17:49:56) </FONT><B>wli:</B></FONT> #2 is fiddling with memory maps
<BR>
<FONTSIZE="2">(17:50:13) </FONT><B>bryce2:</B></FONT> can you clarify #2?
<BR>
<FONTSIZE="2">(17:50:35) </FONT><B>wli:</B></FONT> discontiguous memory maps have weird issues and under pressure the OS can crap itself believing it's out of mem when it isn't.
<BR>
<FONTSIZE="2">(17:51:08) </FONT><B>wli:</B></FONT> One of the weird issues is that when only one cpu is around the OS "puts processes to sleep" that are chewing up memory so it's hard to bring the issue to light.
<BR>
<FONTSIZE="2">(17:51:11) </FONT><B>Ciaran[zzz]:</B></FONT> I have to go sleep now.
<BR>
<FONTSIZE="2">(17:51:14) </FONT><B>Ciaran[zzz]:</B></FONT> See ya. :)
<BR>
<FONTSIZE="2">(17:51:21) </FONT><B>bryce2:</B></FONT> good night
<BR>
<FONTSIZE="2">(17:51:44) </FONT><B>Ciaran[zzz]:</B></FONT> Is it okay for me to stay in here while I'm sleeping?
<BR>
<FONTSIZE="2">(17:51:46) </FONT><B>wli:</B></FONT> With a lot of cpu's, the OS can be hit by > 1 task at once pushing it and this exposes the issue with allowing too much mem to be consumed
<BR>
<FONTSIZE="2">(17:51:51) </FONT><B>wli:</B></FONT> I don't mind.
<BR>
<FONTSIZE="2">(17:52:01) </FONT><B>bryce2:</B></FONT> ciaran: we won't pour cold water on you.
<FONTSIZE="2">(17:52:42) </FONT><B>wli:</B></FONT> so basically being able to say "give me 128MB at 0, another 128MB starting at 4GB,..." and so on up to 64GB helps a lot here.
<BR>
<FONTSIZE="2">(17:52:50) </FONT><B>eks:</B></FONT> bryce2: does the PIT support mode 0 ?
<BR>
<FONTSIZE="2">(17:53:24) </FONT><B>wli:</B></FONT> atm support for > 8 cpu's on i386 in Linux needs clustered APIC mode + various tidbits of weirdness
<BR>
<FONTSIZE="2">(17:53:44) </FONT><B>bryce2:</B></FONT> eks: based on 10 seconds of looking at pit.cc I think yes
<BR>
<FONTSIZE="2">(17:53:53) </FONT><B>wli:</B></FONT> Assuming there aren't architectural weirdnesses physical mode could be used for > 64 up to 255 on xAPICs
<BR>
<FONTSIZE="2">(17:53:59) </FONT><B>bryce2:</B></FONT> switch (BX_PIT_THIS s.timer[timerid].mode) { case 0: .... }
<FONTSIZE="2">(17:55:05) </FONT><B>bryce2:</B></FONT> wli: I don't think it would be hard to simulate the discontinuous memory maps. I don't know much about it though.
<BR>
<FONTSIZE="2">(17:55:24) </FONT><B>wli:</B></FONT> One of the more pressing issues in Linux is that there are very early issues in v2.5.x with larger machines and without either special equipment or lots of time to devote to workarounds for not having the equipment fixing bootstrap code for larger machines will take ages...
<BR>
<FONTSIZE="2">(17:55:55) </FONT><B>wli:</B></FONT> Yeah the discontiguous memory map doesn't sound hard to me either, it's very much back burner for me.
<BR>
<FONTSIZE="2">(17:56:19) </FONT><B>bryce2:</B></FONT> eks: I didn't say it did mode 0 right necessarily :)
<BR>
<FONTSIZE="2">(17:56:31) </FONT><B>wli:</B></FONT> the way things come to light is for instance running dbench on an NFS-mounted filesystem on an SMP discontiguous memory machine.
<BR>
<FONTSIZE="2">(17:57:33) </FONT><B>wli:</B></FONT> the OS "paints itself into a corner" by not slowing down those consuming memory well enough to keep enough memory there to do low-level operations that will eventually alleviate the pressure... but this is less difficult to simulate by far than the interrupt controller business.
<BR>
<FONTSIZE="2">(17:58:43) </FONT><B>wli:</B></FONT> one of the most aggravating issues that's come up has to do with the APIC LVT timer in conjunction with some obvious bits to simulate clustered APIC destination formats.
<BR>
<FONTSIZE="2">(17:59:18) </FONT><B>wli:</B></FONT> there aren't enough clues to really tell why the in-service bit isn't getting cleared.
<BR>
<FONTSIZE="2">(17:59:26) </FONT><B>bryce2:</B></FONT> I see how bochs can be useful to see what's going on in some of these situations where the system gets unstable.
<BR>
<FONTSIZE="2">(17:59:57) </FONT><B>wli:</B></FONT> bryce: the greater parallelism exposes OS stability issues hidden by implicit serialization on smaller systems.
<BR>
<FONTSIZE="2">(18:00:02) </FONT><B>bryce2:</B></FONT> wli: I say, add lots more BX_DEBUGs :)
<BR>
<FONTSIZE="2">(18:00:39) </FONT><B>wli:</B></FONT> well, atm I don't really know if I'm working with the latest bits of APIC LVT code.
<FONTSIZE="2">(18:01:39) </FONT><B>wli:</B></FONT> one question that arises is how it's been tested thus far;
<BR>
<FONTSIZE="2">(18:02:17) </FONT><B>wli:</B></FONT> it *appears* that the APIC LVT timer doesn't adjust the interrupt vector by the base vector so for the timer interrupt (0) it appears to the cpu as interrupt 0 and generates a div by 0 exception
<BR>
<FONTSIZE="2">(18:02:35) </FONT><B>eks:</B></FONT> bryce2: on my system here it gets stuck in an infinite loop always reprogramming the PIT channel 0 for mode 0
<BR>
<FONTSIZE="2">(18:02:44) </FONT><B>eks:</B></FONT> bryce2: the loop is 25 instructions long
<BR>
<FONTSIZE="2">(18:03:03) </FONT><B>wli:</B></FONT> I didn't see an obvious base register so I just added a hardcoded offset of 0x20 to the vector since I know 0x20 is what Linux uses.
<BR>
<FONTSIZE="2">(18:03:16) </FONT><B>eks:</B></FONT> bryce2: keeps waiting for something to change on its stack
<BR>
<FONTSIZE="2">(18:03:29) </FONT><B>wli:</B></FONT> this is a workaround; the real fix is unclear
<BR>
<FONTSIZE="2">(18:03:32) </FONT><B>eks:</B></FONT> bryce2: so my guess is that it is waiting for the timer to act, but it never comes
<BR>
<FONTSIZE="2">(18:03:40) </FONT><B>bryce2:</B></FONT> eks: very strange.
<BR>
<FONTSIZE="2">(18:03:57) </FONT><B>bryce2:</B></FONT> eks: since we can get source to freedos edit, I wonder if that would shed some light on the behavior.
<BR>
<FONTSIZE="2">(18:04:14) </FONT><B>eks:</B></FONT> bryce2: I get the same behaviour from the console :/
<BR>
<FONTSIZE="2">(18:04:21) </FONT><B>wli:</B></FONT> there are some other odd issues; I believe that S-APIC bus arbitration should use round-robin distribution of the interrupts, but AFAICT IDE interrupts are always delivered to cpu0.
<BR>
<FONTSIZE="2">(18:04:45) </FONT><B>wli:</B></FONT> And this is in flat logical destination format.
<BR>
<FONTSIZE="2">(18:05:16) </FONT><B>wli:</B></FONT> btw, do I need to separate out the parts of the 8-way patch that -aren't- workarounds so they can be included?
<BR>
<FONTSIZE="2">(18:05:38) </FONT><B>bryce2:</B></FONT> eks: hmm. did you turn on debugging on the PIC? maybe there are some clues just before it gets into the infinite loop.
<BR>
<FONTSIZE="2">(18:06:05) </FONT><B>wli:</B></FONT> the BIOS and configure.in stuff is trivial and has no bearing on quality of simulation for other configurations.
<BR>
<FONTSIZE="2">(18:06:40) </FONT><B>bryce2:</B></FONT> wli: I havent' had time to look at it more than a minute.
<BR>
<FONTSIZE="2">(18:07:04) </FONT><B>bryce2:</B></FONT> wli: which is the case for lots of things :(
<BR>
<FONTSIZE="2">(18:07:23) </FONT><B>wli:</B></FONT> so barring reviews for correctness of the other bits I should eliminate the bits that have any impact on simulation while <8cpu'sareinuse?
<BR>
<FONTSIZE="2">(18:07:55) </FONT><B>wli:</B></FONT> and leave the other stuff around so people can see what kinds of issues arise until real fixes are done?
<BR>
<FONTSIZE="2">(18:08:44) </FONT><B>bryce2:</B></FONT> yes, it will help me if you can split into two patches
<BR>
<FONTSIZE="2">(18:08:48) </FONT><B>eks:</B></FONT> bryce2: I'll compress the out.bochs and place it on my server, gimme a sec
<BR>
<FONTSIZE="2">(18:08:52) </FONT><B>wli:</B></FONT> on its way today
<BR>
<FONTSIZE="2">(18:09:24) </FONT><B>bryce2:</B></FONT> 1. things that you know are right, such as the 8-way cpu bios/configure changes
<BR>
<FONTSIZE="2">(18:09:37) </FONT><B>bryce2:</B></FONT> 2. workarounds, which I would want to leave in patches but not check in
<BR>
<FONTSIZE="2">(18:09:51) </FONT><B>bryce2:</B></FONT> eks: I doubt I'll be able to make sense of it, but I'll look :)
<BR>
<FONTSIZE="2">(18:10:02) </FONT><B>eks:</B></FONT> bryce2: I think the contrary :p
<BR>
<FONTSIZE="2">(18:10:31) </FONT><B>eks:</B></FONT> bryce2: is 1.2MB too big?
<FONTSIZE="2">(18:11:09) </FONT><B>eks:</B></FONT> bryce2: uncompress and go at the end of the log
<BR>
<FONTSIZE="2">(18:11:22) </FONT><B>eks:</B></FONT> look at the various [PIT ] entries
<BR>
<FONTSIZE="2">(18:11:29) </FONT><B>eks:</B></FONT> you will notice something quite anormal
<BR>
<FONTSIZE="2">(18:12:28) </FONT><B>eks:</B></FONT> the timer is "reset" continously, that's alright, but it never have the time to expire before the timer is set again
<BR>
<FONTSIZE="2">(18:13:22) </FONT><B>bryce2:</B></FONT> I wonder if you set ips = 10 million if the problem would go away
<BR>
<FONTSIZE="2">(18:13:34) </FONT><B>eks:</B></FONT> most likely the reverse, IPS=1 ;)
<BR>
<FONTSIZE="2">(18:13:42) </FONT><B>bryce2:</B></FONT> ah one of those
<BR>
<FONTSIZE="2">(18:13:50) </FONT><B>wli:</B></FONT> I should try something like 32M for the 32-way sim.
<BR>
<FONTSIZE="2">(18:13:50) </FONT><B>eks:</B></FONT> I'll give it a try
<BR>
<FONTSIZE="2">(18:13:56) </FONT><B>wli:</B></FONT> it might make issues go away
<BR>
<FONTSIZE="2">(18:13:58) </FONT><B>bryce2:</B></FONT> usually raising ips makes it more realistic
<BR>
<FONTSIZE="2">(18:14:44) </FONT><B>wli:</B></FONT> maybe 600M or something hopefully that won't overflow inside the sim
<FONTSIZE="2">(18:15:23) </FONT><B>bryce2:</B></FONT> eks: can you see from the disassembly how this code EXPECTS to ever leave the loop?
<BR>
<FONTSIZE="2">(18:17:04) </FONT><B>bryce2:</B></FONT> does the inf loop start immediately after the ALT is pressed?
<BR>
<FONTSIZE="2">(18:17:47) </FONT><B>eks:</B></FONT> there's a CMP BX, SS:[BP + F9]
<BR>
<FONTSIZE="2">(18:18:37) </FONT><B>eks:</B></FONT> I think it's related to the X11 GUI too... here's what happen
<BR>
<FONTSIZE="2">(18:18:59) </FONT><B>eks:</B></FONT> if I press ALT but no other keys on my real keyboard, FreeDOS does'nt see any key being pressed (int 9 not called)
<BR>
<FONTSIZE="2">(18:19:30) </FONT><B>eks:</B></FONT> if I hold ALT and press F, FreeDOS goes into this int 9 and then tries to set the timer (god only knows why)
<BR>
<FONTSIZE="2">(18:19:37) </FONT><B>eks:</B></FONT> it's there that it gets stuck
<BR>
<FONTSIZE="2">(18:20:00) </FONT><B>wli:</B></FONT> it's supposed to get the scancode for the real key not long after
<BR>
<FONTSIZE="2">(18:20:59) </FONT><B>bryce2:</B></FONT> it seems wrong that the ALT doesn't cause a keyboard event, so maybe we should solve that and then see if it helps.
<BR>
<FONTSIZE="2">(18:21:30) </FONT><B>eks:</B></FONT> maybe it's the ION window manager :P
<BR>
<FONTSIZE="2">(18:22:24) </FONT><B>eks:</B></FONT> *sigh*, running bochs with IPS: 1000 is painful...
<BR>
<FONTSIZE="2">(18:23:27) </FONT><B>bryce2:</B></FONT> simulate a 1khz pentium. nice.
<BR>
<FONTSIZE="2">(18:25:19) </FONT><B>eks:</B></FONT> IPS=10000 makes the ALT in console work
<FONTSIZE="2">(18:39:10) </FONT><B>eks:</B></FONT> here's the behaviour I'm experiencing here
<BR>
<FONTSIZE="2">(18:39:27) </FONT><B>eks:</B></FONT> if I press a key, int 0x09 is called right away
<BR>
<FONTSIZE="2">(18:39:38) </FONT><B>eks:</B></FONT> if I press left ALT, int 0x09 is also called right away
<BR>
<FONTSIZE="2">(18:40:12) </FONT><B>eks:</B></FONT> if I press left ALT + f, int 0x09 is called for the ALT like usual, but as soon as the f comes in, it enters a "waiting for timer" loop
<BR>
<FONTSIZE="2">(18:40:20) </FONT><B>eks:</B></FONT> if I press more keys, they do not even generate an interrupt
<BR>
<FONTSIZE="2">(18:40:34) </FONT><B>eks:</B></FONT> after a while (like 3 seconds), the keyboard works again
<FONTSIZE="2">(19:26:41) </FONT><B>wli:</B></FONT> it's not mentioned in vol3 except for a one-liner saying they may exist
<BR>
<FONTSIZE="2">(19:26:58) </FONT><B>wli:</B></FONT> depends on if CONFIG_MULTIQUAD depends on them
<BR>
<FONTSIZE="2">(19:33:55) </FONT><B>eks:</B></FONT> bryce2: if I press ALT+<something> in the console, the ALT is generated and seems to be handled properly, but the keyboard does not generate the <something> make/break code
<FONTSIZE="2">(19:34:33) </FONT><B>eks:</B></FONT> bryce2: the EOI did receive the 0x20 on port 0x20
<BR>
<FONTSIZE="2">(19:34:34) </FONT><B>bryce2:</B></FONT> so you think it's a keyboard.cc problem, rather than software emulation/timing/etc?
<BR>
<FONTSIZE="2">(19:34:37) </FONT><B>eks:</B></FONT> and the keyboard _is_ enabled
<BR>
<FONTSIZE="2">(19:35:16) </FONT><B>eks:</B></FONT> yes, most likely, keyboard.cc or gui
<BR>
<FONTSIZE="2">(19:35:34) </FONT><B>eks:</B></FONT> I have to re-run the same tests with more debugging output though
<BR>
<FONTSIZE="2">(19:35:57) </FONT><B>bryce2:</B></FONT> once you turn on the PIT, the log is huge :)
<BR>
<FONTSIZE="2">(19:37:04) </FONT><B>eks:</B></FONT> well, my cpu trace is actually 147MB and the out.bochs like 40MB :p
<BR>
<FONTSIZE="2">(19:37:19) </FONT><B>bryce2:</B></FONT> it sounds like the missing <something> should be visible (well, not visible) if you just turn on the keyboard debugging. right?
<BR>
<FONTSIZE="2">(19:37:36) </FONT><B>eks:</B></FONT> debugging was on, I'm studying the out.bochs atm
<BR>
<FONTSIZE="2">(19:37:52) </FONT><B>bryce2:</B></FONT> I won't ask you to send those to me ;)
<BR>
<FONTSIZE="2">(19:37:56) </FONT><B>bryce2:</B></FONT> I'll just make my own
<BR>
<FONTSIZE="2">(19:38:33) </FONT><B>bryce2:</B></FONT> the <something> is getting lost between the time you type it and.....your interrupt 0x9 breakpoint?
<BR>
<FONTSIZE="2">(19:38:42) </FONT><B>eks:</B></FONT> btw, the timings are not perfectly in sync between the cpu trace and the bochs.out file :p
<BR>
<FONTSIZE="2">(19:39:00) </FONT><B>bryce2:</B></FONT> ugh, I thought we fixed that....
<BR>
<FONTSIZE="2">(19:39:09) </FONT><B>eks:</B></FONT> bryce2: they are +3 in the bochs.out :p
<FONTSIZE="2">(19:39:48) </FONT><B>bryce2:</B></FONT> the <something> is getting lost between the time you type it and.....your interrupt 0x9 breakpoint?
<FONTSIZE="2">(19:41:33) </FONT><B>bryce2:</B></FONT> ok
<BR>
<FONTSIZE="2">(19:41:39) </FONT><B>eks:</B></FONT> bryce2: the scancode for the ALT is properly passed, but the scancode for the accompanying letter is not
<BR>
<FONTSIZE="2">(19:41:48) </FONT><B>bryce2:</B></FONT> are you testing in the console?
<BR>
<FONTSIZE="2">(19:42:15) </FONT><B>eks:</B></FONT> testing in X
<BR>
<FONTSIZE="2">(19:42:16) </FONT><B>bryce2:</B></FONT> boot the image, press ALT, press F and the F scancode is lost?
<BR>
<FONTSIZE="2">(19:42:25) </FONT><B>eks:</B></FONT> if you do:
<BR>
<FONTSIZE="2">(19:42:27) </FONT><B>bryce2:</B></FONT> right. X11 gui. I meant the freedos console
<BR>
<FONTSIZE="2">(19:42:28) </FONT><B>eks:</B></FONT> press and release alt
<BR>
<FONTSIZE="2">(19:42:31) </FONT><B>eks:</B></FONT> press F
<BR>
<FONTSIZE="2">(19:42:33) </FONT><B>eks:</B></FONT> both are going ok
<BR>
<FONTSIZE="2">(19:42:39) </FONT><B>eks:</B></FONT> if you do:
<BR>
<FONTSIZE="2">(19:42:45) </FONT><B>eks:</B></FONT> press and hold alt, press f
<BR>
<FONTSIZE="2">(19:42:50) </FONT><B>eks:</B></FONT> the alt goes thru, the f does not
<BR>
<FONTSIZE="2">(19:42:53) </FONT><B>bryce2:</B></FONT> ok
<BR>
<FONTSIZE="2">(19:43:00) </FONT><B>bryce2:</B></FONT> what's the breakpoint for int9?
<FONTSIZE="2">(20:10:08) </FONT><B>cbothamy:</B></FONT> Does anybody know if there are specific BIOS device numbers for atapi cdroms ? Or do they get a harddisk-type number (>=0x80) ?
<BR>
<FONTSIZE="2">(20:10:29) </FONT><B>eks:</B></FONT> cbothamy: they get floppy numbers
<BR>
<FONTSIZE="2">(20:10:44) </FONT><B>cbothamy:</B></FONT> eks: no kidding ?
<BR>
<FONTSIZE="2">(20:10:45) </FONT><B>eks:</B></FONT> cbothamy: at least at bootup
<BR>
<FONTSIZE="2">(20:11:08) </FONT><B>eks:</B></FONT> cbothamy: if you want to boot with a CDROM it will get a code 0x00 to 0x04 depending on how many floppies you have
<BR>
<FONTSIZE="2">(20:11:56) </FONT><B>cbothamy:</B></FONT> eks: ok, that's when you boot from a floppy-on-cd. But you can also use regular int13 access to cd sectors.
<BR>
<FONTSIZE="2">(20:12:41) </FONT><B>eks:</B></FONT> cbothamy: not sure about after bootup, but my guess is that the cd is still viewed as a floppy from a BIOS point of view
<BR>
<FONTSIZE="2">(20:14:36) </FONT><B>eks:</B></FONT> bryce2: ok.. like you said.. without the debugger interferring in my window management I do get the proper enQ() generated
<BR>
<FONTSIZE="2">(20:14:46) </FONT><B>eks:</B></FONT> bryce2: so that part should be alright
<BR>
<FONTSIZE="2">(20:15:13) </FONT><B>bryce2:</B></FONT> I also get the right enQ() sequence for Alt-F when running EDIT
<BR>
<FONTSIZE="2">(20:15:41) </FONT><B>bryce2:</B></FONT> on the console, I notice that after pressing alt-F the kbd seems to freeze for a little while
<FONTSIZE="2">(20:46:33) </FONT><B>eks:</B></FONT> bryce2: I'm 99% sure that the AD/AE is done by the BIOS, because the _exact_ same method is used to check if it was fired by IRQ 1 or not
<FONTSIZE="2">(21:16:02) </FONT><B>eks:</B></FONT> sure, I'll check it in
<BR>
<FONTSIZE="2">(21:16:49) </FONT><B>wli:</B></FONT> my 8 cpu BIOS stuff doesn't come anywhere near that part of the BIOS -- should be no conflicts (or even fuzz).
<BR>
<FONTSIZE="2">(21:18:31) </FONT><B>bryce2:</B></FONT> now I can revert my local change in exception.cc: if (vector==9) BX_INFO(("interrupt(): vector = %u, INT = %u, EXT = %u",(unsigned) vector, (unsigned) is_INT, (unsigned) BX_CPU_THIS_PTR EXT));
<FONTSIZE="2">(21:42:55) </FONT><B>bryce2:</B></FONT> wli: I just applied your 8cpu patch
<BR>
<FONTSIZE="2">(21:43:16) </FONT><B>wli:</B></FONT> bryce: sounds good
<BR>
<FONTSIZE="2">(21:43:20) </FONT><B>bryce2:</B></FONT> I don't think the keyboard change that eks and I were just working on will affect the I/O apic problems
<BR>
<FONTSIZE="2">(21:43:46) </FONT><B>bryce2:</B></FONT> it solved a problem of keyboard freezes in some DOS applications
<BR>
<FONTSIZE="2">(21:44:09) </FONT><B>wli:</B></FONT> bryce: well, I can field problem reports for the 8 cpu thing related to APIC ID unhappiness if the issue arises
<BR>
<FONTSIZE="2">(21:44:40) </FONT><B>bryce2:</B></FONT> in the other patch, I don't understand why you needed
<FONTSIZE="2">(21:45:14) </FONT><B>wli:</B></FONT> bryce: overkill -- is_32 was set to a stack address and I got paranoid
<BR>
<FONTSIZE="2">(21:45:15) </FONT><B>bryce2:</B></FONT> instead of unsigned os_32, as_32
<BR>
<FONTSIZE="2">(21:46:03) </FONT><B>wli:</B></FONT> bryce: the real issue is something silently clobbering the variable, it's 100% workaround, they should all be boolean (i.e. 0 or 1) regardless of type.
<BR>
<FONTSIZE="2">(21:47:03) </FONT><B>bryce2:</B></FONT> what do you mean by "is_32 was set to a stack address"?
<BR>
<FONTSIZE="2">(21:47:19) </FONT><B>bryce2:</B></FONT> your change didn't change that
<FONTSIZE="2">(21:49:52) </FONT><B>bryce2:</B></FONT> you might try linking with electric fence or some other memory checker
<BR>
<FONTSIZE="2">(21:50:00) </FONT><B>bryce2:</B></FONT> -lefence, it's installed on redhat
<BR>
<FONTSIZE="2">(21:50:16) </FONT><B>bryce2:</B></FONT> and it takes over your malloc
<BR>
<FONTSIZE="2">(21:50:39) </FONT><B>wli:</B></FONT> whatever methods are required to find it will surely be laborious, efence just breaks assumptions more readily
<BR>
<FONTSIZE="2">(21:51:32) </FONT><B>wli:</B></FONT> I think I documented that in the "one giant patch" version of it
<BR>
<FONTSIZE="2">(21:51:41) </FONT><B>bryce2:</B></FONT> now the change in ioapic to allow an id>=16
<BR>
<FONTSIZE="2">(21:51:50) </FONT><B>bryce2:</B></FONT> is that specific to P4's or anything?
<BR>
<FONTSIZE="2">(21:52:18) </FONT><B>wli:</B></FONT> I think it is, if I fix the ioapic ID to 0xe instead of 0x11 it should no longer be necessary
<BR>
<FONTSIZE="2">(21:52:25) </FONT><B>bryce2:</B></FONT> ok
<BR>
<FONTSIZE="2">(21:53:19) </FONT><B>***arashi</B></FONT> is away: sleeping roommate
<BR>
<FONTSIZE="2">(21:53:22) </FONT><B>bryce2:</B></FONT> when we start coding things that should act differently on ppros and p4s or whatever, let's think about adding a new cpu level
<BR>
<FONTSIZE="2">(21:53:36) </FONT><B>bryce2:</B></FONT> or apic behavior switch
<BR>
<FONTSIZE="2">(21:53:46) </FONT><B>bryce2:</B></FONT> or something
<BR>
<FONTSIZE="2">(21:54:14) </FONT><B>wli:</B></FONT> the only piece I'm missing for that is I don't know how to add new config options to autoconf stuff
<BR>
<FONTSIZE="2">(21:54:45) </FONT><B>bryce2:</B></FONT> you edit configure.in and then run autoconf
<BR>
<FONTSIZE="2">(21:54:49) </FONT><B>bryce2:</B></FONT> to produce a new configure script
<BR>
<FONTSIZE="2">(21:55:11) </FONT><B>wli:</B></FONT> I winged the extra case for 8 cpu's, in general I don't know syntax.
<BR>
<FONTSIZE="2">(21:55:12) </FONT><B>bryce2:</B></FONT> I just follow the examples, or if I'm really desperate I read "info autoconf"
<BR>
<FONTSIZE="2">(21:55:17) </FONT><B>bryce2:</B></FONT> me either :)
<BR>
<FONTSIZE="2">(21:55:24) </FONT><B>bryce2:</B></FONT> it's a shell script with m4 macros. yuck.
<BR>
<FONTSIZE="2">(21:56:00) </FONT><B>bryce2:</B></FONT> I will check in 06_8_cpu_workarounds in patches
<BR>
<FONTSIZE="2">(21:56:28) </FONT><B>bryce2:</B></FONT> but I really don't like the is_32 stuff to avoid stack corruption, as you can imagine
<BR>
<FONTSIZE="2">(21:56:48) </FONT><B>wli:</B></FONT> I don't dare advertise it as clean or even truly a "fix"
<BR>
<FONTSIZE="2">(21:57:30) </FONT><B>bryce2:</B></FONT> I assume you tried make dist-clean, configure, make?
<FONTSIZE="2">(21:57:55) </FONT><B>bryce2:</B></FONT> if there are broken compile dependencies, sometimes make fails to recompile some .o's
<BR>
<FONTSIZE="2">(21:58:05) </FONT><B>bryce2:</B></FONT> leading to disagreements over where the object fields can be found.
<BR>
<FONTSIZE="2">(21:58:25) </FONT><B>bryce2:</B></FONT> also, I find that sometimes the debugger lies about local variables
<BR>
<FONTSIZE="2">(21:58:32) </FONT><B>bryce2:</B></FONT> and says they have junk values.
<BR>
<FONTSIZE="2">(21:58:43) </FONT><B>bryce2:</B></FONT> adding a BX_INFO will tell for sure.
<BR>
<FONTSIZE="2">(21:59:24) </FONT><B>wli:</B></FONT> I got the local variable value from a coredump
<BR>
<FONTSIZE="2">(21:59:42) </FONT><B>bryce2:</B></FONT> I have a feeling the debugger has trouble with -fomit-frame-pointer, but I could be imagining it.
<BR>
<FONTSIZE="2">(21:59:50) </FONT><B>wli:</B></FONT> oh it does
<BR>
<FONTSIZE="2">(21:59:55) </FONT><B>wli:</B></FONT> I didn't use that option
<BR>
<FONTSIZE="2">(22:00:49) </FONT><B>wli:</B></FONT> could also be miscompiling, codegen does have a few holes in it as seen in the kernel, could be getting hit here as well.
<BR>
<FONTSIZE="2">(22:01:21) </FONT><B>bryce2:</B></FONT> I'm checking in your workarounds on top of patch.smp-8cpu-etc
<BR>
<FONTSIZE="2">(22:01:24) </FONT><B>bryce2:</B></FONT> is that ok?
<FONTSIZE="2">(22:01:39) </FONT><B>bryce2:</B></FONT> the rombios and configure.in changes are already committed
<BR>
<FONTSIZE="2">(22:01:48) </FONT><B>wli:</B></FONT> it ought to make some of the issues arising more visible.
<BR>
<FONTSIZE="2">(22:01:53) </FONT><B>bryce2:</B></FONT> so the remaining workarounds will be in patch.smp-8cpu-etc
<BR>
<FONTSIZE="2">(22:02:34) </FONT><B>bryce2:</B></FONT> ok
<BR>
<FONTSIZE="2">(22:02:38) </FONT><B>bryce2:</B></FONT> I'm off to do my taxes!
<BR>
<FONTSIZE="2">(22:02:55) </FONT><B>wli:</B></FONT> hopefully with more code going around for the stuff people will try it and drop code to help out, or poke it in ways I didn't before so I can debug. =)
