Andy Green wrote:
| On Sunday 13 April 2003 23:30, Ivan Hawkes wrote:
|
|
|>When faced with an intractable problem like the boot issues, I
|>usually start to remove all the code possible to bring it down to a
|>skeleton only. When that is operating (if!) properly it's time to
|>slowly trickle the rest of the code back in, a little at a time
|>until the source of the breakage is identified. That may not apply
|>in this case if you are having issues which could possibly be
|>related to the code layout in memory.
|
|
| A good method. But the problem is present with a minimal startup
| footprint, as soon as enough code - pretty much any code, it seems,
| is added to see the symptoms.
That's going to make it hard to crack.
|>Instability is more likely due to buffer overflows which affect
|>sections of code/data (data more likely really, it should all be in
|>a data segment) and is layout sensitive because corrupted data in
|>some sections is more tolerable than in other.
|
|
| It seems to me there is some interrelation between the hardware and
| the init code going on. Your point is right though, the instability
| could be being driven by uninitialized memory contents in that way.
|
|
|>Since it's at boot time that you're having issues I'm guessing that
|>there's no debugger help available and extremely restricted access
|>to useful methods for instrumenting the code. Pity the machines
|>don't come with an old MDA adapter (Mono Display Adapter) you could
|>have output text to that during boot sequence for debugging
|>purposes. As is stands, what sort of debugging is available? I
|>suspect there is no screen, is there at least a system bell (beep)
|>to call? I used to debug a graphical multimedia system I built
|>using the system bell since the debuggers at the time weren't up to
|>scratch. It's amazing how much info listening for beeps can
|>provide.
|
|
| I designed and built three Filtror devices
|
| http://warmcat.com/milksop/filtror.html
|
| back in July 2002 I think, and distributed two of them to other people
| who were working on the early BIOS stuff. I also wrote a terminal
| type application, so even when there was no IO up at all, it was
| possible to have a debug terminal up. This proved very useful
| indeed, especially when we were booting Linux for the first time, it
| was crashing early during boot with no output to guide us. Milosch
| wrote a filtror character driver and that got us over the dump by
| showing dmesg stuff.
Yikes, nice piece of engineering there. I take it you did electronics at
Uni? Was it the work you did on LPCs that drew you to the XBox project
or was that simply a happy co-incidence?
|>How about pre-initialising all the memory being used to a known
|>value, then checking this value is present prior to using it?
|>There's a chance this will reveal a buffer overrun from a previous
|>section of code.
|
|
| Franz has been trying this trick with adding memsets(), although he is
| quick to claim success, he has not explained which of the "14-15"
| memsets he added did anything, nor where the supposed bug was. And
| he continues to ignore my advice (after all, what do I know!) that
| this instability problem is sensitive to code layout. So I assume
| any changes in behaviour were due to the added code footprint and not
| function, despite Franz's handwaving.
If it's not reproducable then you haven't isolated the bug. If you can't
explain "why" a problem goes away then you haven't solved it - you've
merely moved it a little further into your future. I get decididly edgy
if a problem (intermittent) just goes away...software bugs don't fix
themselves.
| I did actually add code in BootStartup.S some months ago to zero the
| first 1M (I think) of memory before the stack was set up, it made no
| difference to the instability compared to the same amount of NOPs
| inserted at the same place. So I removed the code and came away
| pretty sure that uninitialized RAM is not the problem. (This doesn't
| help with unprepped stack allocation, but at that time there was
| virtually no code other than the init).
Adding NOP into a data segment (god, I'm so old, do they even still have
the segmented memeory architecture on Pentium class processors?) is more
likely to cause data weirdness than zeroing it. That's because 0 is a
terminating character for strings, so if you have a data buffer overflow
(but still in the data segment) then there is a good chance of hitting a
0 eventually...thus terminating the string data. Neither is particularly
good with numeric values. NOP is good in code segments because they take
1 instruction and thus when code goes off the rails and hit's the NOP
they can just suck 'em up like PacMan until they hit the start of the
next block of real instructions.
One idea might be to seed the code area/data area with long jumps to an
exeception handler block, preferrably one that rings the bell or logs to
the screen or fires off a noticable event. Perhaps a little NOP padding
either side of these will increase the chances of it being executed as a
long jump rather than some random instruction sequence because the code
executes from within e.g. (note, I haven't written assembler for 15
years...this will be wrong)
NOP
NOP
NOP
NOP
JMP EX_HANDLER
NOP
NOP
NOP
NOP
JMP EX_HANDLER
NOP
NOP
NOP
NOP
JMP EX_HANDLER
EX_HANDLER:
MOV AH, whatever ; You get the idea...
.
.
.
INT 21H ; or some debugging shit...since
; this is an old BIOS interupt.
|>I'd start hacking myself but my box is in Australia still getting
|>modded...*sigh*...not much longer to wait.
|
|
| You're very welcome to join in.
|
| -Andy
I'd love to join in the hacking, better dust off my assembler books and
stuff though, I haven't used that part of my brain for a while and all
my stuff is still referencing the 8086/8080 architectures...sheesh.
- -------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Xbox-linux-devel mailing list
Xbox-linux-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbox-linux-devel