[EMAIL PROTECTED] writes:
> Hi Steve,
>
> Steve Dunham <[EMAIL PROTECTED]> writes:
> >
> > I sent some info to the laptop-linux list, but I'm not sure if you've
> > seen it. This is a really weird problem, and I can't figure out what
> > is going on.
>
> I saw it and am thinking about it. I will get back to you.
Any ideas? Could it possibly be a stack issue? Is there an easy way
to force the kernel to leave more room on the stack before entering
the BIOS, or should this be taken care of automatically by the kernel
(even under a cli?)
Also, am I correct in assuming that seg faults &c in the BIOS code
would show up as oopses (even under a cli)?
I started to disassemble the BIOS, by writing a program to mmap the
BIOS and running it in gdb, but quickly decided it wouldn't get me
very far. I did notice that: 1. They do a cli themselves before the
decode %al (appears to be a jump table, but gdb isn't disassembling
the call opcodes correctly, and I don't have a chart.)
I do have a binary image of f0000 to fffff. The entry point is f5f93
(or, rather, f000:f593).
I also tried dumping 0040:0000 (what ds is set to), but I can't mmap()
it. I'm not sure it matters, since the first thing the BIOS code does
is set %ds to %cs+0x10.
Steve
[EMAIL PROTECTED]
