(15:54:41) darkito: thefreak : what is your favourite classical music composer?
(15:54:51) darkito: wb bryce2 :)
(15:55:33) bryce2: Chopin, Rachmaninoff, Debussy, Ravel
(15:55:54) thefreak: darkito: grieg for his beautifull music, bach for his great mathematical compositions, mozart cause he can make the simple sound great, etc.
(15:56:04) darkito: mine Bach, Haynd...
(15:56:36) thefreak: Ever read Hofstadters Gödel, Escher, Bach?
(15:58:06) darkito: no.. what's that?
(15:59:33) ***darkito listens to schubert - rosamunda "intermezzo"
(15:59:34) thefreak: 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.
(16:00:58) darkito: oh
(16:01:17) darkito: you're a classical music gooroo
(16:01:22) ***thefreak actually owns a copy of Classical Music for Dummies (it's better than you'd think)
(16:01:46) bryce2: Sun Apr 7 20:01:42 UTC 2002
(16:02:09) thefreak: you're suggesting a change in topic?
(16:02:12) bryce2: :)
(16:02:15) darkito: ahm... I didn't read a book about classical music
(16:02:21) darkito: heh
(16:02:41) darkito: heh
(16:02:51) bryce2: I assume people have been testing out Bochs 1.4, based on the
(16:03:01) bryce2: 20 thousand people who have downloaded it from SF.
(16:03:33) darkito: (I think if bach was alive he would be a black-metal composer <- last note :)
(16:03:38) darkito: bryce2 oh...
(16:04:07) wli: heh
(16:04:11) wli: did I miss it yet?
(16:04:32) bryce2: Has anyone found any problems that didn't exist before? or new features that should work but don't?
(16:04:38) thefreak: 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)
(16:05:02) wli: Did I miss the discussion?
(16:05:08) bryce2: wli: no we just started
(16:05:12) wli: phew
(16:05:37) darkito: Bochs x86 Emulator 1.2.1
(16:05:53) darkito: I use that one
(16:05:53) darkito: :\
(16:07:19) bryce2: who has gotten VBE to work?
(16:07:52) japj: i do :)
(16:07:52) bryce2: I haven't seen a disk image with a VBE X windows server yet
(16:08:00) bryce2: japj: I know you have. :)
(16:08:02) japj: who doesn't :)
(16:08:09) wli: What's VBE?
(16:08:30) japj: xfree86 4.x should have vbe driver
(16:08:46) cbothamy: wli : Vesa Bios Extensions
(16:08:58) thefreak: Even 3.x had a vbe driver, but it was painfully slow
(16:09:18) bryce2: there's a new debian 2.2r5 disk image on the site
(16:09:30) bryce2: 32meg download, 505meg disk image
(16:09:38) wli: um
(16:09:39) japj: thefreak: a generic vbe driver? from the release notes of Xfree86 4, they introduced it in 4
(16:09:48) wli: they can be manufactured pretty easily
(16:10:07) bryce2: we could start from that, install X free 4 in it
(16:10:10) thefreak: I believe that I used it back in the days, but it's off topic....
(16:10:26) bryce2: it would be great to get a working disk image with X windows on the site
(16:10:47) japj: yes indeed
(16:12:11) wli: it'd look flashy
(16:13:05) bryce2: How about keyboard mapping? Has Christophe's keymap code solved the problems of using bochs on a non-US keyboard?
(16:13:40) wli: I've got a Sun Type 6 keyboard and it sometimes doesn't recognize scancodes.
(16:14:00) wli: then again that goes for Linux and XF86 as well
(16:14:02) thefreak: I'm not quite satisfied with it, I might fix a swedish one one day, but it haven't bugged me enough yet though.
(16:14:11) bryce2: wli: what are some of the keys that don't work?
(16:15:57) wli: the crescent moon, the volume keys, and the stop/again/props/undo/front/copy/open/paste/find/cut, and help.
(16:16:09) wli: OTOH I've NFI what it would do with them...
(16:16:35) bryce2: 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
(16:16:39) bryce2: that's a point. :)
(16:16:42) slowcoder: 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 ?
(16:16:57) wli: I patched XF86 so it wouldn't crap the bed and now it passes along keycodes that 0 apps understand...
(16:17:08) bryce2: slowcoder: better ask japj :)
(16:17:22) slowcoder: Ah.
(16:17:30) slowcoder: japj: Did you get that ?
(16:17:34) japj: I will need to check the RH6.2 image on the site
(16:17:47) bryce2: slowcoder: and we'll need to know what is the panic message.
(16:18:08) wli: probably should be all separate patches
(16:18:14) slowcoder: I'm at another location right now, so I can't check it.. Sorry..
(16:18:17) japj: slowcoder: I hate to ask, but can you submit a bug on the sourceforge bug tracker on this?
(16:18:36) bryce2: hooray for the SF bug tracker
(16:18:47) slowcoder: japj: Sure, np.. I'll get some more info, and submit it
(16:19:38) bryce2: I tried to make "Paste" work in the precompiled binaries. Any luck with that?
(16:19:56) bryce2: Copy and Snapshot should work everywhere, but to get paste working you must turn on keyboard_mapping.
(16:21:12) wli: a copy key?
(16:21:21) wli: I think it's like SunCopy or something
(16:21:31) bryce2: wli: those little toolbar buttons on the top, ya know?
(16:21:39) wli: nm
(16:22:31) thefreak: 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...
(16:22:45) japj: bryce2: btw, why can't I do "bochs some_bochsrc_file"
(16:23:04) japj: and have bochs read the rc file
(16:23:34) bryce2: at one time, all command line options were treated just like bochsrc options
(16:23:54) bryce2: like bochs 'boot: c' 'vgaromimage: bios/VGABIOS-elpin-2.40'
(16:24:22) bryce2: I don't even know if it still works.
(16:24:36) japj: btw, I still get wxmain.cc:960:28: gdk/gdkkeysyms.h: No such file or directory .. do I need some gdk dev package?
(16:24:45) bryce2: it would make sense though
(16:25:22) bryce2: (he's talking about wxwindows if you're wondering)
(16:25:36) bryce2: japj: my gdk/gdkkeysyms.h is provided by a package gtk+-devel-1.2.6-7
(16:25:40) japj: (the bochs cpanel brand)
(16:26:18) bryce2: try grep GDK_Alt_L /usr/include/*/*.h to find it
(16:26:33) bryce2: if it's in a different directory or something
(16:26:48) japj: it's in /usr/include/gtk-1.2/gdk/gdkkeysyms.h
(16:27:15) cbothamy: There is one "bug" when you press the config button. The default answer is "10. Instruction tracing", i'd prefer it be "11. Continue"
(16:27:16) bryce2: ah I bet we need gtk-config --cflags or something
(16:27:29) bryce2: cbothamy: haha good point
(16:28:05) cbothamy: bryce2: i think it comes from the added "keyboard paste delay" option
(16:29:08) bryce2: cbothamy: I'll fix it.
(16:30:48) cbothamy: Has anybody had "keyboard stuck" problem with dos 6.2 ? Or is it just french dos 6.2 ?
(16:31:03) bryce2: [ 466292 ] kbd fails in scandisk, freedos edit
(16:31:22) bryce2: 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.
(16:31:26) bryce2: ?
(16:31:58) japj: the keyboard is 'systematicly' not responding in certain cases
(16:32:03) cbothamy: I fixed two missings functions in the bios yesterday because of this problem.
(16:32:32) japj: (or mabye 'was' not responding ... need to recheck after those changes)
(16:32:50) bryce2: cbothamy: do you have any suggestions on how to debug stuck keyboards?
(16:33:09) cbothamy: bryce2: can you check with current bios ? you will have to recompile it though
(16:33:10) eks: bryce2: do a trace on the keyboard port and keyboard functions
(16:33:16) japj: bryce2: I can boot that debian image, what was the idea?
(16:34:11) bryce2: eks: I have tried that, and everything looks the same when the keyboard works and when it's stuck.
(16:34:41) bryce2: japj: the idea was to install XFree4 in that image and try to run it with VBE
(16:34:51) eks: bryce2: the only other thing I see that could make it "stuck" is if the IRQ line was not lowered/raised under certain circonmstances
(16:34:54) slowcoder: japj: (With regards to the VBE "issue") would the CVS version have any improvements compared to the 1.4 release ?
(16:35:43) japj: current cvs has LFB patched already applied, 1.4 doesn't (but they both need the additional vbebios from patches/ somefile.tar.gz)
(16:35:44) wli: logging how irq's are raised/lowered
(16:35:47) wli: ?
(16:36:07) slowcoder: japj: Ok, but there hasn't been any changes in the code ?
(16:36:08) cbothamy: bryce2: no, i never had such problems before. Anyway, the fix is just for the key.com dos program
(16:36:19) bryce2: 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
(16:36:25) japj: what's vfb.o (in /lib/modules/.../video , is it a vesa framebuffer driver?
(16:36:46) Ciaran: Hi.
(16:36:58) japj: slowcoder: no, not yet there are some other things that need to fixed first
(16:37:16) slowcoder: japj: Okay
(16:37:22) wli: I ran into something weird while trying to make clustered mode work...
(16:37:41) wli: for some reason the APIC LVT timer behaved weirdly
(16:37:46) Ciaran: I guess I'm too late for the IRC meeting...
(16:37:48) wli: first it delivered int 0
(16:37:54) wli: which I didn't see before
(16:38:04) japj: Ciaran: no, it's still running
(16:38:07) wli: then it didn't deliver more than a few times
(16:38:08) cbothamy: Ciaran: no, it's just now
(16:38:17) Ciaran: Oh, cool.
(16:38:56) japj: bryce2: does the redhat 62 image also have an bochsrc?
(16:39:20) eks: bryce2: is there an image of freedos available for download somewhere?
(16:39:24) bryce2: I don't know. Psyon probably has one
(16:39:34) slowcoder: Who put together the RH6.2 image ?
(16:39:54) bryce2: I forget if psyon created it, or he got it from someone and uploaded it.
(16:39:59) bryce2: do you need help guessing the diskc line?
(16:40:18) bryce2: eks: http://bochs.sourceforge.net/guestos/freedos-img.tar.gz
(16:40:27) slowcoder: bryce2: There's an issue with it.. The root-password is unknown.. I had to mess around with it quite a bit..
(16:40:34) bryce2: haha
(16:41:28) bryce2: slowcoder: try "bochs" or "redhat"
(16:41:39) bryce2: I think it may be Michael Calabrese's image.
(16:41:51) slowcoder: bryce2: I tried bochs.. Didn't think of "redhat" though
(16:41:53) thefreak: Why don't you simply mount the image and edit the passwd file?
(16:41:57) bryce2: I remember that...I had to boot a floppy, edit the password file, etc.
(16:42:22) slowcoder: thefreak: 'linux single init=/bin/sh' is the "proper" way.. :)
(16:42:42) thefreak: slowcoder: let's not get religous :)
(16:43:05) bryce2: Did everybody see the survey results? I can paste them in here if you want.
(16:43:51) thefreak: how many voters was there?
(16:43:55) bryce2: only 13
(16:44:09) wli: I couldn't get to the survey thing, it required some kind of login, and it never sent me my passwd.
(16:44:14) bryce2: oops
(16:44:54) bryce2: it's a source forge survey, and I didn't think that it required you to log in.
(16:45:02) cbothamy: was it advertised on the main bochs site ? 13 answers is not a lot
(16:45:18) cbothamy: compared to 20K downloads
(16:45:18) bryce2: I sent it to the 400+ people on the bochs developers list
(16:45:27) bryce2: I know, it's a wimpy response
(16:45:36) bryce2: anyway :)
(16:45:39) wli: heh
(16:45:53) bryce2: everything is rated from 1 (not important) to 5 (most important)
(16:45:56) bryce2: 4.07 simulation speed improvements
(16:46:02) bryce2: 3.71 testing framework to compare Bochs against physical hardware
(16:46:06) bryce2: 3.71 full featured networking
(16:46:13) japj: bryce2: I can't seem to boot from the redhat image (it's stuck at LI (lilo bootloader))
(16:46:21) bryce2: 3.57 convert devices to plugins so bochs and plex86 can share code
(16:46:32) bryce2: 3.43 improve video emulation to allow better resolutions, more colors
(16:46:44) japj: bryce2: at least, with latest cvs that is
(16:46:48) bryce2: 3.00 regression testing to compare Bochs versions against each other
(16:46:51) bryce2: 3.00 improve documentation
(16:46:58) bryce2: 2.64 wxwindows graphical interface for configuration, debugger
(16:47:04) bryce2: etc.
(16:47:04) slowcoder: japj: Probably wrong CHS.. It's xxx / 63 / 16 (I can't remember how many bytes the image is..)
(16:47:39) japj: 512mb
(16:47:50) japj: 1040/16/63 CHS
(16:47:52) slowcoder: japj: Exact byte-count
(16:48:10) bryce2: I'm not surprised that simulation speed is the top of the list
(16:48:12) wli: I know what's #1 on my wishlist =)
(16:48:20) wli: (it ain't speed)
(16:48:24) japj: ls /cvs_wa/images/redhat6-512mb.img -la
(16:48:24) japj: -rw-rw-rw- 1 japj japj 528482304 Jun 1 2001 /cvs_wa/images/redhat6-512mb.img
(16:48:44) bryce2: however, I don't really think we should spend 75% of our time on speed
(16:48:57) thefreak:
(16:49:07) slowcoder: japj: 1024 / 16 / 63
(16:49:11) wli: 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.
(16:49:15) japj: nope, that won't work, but 1-3 people should definitely be looking at it
(16:49:25) bryce2: or something. We know that emulation is slow compared to virtualization
(16:50:06) bryce2: 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.
(16:50:44) wli: 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.
(16:50:48) cbothamy: Well, virtual PC can do it...
(16:51:12) bryce2: does virtual PC try to compile on 10 platforms?
(16:51:19) japj: slowcoder: yep that was it, so it's not actually a 512 mb image then?
(16:51:25) thefreak: wli: if you write 0.9 of it, we'll do the rest :)
(16:51:31) slowcoder: japj: Apparently not.. ;)
(16:51:43) wli: thefreak: natural number, not rational
(16:51:58) japj: hmm /dev/hda6 has gone too long unchecked :)
(16:52:10) slowcoder: japj: Yea, I like that it starts out with that..
(16:52:23) cbothamy: bryce2: Bochs is portable, that's a fact
(16:52:27) slowcoder: japj: Also note that you haven't got a clue of what the root-password is..
(16:52:38) thefreak: Can anyone tell me where you learn how to write a JIT-backend?
(16:52:40) bryce2: japj: since you're running mandrake 8.2 (ha I remembered), just run fsck natively
(16:52:42) wli: Any way I can shoehorn my own priorities in after that survey?
(16:52:55) wli: thefreak: the idea is obvious, the implementation is a nightmare.
(16:53:04) japj: bryce2: http://www.connectix.com/products/vpcw_wp_index.html
(16:53:12) slowcoder: bryce2: That wouldn't be a good idea, since it's a partitioned image.
(16:53:16) japj: slowcoder: probably empty :)
(16:53:24) slowcoder: japj: Guess again
(16:53:51) thefreak: wli: any problem is simple enough when you've learned how to break it down properly.. :)
(16:54:02) bryce2: 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. :)
(16:54:39) slowcoder: japj: After the fsck'ing, reboot and at the lilo-prompt, type: 'linux single init=/bin/sh' , and edit the /etc/passwd from there..
(16:54:47) japj: bryce2: I would like to have 'incremental write' images
(16:55:17) japj: but then a lot of tools won't work anymore
(16:55:20) bryce2: me too. [ 433171 ] patch disk image mode
(16:55:26) slowcoder: japj: That would be _great_ for trying out fses for experimental-oses.
(16:55:26) bryce2: http://sourceforge.net/tracker/index.php?func=detail&aid=433171&group_id=12580&atid=362580
(16:55:31) wli: 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...
(16:55:55) wli: thefreak: and you repeat the entire process once for every arch
(16:55:59) eks: bryce2: seems like the keyboard problem is present even in console mode, as soon as you press "ALT"...
(16:56:02) wli: thefreak: this is a true nightmare
(16:56:41) bryce2: eks: interesting. I hadn't noticed that one.
(16:56:51) japj: slowcoder: the redhat6 image root password is 'redhat'
(16:57:05) slowcoder: japj: Ah.. Nice.. Didn't try that.. :)
(16:57:06) eks: 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..
(16:57:28) bryce2: Here's an idea for simulation performance improvement. Let me know what you think...
(16:57:55) bryce2: Theory: bochs cannot run fast even on fast machines because it is absolutely full of branches which cannot be predicted right.
(16:57:56) thefreak: wli: can we get better speed in another way? Writing os/specific optimiztion is one other way..?
(16:58:12) wli: heck I don't know
(16:58:13) japj: how do I turn off mousegrabbing under linux? (in windows it's F12?)
(16:58:28) bryce2: When running code that is very frequently used, like a loop that executes over and over,
(16:58:54) slowcoder: japj: Third mousebutton
(16:59:23) bryce2: we "generate code" which is just the implementation of each instruction of the loop appended together
(16:59:25) japj: as far as I can see the redhat6 XFree, doesn't use VBE. It uses the standard vga adapter to display things
(16:59:41) japj: slowcoder: thanks :)
(17:00:01) bryce2: with no branches in between. Does anyone think that would make a difference?
(17:00:17) thefreak: bryce2: is the loop detection trivial?
(17:00:34) wli: Is this like tabulating function pointers by instruction address?
(17:01:12) bryce2: I'm thinking we identify regions of code memory that are used constantly, and spend some time (at runtime) trying to speed them up.
(17:01:19) ***eks wonders why freedos is stuck in a loop reprogramming the PIT after he presses ALT..
(17:01:22) wli: oic
(17:01:32) slowcoder: japj: I was booting the kernel with 'linux vga=????' to enable a framebuffer-console
(17:01:45) bryce2: wli: no I want to eliminate branches in the simulation, except for the branches in the guest code
(17:01:47) wli: I thought it was something different to avoid going through the decoder
(17:01:51) bryce2: for tight loops
(17:01:51) japj: 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)
(17:02:46) japj: I can't type ? in bochs :)
(17:03:00) japj: how do I turn it on?
(17:03:01) bryce2: japj: you need to write a keymap file for yourself
(17:03:32) slowcoder: japj: Wrong keymapping.. It's on '-' with a danish keyboard (if I recall correctly)
(17:03:34) ***wli wants cpu's ...
(17:03:46) thefreak: btyce2: I like the idea of trying to detect frequently used code and optimize it.
(17:04:09) bryce2: The reason I suggest this is that I was learning how event-driven simulators can often be replaced by
(17:04:23) slowcoder: japj: When I got the problem, I booted the kernel with 'linux vga=771', which indicates a 800x600x256 framebuffer
(17:05:03) bryce2: 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.
(17:05:51) cbothamy: bryce2: is this like transforming CISC to RISC microcode ?
(17:06:25) bryce2: sort of, yes.
(17:06:48) bryce2: but I think we can use the compiler+assembler to produce the "microcode" in the form of native instructions on your machine
(17:07:13) darkito: hi
(17:08:00) ***wli wants lots of cpu's =)
(17:08:16) darkito: :)
(17:08:17) bryce2: 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.
(17:08:20) japj: slowcoder: I get the linux fb penguin in the left upper corner (running under gdb)
(17:08:26) ***darkito wants tons of knowledgements
(17:08:37) japj: slowcoder: (so it doesn't kill itself right away)
(17:08:59) slowcoder: japj: I didn't get that.. It just changed the size of the bochs-window, and everything was black..
(17:09:11) japj: bryce2: how do I turn on debug symbols?
(17:09:15) slowcoder: japj: And that's with the CVS version?
(17:09:20) japj: yes
(17:09:35) bryce2: japj: if using .conf.linux to configure, edit it and add "-g" to the CFLAGS/CXXFLAGS
(17:09:38) slowcoder: japj: Okay.. Looks like I brainfarted somewhere then..
(17:09:52) bryce2: otherwise export CFLAGS=-g; export CXXFLAGS=-g before running configure.
(17:10:11) japj: slowcoder: no, not entirely :) .. it still crashes (but using gdb, I saw the initial logo drawn correcltly ... after that it segfaults)
(17:10:20) thefreak: bryce2: 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...?
(17:10:43) slowcoder: japj: Still want me to submit the bug to sf ?
(17:11:00) japj: yep, especially mentioning the vga=711 things
(17:11:13) bryce2: thefreak: nothing about simulating virtual machines this way. I bet there are papers on JIT compilers for java that talk about it
(17:11:22) slowcoder: japj: Will do... (Tomorrow)
(17:11:26) wli: for 32-way SMP all you need is clustered APIC mode, more xAPIC stuff in odd places, and *goat's blood*.
(17:11:30) japj: I'm going to rerun lilo on the image (so I won't have to type it in everytime :)
(17:11:50) bryce2: thefreak: but no I don't have anything to back me up. (YET) :)
(17:12:08) wli: any idea why the local APIC timer would wig out?
(17:12:21) thefreak: bryce2: as java has overused the JIT acronym, it's hard to find anything theoretical enough in all the junk out on the net :)
(17:12:39) thefreak: bryce2: don't drop the idea
(17:12:43) bryce2: cbothamy: should we talk about the ideas for I/O device plugins?
(17:13:32) bryce2: cbothamy: and how to get shared code between bochs and plex?
(17:13:48) cbothamy: bryce2: ok
(17:14:13) thefreak: 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?
(17:14:19) bryce2: thefreak: I personally think bochs should most of its spend its time worrying about correctness rather than speed.
(17:15:03) bryce2: Christophe Bothamy and Volker Ruppert have been working on porting the bochs devices that we've been working on for a year into plex86.
(17:15:47) wli: me too
(17:16:36) thefreak: bryce2: well, I fully respect that, but I want speed! :) (i can't force you to do it for me though...)
(17:17:19) bryce2: 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.
(17:18:01) cbothamy: Log messages are ok
(17:18:34) cbothamy: The idea for plugins is to remove all direct inter-device access.
(17:20:05) cbothamy: In plex this is done by "registering" a plugin global function for each inter-device operation, (ie raise IRQ)
(17:20:05) thefreak: how much inter-device access is there today?
(17:20:05) wli: real hw rarely does that anyway
(17:21:12) cbothamy: thefreak: cmos, timers are accessed by a few devices, IRQ by nearly all,
(17:21:27) thefreak: cbothamy: what about dma?
(17:21:46) japj: how do I display a local variable in gdb? (I'm used to VC6 :)
(17:22:01) bryce2: japj: print n
(17:22:15) cbothamy: thfreak: yes, dma as well for devices using dma ;-)
(17:22:25) japj: bryce2: how can I print it in hex?
(17:22:31) japj: or signed?
(17:22:34) bryce2: japj: printf "%x\n", n
(17:22:38) japj: duh
(17:22:40) japj: :)
(17:22:51) eks: bryce2: I think I know what is happening
(17:23:04) eks: bryce2: about that problemw ith the keyboard in freedos
(17:23:07) thefreak: cbothamy: how does bochs handle this?
(17:23:33) thefreak: cbotamy: never mind *reading back*
(17:23:46) bryce2: eks: great! what?
(17:23:46) eks: bryce2: some code sends a "keyboard disable" command to the emulated keyboard, but never re-enables it
(17:24:05) cbothamy: thefreak: In Bochs, the access is done by directly referencing methods on the objects.
(17:24:11) eks: bryce2: problem is, the code that sends the keyboard disable (0xAD) to port 0x64 is in the bios....
(17:24:57) cbothamy: thefreak: example BX_FD_THIS devices->pic->lower_irq(6);
(17:25:03) thefreak: cbothamy: i personally think the bochs way is awful compared to the pluginmode, it generates lots of depencies which we really don't need.
(17:25:13) bryce2: thefreak: amen
(17:25:25) cbothamy: thefreak: bryce2 fully agrees
(17:25:39) thefreak: cbothamy: i've had a few such problems when trying to implement 3c509 support, eth and ne2k is separated, but not completely.. for example.
(17:25:48) bryce2: thefreak: I think we should be replacing "BX_FD_THIS devices->pic->lower_irq(6)"
(17:26:13) bryce2: with a macro call such as BX_LOWER_IRQ(6) or something
(17:26:45) thefreak: bryce2: AAAAHHHRRRGG!!! If we're going to use an oo language, why not use the features on it instead on ugly macros?
(17:26:56) bryce2: 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.
(17:27:07) bryce2: thefreak: plex86 is a C program
(17:27:18) thefreak: bryce2: point taken
(17:27:32) bryce2: thefreak: bochs is a C++ program which doesn't use many features of C++
(17:28:13) bryce2: 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.
(17:28:16) thefreak: bryce2: I've actually wondered about that, why did you choose c++ when you're hardly using many of it features?
(17:28:25) bryce2: history
(17:28:31) bryce2: Kevin regrets changing to C++
(17:28:45) bryce2: but it's done and I don't think there's good enough reason to change back.
(17:29:19) cbothamy: If we use macros, the code could be shared as is between the two projects.
(17:29:35) bryce2: Using macros is very flexible. Anybody who wants to use our PIT can
(17:29:41) cbothamy: If we use macros, we can easily move to a plugin architecture
(17:29:42) japj: bryce2: I think I fixed the redhat6 fbdev bug (using linux vga=771 that slowcoder mentioned)
(17:29:47) thefreak: Implementing a emulator in oo-languages would lead to a beautiful implementation, but awfully slow.. And as I said I want speed! :)
(17:29:59) bryce2: just look at the header file, define the macros to do something reasonable in his simulation, and use it.
(17:30:47) bryce2: japj: sorry I wasn't following that conversation :) but I'm glad you found it.
(17:31:39) bryce2: cbothamy: do you and Volker need help with Macro-izing the devices, or do you have it under control?
(17:31:53) wli: the receive stimulus / transition between states / wait paradigm is fine
(17:32:07) cbothamy: bryce2: i guess we can handle it ;-)
(17:32:09) wli: OO is good for that
(17:32:15) bryce2: I think it makes sense to get the macros working in bochs&plex first
(17:32:30) bryce2: then start to add plugin support to Bochs
(17:32:33) thefreak: wli: agreed, interfaces and inheritance is also convenient.
(17:32:46) japj: I'm going to bed now (23:37 over here and I need to work early tomorrow)
(17:32:53) bryce2: (which will require a redefinition of the macros to make them more like plex's definitions)
(17:32:53) wli: hmm
(17:33:00) cbothamy: That's my idea as well. this sounds ok
(17:33:05) bryce2: cool
(17:33:12) japj: is someone logging this?
(17:33:18) japj: (so I can read back later)
(17:33:20) wli: there are a couple of devices that have been hounding me
(17:33:22) thefreak: I'm also leaving now, i'll have to be working before 08 am...
(17:33:54) bryce2: glad you could join us, japj and thefreak
(17:34:06) wli: rest easy japj
(17:34:06) thefreak: BTW. If you're interested... Linux now detects my 3c509 card, it doesn't actually do everything it should though..
(17:34:07) bryce2: we haven't talked about the testing framework ideas yet
(17:34:09) wli: thefreak too
(17:34:18) bryce2: thefreak: cool :) that's the first step!
(17:34:21) japj: bryce2: you're logging this?
(17:34:33) bryce2: japj: unless my client crashes again, yes :)
(17:34:42) japj: ok.. goodnight
(17:35:05) bryce2: regression testing should be a part of any sort of complex model, and we have absolutely nothing.
(17:35:32) wli: booting Linux is the closest thing I have
(17:35:44) wli: kind of imprecise
(17:35:58) bryce2: There are lots of different ways to approach it, from writing out a large log file of memory and I/O references
(17:36:08) thefreak: bryce2: 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
(17:36:09) wli: should be a bunch of executives around with canned tests
(17:36:19) bryce2: and comparing output from different versions
(17:37:06) wli: a full OS will generate quite a large trace
(17:37:08) bryce2: to writing guest OS code that searches for problems and returns a pass/fail, like wli just said
(17:38:15) bryce2: 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.
(17:38:33) bryce2: The full log is most useful for debugging, because yes it gets very long, but it's better than nothing!
(17:39:00) bryce2: Kevin also used simultaneous simulations of two bochses at once, doing comparison every once in a while, which he called co-simulation.
(17:39:06) bryce2: Any of these interest people?
(17:40:40) bryce2: 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.
(17:40:54) wli: um
(17:41:10) wli: the results from physical machines need logic analyzers to obtain
(17:41:27) bryce2: I mean results that can be detected using code
(17:41:31) wli: or circuit-level simulation of the verilog/whatever
(17:41:53) wli: nm
(17:42:29) wli: some of this is BIOS-dependent as well
(17:42:54) bryce2: 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.
(17:43:07) bryce2: figure out what's different, and adjust Bochs accordingly.
(17:43:36) wli: e.g. on NUMA-Q NMI's do stuff basically like startup IPI's in the BIOS
(17:43:48) wli: other boxen probably have other weird BIOS hacks
(17:43:59) bryce2: granted it doesn't work for everything
(17:44:20) bryce2: if would be great for testing accuracy of our floating point multiply or something.
(17:44:40) wli: that can be done in userspace anyway
(17:44:42) bryce2: or almost any other user-level instruction
(17:45:03) wli: singleshot instructions aren't a good example because there's an easy trapdoor =)
(17:45:25) bryce2: it would still be valuable to be able to test them!
(17:45:28) wli: true
(17:45:37) bryce2: even if it's not a challenge
(17:45:45) wli: userspace test harness for them etc.
(17:46:37) bryce2: talking about regression tests seems to have put nearly everyone to sleep, or driven them away :)
(17:47:49) wli: well
(17:47:52) bryce2: Did anybody see the wxwindows screen shot at http://bochs.sourceforge.net/tmp/wxwindows/wxbochs4.gif ?
(17:48:15) wli: any chance I can sneak in my ulterior motives / blatant plugs / whatever?
(17:48:57) bryce2: wli: sure.
(17:48:59) wli: looks like different widgets
(17:49:04) wli: alright
(17:49:24) wli: I want nasty scenarios to "be hostile to" kernels.
(17:49:31) bryce2: :)
(17:49:37) wli: there are 2 things, 1 more important than the other
(17:49:40) bryce2: for worst case races and things
(17:49:47) wli: #1 is tons of cpu's -- i.e. races right
(17:49:56) wli: #2 is fiddling with memory maps
(17:50:13) bryce2: can you clarify #2?
(17:50:35) wli: discontiguous memory maps have weird issues and under pressure the OS can crap itself believing it's out of mem when it isn't.
(17:51:08) wli: 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.
(17:51:11) Ciaran[zzz]: I have to go sleep now.
(17:51:14) Ciaran[zzz]: See ya. :)
(17:51:21) bryce2: good night
(17:51:44) Ciaran[zzz]: Is it okay for me to stay in here while I'm sleeping?
(17:51:46) wli: 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
(17:51:51) wli: I don't mind.
(17:52:01) bryce2: ciaran: we won't pour cold water on you.
(17:52:06) Ciaran[zzz]: Cool. :)
(17:52:09) Ciaran[zzz]: 'night then.
(17:52:17) Ciaran[zzz]: *poof*
(17:52:42) wli: 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.
(17:52:50) eks: bryce2: does the PIT support mode 0 ?
(17:53:24) wli: atm support for > 8 cpu's on i386 in Linux needs clustered APIC mode + various tidbits of weirdness
(17:53:44) bryce2: eks: based on 10 seconds of looking at pit.cc I think yes
(17:53:53) wli: Assuming there aren't architectural weirdnesses physical mode could be used for > 64 up to 255 on xAPICs
(17:53:59) bryce2: switch (BX_PIT_THIS s.timer[timerid].mode) { case 0: .... }
(17:54:05) eks: bryce2: hrm.. ok..
(17:55:05) bryce2: wli: I don't think it would be hard to simulate the discontinuous memory maps. I don't know much about it though.
(17:55:24) wli: 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...
(17:55:55) wli: Yeah the discontiguous memory map doesn't sound hard to me either, it's very much back burner for me.
(17:56:19) bryce2: eks: I didn't say it did mode 0 right necessarily :)
(17:56:31) wli: the way things come to light is for instance running dbench on an NFS-mounted filesystem on an SMP discontiguous memory machine.
(17:57:33) wli: 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.
(17:58:43) wli: 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.
(17:59:18) wli: there aren't enough clues to really tell why the in-service bit isn't getting cleared.
(17:59:26) bryce2: I see how bochs can be useful to see what's going on in some of these situations where the system gets unstable.
(17:59:57) wli: bryce: the greater parallelism exposes OS stability issues hidden by implicit serialization on smaller systems.
(18:00:02) bryce2: wli: I say, add lots more BX_DEBUGs :)
(18:00:39) wli: well, atm I don't really know if I'm working with the latest bits of APIC LVT code.
(18:00:54) bryce2: ?
(18:01:03) bryce2: I don't have any patches that aren't checked in
(18:01:14) wli: that answers it then; I am
(18:01:24) bryce2: :)
(18:01:39) wli: one question that arises is how it's been tested thus far;
(18:02:17) wli: 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
(18:02:35) eks: bryce2: on my system here it gets stuck in an infinite loop always reprogramming the PIT channel 0 for mode 0
(18:02:44) eks: bryce2: the loop is 25 instructions long
(18:03:03) wli: 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.
(18:03:16) eks: bryce2: keeps waiting for something to change on its stack
(18:03:29) wli: this is a workaround; the real fix is unclear
(18:03:32) eks: bryce2: so my guess is that it is waiting for the timer to act, but it never comes
(18:03:40) bryce2: eks: very strange.
(18:03:57) bryce2: eks: since we can get source to freedos edit, I wonder if that would shed some light on the behavior.
(18:04:14) eks: bryce2: I get the same behaviour from the console :/
(18:04:21) wli: 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.
(18:04:45) wli: And this is in flat logical destination format.
(18:05:16) wli: btw, do I need to separate out the parts of the 8-way patch that -aren't- workarounds so they can be included?
(18:05:38) bryce2: eks: hmm. did you turn on debugging on the PIC? maybe there are some clues just before it gets into the infinite loop.
(18:06:05) wli: the BIOS and configure.in stuff is trivial and has no bearing on quality of simulation for other configurations.
(18:06:40) bryce2: wli: I havent' had time to look at it more than a minute.
(18:07:04) bryce2: wli: which is the case for lots of things :(
(18:07:23) wli: so barring reviews for correctness of the other bits I should eliminate the bits that have any impact on simulation while < 8 cpu's are in use?
(18:07:55) wli: and leave the other stuff around so people can see what kinds of issues arise until real fixes are done?
(18:08:44) bryce2: yes, it will help me if you can split into two patches
(18:08:48) eks: bryce2: I'll compress the out.bochs and place it on my server, gimme a sec
(18:08:52) wli: on its way today
(18:09:24) bryce2: 1. things that you know are right, such as the 8-way cpu bios/configure changes
(18:09:37) bryce2: 2. workarounds, which I would want to leave in patches but not check in
(18:09:51) bryce2: eks: I doubt I'll be able to make sense of it, but I'll look :)
(18:10:02) eks: bryce2: I think the contrary :p
(18:10:31) eks: bryce2: is 1.2MB too big?
(18:10:35) bryce2: nope
(18:10:56) eks: bryce2: http://void-core.2y.net/out.bochs.bz2
(18:11:09) eks: bryce2: uncompress and go at the end of the log
(18:11:22) eks: look at the various [PIT ] entries
(18:11:29) eks: you will notice something quite anormal
(18:12:28) eks: the timer is "reset" continously, that's alright, but it never have the time to expire before the timer is set again
(18:13:22) bryce2: I wonder if you set ips = 10 million if the problem would go away
(18:13:34) eks: most likely the reverse, IPS=1 ;)
(18:13:42) bryce2: ah one of those
(18:13:50) wli: I should try something like 32M for the 32-way sim.
(18:13:50) eks: I'll give it a try
(18:13:56) wli: it might make issues go away
(18:13:58) bryce2: usually raising ips makes it more realistic
(18:14:44) wli: maybe 600M or something hopefully that won't overflow inside the sim
(18:14:54) wli: 5M * NR_CPUS
(18:15:23) bryce2: eks: can you see from the disassembly how this code EXPECTS to ever leave the loop?
(18:17:04) bryce2: does the inf loop start immediately after the ALT is pressed?
(18:17:47) eks: there's a CMP BX, SS:[BP + F9]
(18:18:37) eks: I think it's related to the X11 GUI too... here's what happen
(18:18:59) eks: if I press ALT but no other keys on my real keyboard, FreeDOS does'nt see any key being pressed (int 9 not called)
(18:19:30) eks: if I hold ALT and press F, FreeDOS goes into this int 9 and then tries to set the timer (god only knows why)
(18:19:37) eks: it's there that it gets stuck
(18:20:00) wli: it's supposed to get the scancode for the real key not long after
(18:20:59) bryce2: it seems wrong that the ALT doesn't cause a keyboard event, so maybe we should solve that and then see if it helps.
(18:21:30) eks: maybe it's the ION window manager :P
(18:22:24) eks: *sigh*, running bochs with IPS: 1000 is painful...
(18:23:27) bryce2: simulate a 1khz pentium. nice.
(18:25:19) eks: IPS=10000 makes the ALT in console work
(18:25:21) wli: 1KHz breaks timing algorithms
(18:25:35) eks: wli: quite what I wanted
(18:25:35) wli: Linux gets divide by 0
(18:26:03) bryce2: eks: when you say alt breaks in the console, what do you mean?
(18:26:13) bryce2: if I boot freedos, I get a command prompt
(18:26:17) bryce2: I type a few letters to test it
(18:26:24) bryce2: I press alt, release it, and type a few more
(18:26:34) bryce2: no problem. Is that what you see too?
(18:27:36) wli: what's Alt-F1 key combination do?
(18:28:40) bryce2: I can't see any freeze problems at the console, no matter how many times I press ALT or ALT-F.
(18:30:13) eks: alright, confirmed, X11 does not foward the "ALT" neither left or right when it is pressed alone
(18:30:36) eks: bryce2: darn
(18:30:56) bryce2: does for me
(18:30:58) bryce2: :)
(18:30:59) eks: I'll be right back, going to try with another window manager
(18:31:05) bryce2: X11 gui
(18:31:10) eks: yip, X11 giu
(18:33:49) eks: bryce2: same thing under blackbox and ion window manager
(18:33:54) eks: bochs is built with the X11 GUI
(18:34:04) eks: using the freedos-img that was on the bochs site
(18:34:06) bryce2: what you are looking at? debug messages from keyboard?
(18:34:32) eks: I put a breakpoint at the int 0x09 handler
(18:34:50) bryce2: ok
(18:35:18) bryce2: I need to go for a while. I can check back in an hour or so
(18:35:32) wli: later on
(18:35:37) bryce2: I think we're getting closer to figuring it out...
(18:35:53) bryce2: thanks
(18:35:55) bryce2: later
(18:37:40) eks: hrm..
(18:38:39) eks: ok...
(18:39:10) eks: here's the behaviour I'm experiencing here
(18:39:27) eks: if I press a key, int 0x09 is called right away
(18:39:38) eks: if I press left ALT, int 0x09 is also called right away
(18:40:12) eks: 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
(18:40:20) eks: if I press more keys, they do not even generate an interrupt
(18:40:34) eks: after a while (like 3 seconds), the keyboard works again
(18:40:41) wli: weird
(18:47:34) eks: hrm...
(18:59:21) eks: welll well well...
(18:59:41) eks: after I press ALT+, the keyboard keep generating ALT make/break continuously
(19:00:00) eks: the make/break is never sent..
(19:23:56) bryce2: back
(19:24:41) wli: re
(19:25:14) wli: I may have to introduce a cluster controller
(19:26:07) bryce2: I don't know nothin about that.
(19:26:16) wli: neither do I
(19:26:20) bryce2: :)
(19:26:41) wli: it's not mentioned in vol3 except for a one-liner saying they may exist
(19:26:58) wli: depends on if CONFIG_MULTIQUAD depends on them
(19:33:55) eks: bryce2: if I press ALT+ in the console, the ALT is generated and seems to be handled properly, but the keyboard does not generate the make/break code
(19:34:20) eks: bryce2: if=1, I've checked
(19:34:33) eks: bryce2: the EOI did receive the 0x20 on port 0x20
(19:34:34) bryce2: so you think it's a keyboard.cc problem, rather than software emulation/timing/etc?
(19:34:37) eks: and the keyboard _is_ enabled
(19:35:16) eks: yes, most likely, keyboard.cc or gui
(19:35:34) eks: I have to re-run the same tests with more debugging output though
(19:35:57) bryce2: once you turn on the PIT, the log is huge :)
(19:37:04) eks: well, my cpu trace is actually 147MB and the out.bochs like 40MB :p
(19:37:19) bryce2: it sounds like the missing should be visible (well, not visible) if you just turn on the keyboard debugging. right?
(19:37:36) eks: debugging was on, I'm studying the out.bochs atm
(19:37:52) bryce2: I won't ask you to send those to me ;)
(19:37:56) bryce2: I'll just make my own
(19:38:33) bryce2: the is getting lost between the time you type it and.....your interrupt 0x9 breakpoint?
(19:38:42) eks: btw, the timings are not perfectly in sync between the cpu trace and the bochs.out file :p
(19:39:00) bryce2: ugh, I thought we fixed that....
(19:39:09) eks: bryce2: they are +3 in the bochs.out :p
(19:39:14) eks: constantly
(19:39:24) bryce2: at least it's consistent. :)
(19:39:26) eks: probably the changes whoever did to the debugger trace
(19:39:34) bryce2: Greg I think
(19:39:37) eks: yea
(19:39:48) bryce2: the is getting lost between the time you type it and.....your interrupt 0x9 breakpoint?
(19:40:22) wli: hmm
(19:40:31) wli: does it compile yet?
(19:40:40) wli: wrong chan
(19:40:46) bryce2: wli: yes
(19:41:05) bryce2: wli: :)
(19:41:15) eks: bryce2: yip
(19:41:33) bryce2: ok
(19:41:39) eks: bryce2: the scancode for the ALT is properly passed, but the scancode for the accompanying letter is not
(19:41:48) bryce2: are you testing in the console?
(19:42:15) eks: testing in X
(19:42:16) bryce2: boot the image, press ALT, press F and the F scancode is lost?
(19:42:25) eks: if you do:
(19:42:27) bryce2: right. X11 gui. I meant the freedos console
(19:42:28) eks: press and release alt
(19:42:31) eks: press F
(19:42:33) eks: both are going ok
(19:42:39) eks: if you do:
(19:42:45) eks: press and hold alt, press f
(19:42:50) eks: the alt goes thru, the f does not
(19:42:53) bryce2: ok
(19:43:00) bryce2: what's the breakpoint for int9?
(19:43:09) eks: pb 0xd6d6
(19:43:11) bryce2: thx
(19:44:11) eks: lol, ViM died :p
(19:44:17) eks: too much work for it >:}
(19:44:17) bryce2: hahaha
(19:44:27) eks: -rw-r--r-- 1 eks eks 39411609 Apr 7 18:17 out.bochs
(19:44:36) bryce2: maybe less can handle it
(19:44:51) eks: huh.. not sure I want to go thru 600thousand lines with less :p
(19:45:03) bryce2: it doesn't have to load them all at once
(19:45:07) bryce2: you can skip to end fast, etc.
(19:45:29) bryce2: just an idea
(19:46:14) bryce2: eks: btw, what bios are you using?
(19:46:16) eks: -rw-r--r-- 1 eks eks 78223 Apr 7 18:46 out2
(19:46:29) eks: here, that's the part of the debug log which is interesting
(19:46:44) bryce2: eks: christophe was working on some keyboard thing in the BIOS very recently
(19:46:53) eks: http://void-core.2y.net/out.bochs
(19:46:55) eks: 78KB
(19:46:58) Exodus: *YAWN*
(19:47:14) eks: bryce2: hrm.. lemme check
(19:47:15) bryce2: exodus: you slept through the whole irc meeting :)
(19:47:24) Exodus: i did?
(19:47:27) Exodus: i just got off work
(19:47:28) cbothamy: bryce2: int 16 function 92h and A2h
(19:47:33) eks: bryce2: I'm using the one provided with the freedos image
(19:47:48) bryce2: exodus: ok, well I guess you worked right through the irc meetin :)
(19:47:50) bryce2: g
(19:48:14) eks: bryce2: 00075135051d[KBD ] READ(60) = 38
(19:48:18) eks: that's the ALT code
(19:48:33) bryce2: ok
(19:48:55) eks: there is no other READ(60) in this file, it was the only one
(19:49:33) bryce2: exactly what did you type in this run?
(19:49:35) eks: the only two writes to port 0x64 are 0xAD and 0xAE surrounding the read
(19:49:39) bryce2: cbothamy: thanks :)
(19:49:53) eks: bryce2: F1 ENTER ENTER ENTER ALT+F
(19:50:05) bryce2: cbothamy: I thought you were asleep
(19:50:07) eks: I hooked the d6d6 handler after the 3 enter
(19:50:37) cbothamy: bryce2: no, i'm trying to find out why win2k does not boot
(19:50:56) Exodus: cuz its made by MS?
(19:51:04) Exodus: hell Win2k on this computer doesnt boot all the time
(19:51:16) Exodus: when I restart I have to hit the reset button like 5 or 6 times before it decides to boot
(19:51:18) cbothamy: Exodus: of course ;-)
(19:51:29) Exodus: im serious
(19:51:41) Exodus: I refuse to restart this thing...
(19:51:50) Exodus: ive gone as long as an hour waiting for it to boot
(19:51:51) bryce2: eks: I don't know why there aren't READ(60)'s for the f1, 3xENTER
(19:51:55) Exodus: it just gets to a point and hangs
(19:51:57) Exodus: sometimes
(19:52:07) bryce2: did you turn on debug after that?
(19:52:11) eks: bryce2: lol, I stripped them out, they were in the first 39MB of log
(19:52:15) bryce2: right ok
(19:52:17) eks: bryce2: if you want them I can send ;)
(19:52:20) bryce2: NO!
(19:52:24) eks: :p
(19:52:27) cbothamy: Exodus: i don't really know because i've never installed or used it!
(19:52:39) bryce2: so this section shows the lack of the "F" scancode
(19:53:03) eks: bryce2: from what I get out of the bochs.out log is that the scancodes are encoded in the queue
(19:53:17) eks: 00075165000d[KBD ] gen_scancode(): scancode: 0000001f
(19:53:17) eks: 00075165000d[KBD ] enQ(26)
(19:53:17) eks: 00075165000d[KBD ] enQ: putting scancode 26 in internal buffer
(19:53:17) eks: 00075165000d[KBD ] activating timer...
(19:53:17) eks: 00075165000d[KBD ] keyboard: writing translated 26
(19:53:19) eks: 00075165000d[KBD ] gen_scancode 75165000 8000001f
(19:53:21) eks: 00075165000d[KBD ] gen_scancode(): scancode: 8000001f
(19:53:24) eks: 00075165000d[KBD ] enQ(a6)
(19:53:26) eks: 00075165000d[KBD ] enQ: putting scancode a6 in internal buffer
(19:53:29) eks: 00075165000d[KBD ] activating timer...
(19:53:32) eks: 00075165000d[KBD ] keyboard: writing translated a6
(19:55:33) eks: bryce2: when 'activating timer', shouldn't the keyboard be called again?
(19:57:26) bryce2: you'd think so
(19:57:48) bryce2: but only if timer_pending==0
(19:58:03) bryce2: I'm having a little trouble interpreting this.
(19:58:18) bryce2: there are two pairs of gen_scancode
(19:58:23) bryce2: gen_scancode 75150000 80000019
(19:58:31) bryce2: which results in enQ(a1)
(19:58:36) bryce2: and gen_scancode 75150000 80000012
(19:58:43) bryce2: which results in enQ(b8)
(19:58:54) bryce2: is that from the ALT?
(19:59:19) bryce2: or the F, or what?
(20:00:16) eks: b8 = release code for alt
(20:00:20) eks: a1 = release code for f
(20:00:32) eks: IIRC ;)
(20:00:53) bryce2: I got those VERY close together
(20:01:04) bryce2: in the same keyboard poll tick
(20:01:27) bryce2: then later gen_scancode 75165000 1f -> enQ(26)
(20:01:41) bryce2: and gen_scancode 75165000 8000001f -> enQ(a6)
(20:05:49) eks: hrm..
(20:05:54) eks: I think I know what's happening
(20:06:03) eks: if you search for the enQ()
(20:06:09) eks: you will get the following
(20:06:12) eks: 3B BB
(20:06:14) eks: 1C 9C
(20:06:15) eks: 1C 9C
(20:06:15) eks: 1C 9C
(20:06:21) eks: 38 38 21 B8
(20:06:29) eks: first is F1
(20:06:35) eks: the next 3 are 'Enter'
(20:06:41) eks: but, when I press ALT+F
(20:06:46) eks: instead of generating ALT and then F
(20:06:51) eks: it generates ALT ALT F
(20:07:05) eks: I'll retry to make sure the behaviour is constant
(20:07:06) bryce2: then B8 is the release of alt?
(20:07:12) eks: yip
(20:07:21) eks: and after B8 I have A1
(20:07:26) eks: no other B8 after that
(20:07:30) bryce2: interesting.
(20:08:58) bryce2: press ALT & hold, press F, release F, release ALT
(20:09:04) bryce2: I got 38 21 a1 b8
(20:09:16) eks: hrm..
(20:09:26) bryce2: I turned on debugging for all devices
(20:09:30) eks: must've been the debugger and the window switching
(20:09:33) bryce2: and then tail -f out.bochs | grep enQ
(20:09:44) eks: I had the debugger hooked to int 9
(20:10:04) bryce2: 20 megs and growing...
(20:10:05) bryce2: :)
(20:10:08) cbothamy: Does anybody know if there are specific BIOS device numbers for atapi cdroms ? Or do they get a harddisk-type number (>=0x80) ?
(20:10:29) eks: cbothamy: they get floppy numbers
(20:10:44) cbothamy: eks: no kidding ?
(20:10:45) eks: cbothamy: at least at bootup
(20:11:08) eks: cbothamy: if you want to boot with a CDROM it will get a code 0x00 to 0x04 depending on how many floppies you have
(20:11:56) cbothamy: eks: ok, that's when you boot from a floppy-on-cd. But you can also use regular int13 access to cd sectors.
(20:12:41) eks: 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
(20:14:36) eks: bryce2: ok.. like you said.. without the debugger interferring in my window management I do get the proper enQ() generated
(20:14:46) eks: bryce2: so that part should be alright
(20:15:13) bryce2: I also get the right enQ() sequence for Alt-F when running EDIT
(20:15:41) bryce2: on the console, I notice that after pressing alt-F the kbd seems to freeze for a little while
(20:15:48) eks: yes
(20:15:49) bryce2: but then in a few seconds it recovers
(20:15:51) eks: it does
(20:15:57) eks: that's the part where it's stuck in the timer loop
(20:16:05) eks: somehow after a while it manages to get out
(20:16:17) eks: but it's a very long loop
(20:16:24) eks: way too long to be normal IMO
(20:17:19) bryce2: rebuilding with debugger
(20:30:08) bryce2: eks: I think I know what that loop is!
(20:30:20) eks: ??
(20:30:32) bryce2: if you press ALT-F in freedos, I think it is trying to beep.
(20:30:45) eks: hrm...
(20:30:45) bryce2: During the beep, it doesn't accept any keystrokes, it's just in a busy wait loop
(20:30:56) eks: lol, could be
(20:30:58) bryce2: when the beep is over it starts accepting keys again
(20:31:06) eks: but how do you open the file menu in edit??
(20:31:38) bryce2: not sure
(20:31:45) bryce2: that is still broken
(20:31:54) bryce2: but I'm wondering if the freedos console is fine
(20:31:56) eks: now the question is..
(20:32:03) eks: is it a FreeDOS problem or a Bochs problem?
(20:32:17) bryce2: the keyboard is frozen in EDIT whether or not I type ALT.
(20:34:23) bryce2: the reason I think it's beeping is that
(20:34:25) eks: rombios bug?
(20:34:33) bryce2: several seconds after I press ALT-F on console I get
(20:34:39) bryce2: 00027272786i[PIT81] Changing GATE 2 to: 0
(20:35:19) bryce2: right after pressing the F, I see 00102273782i[PIT81] Changing GATE 2 to: 1
(20:35:30) bryce2: then after a few seconds, 00108272934i[PIT81] Changing GATE 2 to: 0
(20:35:38) bryce2: afaik that's a beep
(20:36:04) eks: eheh, we need to make a popup window with a "I'm emulating a beep here!" ;)
(20:37:02) bryce2: yeah, turning on the speaker would be bad. it would beep for 5 seconds
(20:37:04) eks: alright, so that explains the console
(20:37:11) bryce2: or if you put a breakpoint, it would beep forever :)
(20:37:14) bryce2: until you continue
(20:37:37) bryce2: I believe so
(20:39:46) cbothamy: bryce2: we had the same behavior with dos paste : beeps
(20:40:07) bryce2: Emulated beeping has become a top priority. :)
(20:40:31) bryce2: well, the beep was a symptom of the buffer overflow
(20:40:42) bryce2: I don't know if it was causing any problem.
(20:41:12) bryce2: eks: are you supposed to disable the keyboard before reading port 60, and then disable it?
(20:41:35) bryce2: eks: what would happen if you read port 60, then disabled the keyboard, then enabled it?
(20:41:40) eks: bryce2: no, you don't have to
(20:41:45) bryce2: since that's what EDIT seems to be doing....
(20:41:54) eks: hrm...
(20:42:02) eks: you mean reading disabling enabling?
(20:42:09) bryce2: yes
(20:42:16) bryce2: interrupt(): vector = 9, INT = 0, EXT = 1
(20:42:19) bryce2: READ(60) = 21
(20:42:19) eks: should work
(20:42:27) bryce2: keyboard: 8-bit write to 0064 = ad, keyboard disabled
(20:42:37) bryce2: keyboard: 8-bit write to 0064 = ae, keyboard enabled
(20:42:56) bryce2: is it wierd?
(20:43:11) eks: not really
(20:43:16) eks: edit read port 60 only
(20:43:21) eks: the bios must do the ad/ae
(20:43:35) bryce2: within 30 instructions
(20:43:40) eks: hrm...
(20:43:48) bryce2: 00083985000i[CPU ] interrupt(): vector = 9, INT = 0, EXT = 1
(20:43:51) bryce2: 00083985013d[KBD ] READ(60) = 21
(20:43:53) bryce2: 00083985042d[KBD ] keyboard: 8-bit write to 0064 = ad
(20:43:56) bryce2: 00083985042d[KBD ] keyboard disabled
(20:43:59) bryce2: 00083985056d[KBD ] keyboard: 8-bit write to 0064 = ae
(20:44:02) bryce2: 00083985056d[KBD ] keyboard enabled
(20:44:09) eks: yip, could be
(20:44:15) cbothamy: great news, i found out why win2k is not booting from cd.
(20:44:21) eks: cbothamy: woohoo!
(20:44:24) bryce2: great!
(20:44:52) cbothamy: Stupid bios conventions. cdroms must have their device number >=E0h
(20:45:44) eks: cbothamy: !!
(20:46:33) eks: 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
(20:46:46) eks: 00031556157d[KBD ] keyboard disabled
(20:46:46) eks: 00031556165d[PIC ] IO write to 0020 = 0b
(20:46:46) eks: 00031556166d[PIC ] IO read from 0020
(20:46:46) eks: 00031556166d[PIC ] read master ISR = 02
(20:46:46) eks: 00031556170d[PIC ] IO write to 0020 = 20
(20:46:48) eks: 00031556172d[KBD ] keyboard: 8-bit write to 0064 = ae
(20:48:34) bryce2: eks: in edit, I put a breakpoint at 0xd6d6, and when I press a key it does hit the bp
(20:49:49) eks: so it must be a BIOS bug
(20:50:48) bryce2: hmm. I just tried it again.
(20:50:57) bryce2: after starting edit, I put a pb at 0xd6d6
(20:51:03) bryce2: I pressed "f" and release it
(20:51:13) bryce2: it hit the breakpoint twice
(20:51:19) bryce2: I pressed "f" again and released it
(20:51:22) bryce2: it hit the breakpoint once
(20:51:26) bryce2: I pressed "f" again
(20:51:28) eks: hrm..
(20:51:34) bryce2: it never hits the breakpoint....
(20:51:42) eks: huhh...
(20:51:45) eks: definately a problem
(20:51:51) bryce2: no......it just took a damn long time
(20:51:52) bryce2: and then it did
(20:51:54) bryce2: :)
(20:51:55) bryce2: sorry
(20:52:10) bryce2: I'll keep playing
(20:52:15) eks: lol
(20:52:16) eks: alright
(20:53:07) eks: bryce2: rombios.c line 9457
(20:53:20) eks: mov al, #0xAD ;;disable keyboard
(20:53:20) eks: out #0x64, al
(20:53:20) eks: sti
(20:53:20) eks: ;; see if there is really a key to read from the controller
(20:53:20) eks: in al, #0x64
(20:53:21) bryce2: in al, #0x64
(20:53:23) eks: test al, #0x01
(20:53:25) eks: jz int09_done ;; nope, skip processing
(20:53:28) eks: int09_done:
(20:53:30) eks: cli
(20:53:33) eks: ;; look at PIC in-service-register to see if EOI required
(20:53:35) eks: mov al, #0x0B
(20:53:38) eks: out #0x20, al
(20:53:40) eks: in al, #0x20
(20:53:43) eks: and al, #0x02 ;; IRQ 1 in service
(20:53:46) eks: jz int09_finish
(20:53:48) eks: mov al, #0x20 ;; send EOI to master PIC
(20:53:51) eks: out #0x20, al
(20:53:53) eks: int09_finish:
(20:53:56) eks: mov al, #0xAE ;;enable keyboard
(20:53:58) eks: out #0x64, al
(20:54:01) eks: that's the sequence you saw
(20:54:03) eks: so I'm positive it's the BIOS
(20:54:06) eks: the EDIT only read port 0x60
(20:54:25) bryce2: we know that EDIT read port 60
(20:54:35) bryce2: but somehow it never reacts to the key
(20:54:44) eks: I think I know why >:}
(20:55:02) eks: and if you want to have fun, reverse my patch
(20:55:06) eks: it will suddenly work
(20:55:19) eks: the problem is in the rombios.c at line 9466 and 9467
(20:55:22) bryce2: uh oh
(20:55:49) eks: you remember how Bochs cleared bit 0 of port 0x64 only after port 0x64 was read right?
(20:56:04) eks: now, EDIT read port 0x60
(20:56:10) bryce2: aha
(20:56:13) eks: wihch clears bit 0 of port 0x64 (with my patch)
(20:56:16) eks: the rombios goes in
(20:56:18) eks: disable the keyboard
(20:56:30) eks: notices that in fact, bit 0 is 0 so exit right away without reading the scancode
(20:56:57) eks: what we need to do is move the "look at PIC in-service-register" ... above
(20:57:04) eks: and replace the bit-test of port 0x64 by this code
(20:57:28) eks: if the irq is in service, we have a key to read
(20:57:33) eks: whatever what the port 0x64 says
(20:57:40) bryce2: so the rombios was okay, until the interrupt model was made more accurate
(20:57:46) eks: exact
(20:58:17) bryce2: that doesn't explain why it was broken in October of last year
(20:58:24) eks: ehehe
(20:58:34) eks: probably some other bugs before another patch
(20:58:40) eks: in between somewhere it must have been fixed
(20:58:42) bryce2: Date Submitted: 2001-09-28 18:07
(20:58:45) eks: then we broke it again
(20:59:02) bryce2: I can believe it
(20:59:16) eks: let's see...
(20:59:17) bryce2: do you know what to change in rombios?
(20:59:25) eks: I think I do, I'll give it a try
(20:59:30) bryce2: should I reverse your patch to test your theory?
(20:59:57) eks: sure :)
(21:00:13) eks: not much to lose
(21:02:46) eks: huh... how the hell am I supposed to build rombios.c ??
(21:02:46) bryce2: I reversed your patch, and now I can enqueue keys but there's never an int9 :)
(21:02:52) eks: bcc-cc1 -o rombios.s -c -D__i86__ -0 _rombios_.c
(21:02:54) bryce2: something else is going on
(21:03:01) eks: ??
(21:03:02) bryce2: oh you want to compile it too? :)
(21:03:06) eks: lol
(21:03:15) eks: how do you expect me to modify it otherwise?
(21:03:19) eks: go with a hex editor? :p
(21:03:59) bryce2: I have bcc-cc1, and it was provided by dev86-0.15.0-2
(21:04:25) bryce2: you also need as86 and ld86
(21:04:28) eks: http://void-core.2y.net/rombios.diff-eks
(21:04:32) bryce2: :)
(21:04:37) darkito: bye
(21:05:02) eks: bye darkito
(21:05:07) bryce2: bye
(21:05:56) wli: incoming
(21:05:58) eks: hrm... dev86 is not a debian package...
(21:06:13) bryce2: http://bochs.sf.net/tmp/rombios.bin
(21:07:19) eks: at least the console still work :p
(21:08:01) wli: split patch sent
(21:08:06) eks: YES!
(21:08:08) eks: IT WORKS!
(21:08:10) eks: ahhahah!
(21:08:10) bryce2: wow
(21:08:15) eks: super!
(21:08:15) cbothamy: great
(21:08:25) wli: when I said "not for long" I didn't suspect "2 minutes".
(21:08:26) eks: even the menu with ALT+F >:}
(21:08:48) eks: woohoo :)
(21:09:06) wli: Now to convert the ioapic to the new irq model.
(21:09:42) bryce2: VERY NICE!
(21:09:44) eks: bryce2: you are testing it?
(21:10:11) bryce2: why the hell did they put Utilities:Calendar in here?
(21:10:18) eks: btw.. this BIOS could use some major optimizations ;)
(21:10:53) bryce2: I opened up the calendar and now I'm stuck :)
(21:10:57) bryce2: rebooting
(21:10:59) eks: lolol
(21:11:23) wli: it locked up after some amount of usage?
(21:11:34) bryce2: not sure
(21:11:37) eks: wli: he just doesn't know how to get out of the calendar :p
(21:12:08) wli: oic
(21:12:31) wli: can't he kill the process from another spell
(21:12:39) eks: bryce2: use the menu to close it
(21:12:55) eks: ALT+W -> Close All
(21:13:29) eks: wli: that's not unix, that's DOS in a Bochs window :P
(21:14:16) wli: eks: I've heard DOS has strange/poor process mgmt.
(21:14:34) wli: eks: (or none)
(21:14:58) bryce2: eks: why don't you check in that change to rombios.c and I'll check in the updated binary
(21:15:11) bryce2: it seems to work great
(21:15:21) bryce2: not that I managed to escape from the calendar
(21:15:24) bryce2: now that I
(21:15:31) bryce2: managed to escape from the calendar
(21:15:57) eks: eheh
(21:16:02) eks: sure, I'll check it in
(21:16:49) wli: my 8 cpu BIOS stuff doesn't come anywhere near that part of the BIOS -- should be no conflicts (or even fuzz).
(21:18:31) bryce2: 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));
(21:18:43) bryce2: :)
(21:19:08) eks: eheh
(21:19:09) bryce2: wli: did you send me something? it hasn't arrived yet
(21:19:24) wli: bryce: to the mailing list
(21:19:25) eks: rombios.c committed
(21:19:40) eks: bryce2: I closed the bug report but did not delete it
(21:19:48) bryce2: that's the right thing
(21:21:29) cbothamy: ok guys, i will have a fix for win2k cd-boot in a few days. Now I'm going to sleep. Bye
(21:21:50) bryce2: cbothamy: good work. see you around.
(21:23:14) eks: bryce2: btw, good job on that bug hunting for the keyboard :)
(21:23:26) bryce2: you too
(21:23:28) eks: you provided many useful tips :)
(21:23:37) bryce2: you fixed it :)
(21:23:51) bryce2: that one has been bugging me for a long time
(21:24:03) bryce2: and we had 3 separate bug reports abou it
(21:24:17) wli: probably no need to revert that thing for SMP keyboard stuff then
(21:24:42) wli: wtf would I get a stack address for is_32?
(21:24:43) bryce2: I checked in the binaries
(21:24:55) bryce2: for bioses with the fix
(21:26:51) wli: is there a better APIC ID for the IO APIC?
(21:27:42) wli: maybe 0xe?
(21:27:46) wli: instead of 0x11?
(21:28:03) bryce2: I thought its apic id was the number of processors
(21:28:17) wli: hmm? there can be 14 of them no?
(21:28:26) bryce2: for 4 cpus, the cpus are 0,1,2,3 and the I/O apic is 4
(21:28:32) bryce2: isn't it?
(21:28:52) wli: I don't know of any relation to #cpus offhand
(21:29:14) bryce2: no
(21:29:21) bryce2: but that was the convention in rombios.c
(21:29:36) bryce2: db 4 ;; apic id=2.
(21:29:39) wli: I just used 0x11 since it had no bits in common
(21:29:39) bryce2: db 0x11 ;; I/O APIC version number
(21:30:15) bryce2: that was for 4 processors
(21:30:33) bryce2: I don't think it matters though
(21:30:33) wli: 0x8 could work even though it's the low nybble it still has no bits in common.
(21:30:46) wli: it has to be < 0xf
(21:30:54) bryce2: ok
(21:31:36) bryce2: eks: did you see that kbd: OUTB set and command 0xaa encounter was reported again?
(21:31:44) wli: 17 - 8 is 9 so subtract 0x9 maybe?
(21:31:51) eks: bryce2: yes, it was reported only when the guy click reset
(21:31:57) bryce2: oh ok
(21:32:08) eks: bryce2: I'll have to reset the 'static' variable somehow when the button is pressed..
(21:32:24) bryce2: I think every device should have a hwreset() method
(21:32:28) eks: or maybe there's a more elegant fix to do
(21:32:43) eks: yes, that would definately be the way to go
(21:33:00) bryce2: they aren't very consistent
(21:33:09) wli: 0x9*16 = 0x90, 0x2e - 0x90 = 0x9e
(21:33:55) eks: alright, going to bed here, gn :)
(21:33:58) bryce2: gn
(21:34:04) bryce2: I have to do my taxes.
(21:34:10) wli: 'night
(21:34:15) wli: rest easy
(21:42:55) bryce2: wli: I just applied your 8cpu patch
(21:43:16) wli: bryce: sounds good
(21:43:20) bryce2: I don't think the keyboard change that eks and I were just working on will affect the I/O apic problems
(21:43:46) bryce2: it solved a problem of keyboard freezes in some DOS applications
(21:44:09) wli: bryce: well, I can field problem reports for the 8 cpu thing related to APIC ID unhappiness if the issue arises
(21:44:40) bryce2: in the other patch, I don't understand why you needed
(21:44:46) bryce2: bool os_32, as_32
(21:45:14) wli: bryce: overkill -- is_32 was set to a stack address and I got paranoid
(21:45:15) bryce2: instead of unsigned os_32, as_32
(21:46:03) wli: 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.
(21:47:03) bryce2: what do you mean by "is_32 was set to a stack address"?
(21:47:19) bryce2: your change didn't change that
(21:47:27) bryce2: - is_32 = BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.d_b;
(21:47:30) bryce2: + if (BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.u.segment.d_b)
(21:47:33) wli: bryce: it had a value which was 0xbfff0000 + something when the sim crashed hard
(21:47:38) bryce2: + is_32 = 1;
(21:47:41) bryce2: + else
(21:47:44) bryce2: + is_32 = 0;
(21:47:59) bryce2: you mean that you found a value of 0xbfff0000 in is_32?
(21:48:05) wli: bryce: right
(21:48:29) wli: well, 0xbfff0000 + something < 0x10000
(21:48:29) bryce2: ugly
(21:49:00) wli: yeah, it's not remotely approaching the root cause
(21:49:17) bryce2: nope
(21:49:52) bryce2: you might try linking with electric fence or some other memory checker
(21:50:00) bryce2: -lefence, it's installed on redhat
(21:50:16) bryce2: and it takes over your malloc
(21:50:39) wli: whatever methods are required to find it will surely be laborious, efence just breaks assumptions more readily
(21:51:32) wli: I think I documented that in the "one giant patch" version of it
(21:51:41) bryce2: now the change in ioapic to allow an id>=16
(21:51:50) bryce2: is that specific to P4's or anything?
(21:52:18) wli: I think it is, if I fix the ioapic ID to 0xe instead of 0x11 it should no longer be necessary
(21:52:25) bryce2: ok
(21:53:19) ***arashi is away: sleeping roommate
(21:53:22) bryce2: when we start coding things that should act differently on ppros and p4s or whatever, let's think about adding a new cpu level
(21:53:36) bryce2: or apic behavior switch
(21:53:46) bryce2: or something
(21:54:14) wli: the only piece I'm missing for that is I don't know how to add new config options to autoconf stuff
(21:54:45) bryce2: you edit configure.in and then run autoconf
(21:54:49) bryce2: to produce a new configure script
(21:55:11) wli: I winged the extra case for 8 cpu's, in general I don't know syntax.
(21:55:12) bryce2: I just follow the examples, or if I'm really desperate I read "info autoconf"
(21:55:17) bryce2: me either :)
(21:55:24) bryce2: it's a shell script with m4 macros. yuck.
(21:56:00) bryce2: I will check in 06_8_cpu_workarounds in patches
(21:56:28) bryce2: but I really don't like the is_32 stuff to avoid stack corruption, as you can imagine
(21:56:48) wli: I don't dare advertise it as clean or even truly a "fix"
(21:57:30) bryce2: I assume you tried make dist-clean, configure, make?
(21:57:52) wli: yeah
(21:57:55) bryce2: if there are broken compile dependencies, sometimes make fails to recompile some .o's
(21:58:05) bryce2: leading to disagreements over where the object fields can be found.
(21:58:25) bryce2: also, I find that sometimes the debugger lies about local variables
(21:58:32) bryce2: and says they have junk values.
(21:58:43) bryce2: adding a BX_INFO will tell for sure.
(21:59:24) wli: I got the local variable value from a coredump
(21:59:42) bryce2: I have a feeling the debugger has trouble with -fomit-frame-pointer, but I could be imagining it.
(21:59:50) wli: oh it does
(21:59:55) wli: I didn't use that option
(22:00:49) wli: could also be miscompiling, codegen does have a few holes in it as seen in the kernel, could be getting hit here as well.
(22:01:21) bryce2: I'm checking in your workarounds on top of patch.smp-8cpu-etc
(22:01:24) bryce2: is that ok?
(22:01:35) wli: Sounds good.
(22:01:39) bryce2: the rombios and configure.in changes are already committed
(22:01:48) wli: it ought to make some of the issues arising more visible.
(22:01:53) bryce2: so the remaining workarounds will be in patch.smp-8cpu-etc
(22:02:34) bryce2: ok
(22:02:38) bryce2: I'm off to do my taxes!
(22:02:55) wli: 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. =)