Hello, I keep getting unexpected exception errors on my IP1000 with builds over the past 6 months or so. The unexpected exception errors are random errors and are different every time, but seem to happen right about the time the vga rom loads. I think it has something to do with x86emu and yabel loading the vga rom. If I change it to boot up with out graphics it boots up every time, no problem. If I enable the vga device (2.0) and allocate vga memory but not load the vga rom it boots up every time no problem. So this tells me it doesn’t like something the rom emulator is doing, right? This is very strange because I do not have this problem with the RM4100… just the IP1000 (brother boards).
I am going to try SeaBIOS and see if that works but what do I need to do to implement HAVE_HIGH_TABLES on the IP1000? Anything special? Can someone point me to some example boards that use HAVE_HIGH_TABLES?
On Mon, Apr 20, 2009 at 8:27 AM, Joseph Smith joe@settoplinux.org wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds over the past 6 months or so. The unexpected exception errors are random errors and are different every time, but seem to happen right about the time the vga rom loads. I think it has something to do with x86emu and yabel loading the vga rom. If I change it to boot up with out graphics it boots up every time, no problem. If I enable the vga device (2.0) and allocate vga memory but not load the vga rom it boots up every time no problem. So this tells me it doesn’t like something the rom emulator is doing, right? This is very strange because I do not have this problem with the RM4100… just the IP1000 (brother boards).
You could well be tickling a but in either emulator. These are hard to find. It's handy to have a user-mode wrapper so you can run these emulators under linux -- much easier to find that way. Is this possible with YABEL?
ron
On 20.04.2009 17:38 Uhr, ron minnich wrote:
On Mon, Apr 20, 2009 at 8:27 AM, Joseph Smith joe@settoplinux.org wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds over the past 6 months or so. The unexpected exception errors are random errors and are different every time, but seem to happen right about the time the vga rom loads. I think it has something to do with x86emu and yabel loading the vga rom. If I change it to boot up with out graphics it boots up every time, no problem. If I enable the vga device (2.0) and allocate vga memory but not load the vga rom it boots up every time no problem. So this tells me it doesn’t like something the rom emulator is doing, right? This is very strange because I do not have this problem with the RM4100… just the IP1000 (brother boards).
You could well be tickling a but in either emulator. These are hard to find. It's handy to have a user-mode wrapper so you can run these emulators under linux -- much easier to find that way. Is this possible with YABEL?
Not right now, but you can connect to coreboot via gdb over serial, which gives you a user space frontend with single stepping...
Stefan
On Mon, 20 Apr 2009 17:50:00 +0200, Stefan Reinauer stepan@coresystems.de wrote:
On 20.04.2009 17:38 Uhr, ron minnich wrote:
On Mon, Apr 20, 2009 at 8:27 AM, Joseph Smith joe@settoplinux.org
wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds
over
the past 6 months or so. The unexpected exception errors are random
errors
and are different every time, but seem to happen right about the time
the
vga rom loads. I think it has something to do with x86emu and yabel
loading
the vga rom. If I change it to boot up with out graphics it boots up
every
time, no problem. If I enable the vga device (2.0) and allocate vga
memory
but not load the vga rom it boots up every time no problem. So this
tells
me it doesn’t like something the rom emulator is doing, right? This
is
very strange because I do not have this problem with the RM4100… just
the
IP1000 (brother boards).
You could well be tickling a but in either emulator. These are hard to find. It's handy to have a user-mode wrapper so you can run these emulators under linux -- much easier to find that way. Is this possible with YABEL?
Could I try something like vbetool?
Not right now, but you can connect to coreboot via gdb over serial, which gives you a user space frontend with single stepping...
Do you mean http://www.coreboot.org/Debugging ?? I tried that, but the errors are different everytime and not always in the exact place so it is hard to put a finger on it using this method.
On Mon, Apr 20, 2009 at 9:53 AM, Joseph Smith joe@settoplinux.org wrote:
Do you mean http://www.coreboot.org/Debugging ?? I tried that, but the errors are different everytime and not always in the exact place so it is hard to put a finger on it using this method.
This really sounds like an unitialized variable or a bad pointer.
I wonder if we shouldn't put in support for the Linux sparse code checking.
ron
On 20.04.2009 19:03 Uhr, ron minnich wrote:
On Mon, Apr 20, 2009 at 9:53 AM, Joseph Smith joe@settoplinux.org wrote:
Do you mean http://www.coreboot.org/Debugging ?? I tried that, but the errors are different everytime and not always in the exact place so it is hard to put a finger on it using this method.
This really sounds like an unitialized variable or a bad pointer.
I wonder if we shouldn't put in support for the Linux sparse code checking.
ron
Check out http://coresystems.de/~stepan/coreboot-scanbuild/
On Mon, 20 Apr 2009 19:10:34 +0200, Stefan Reinauer stepan@coresystems.de wrote:
On 20.04.2009 19:03 Uhr, ron minnich wrote:
On Mon, Apr 20, 2009 at 9:53 AM, Joseph Smith joe@settoplinux.org
wrote:
Do you mean http://www.coreboot.org/Debugging ?? I tried that, but the errors are different everytime and not always in
the
exact place so it is hard to put a finger on it using this method.
This really sounds like an unitialized variable or a bad pointer.
I wonder if we shouldn't put in support for the Linux sparse code
checking.
ron
Thanks, what am I looking for? Errors related to x86emu based on my gdb back traces?
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
On Tue, Apr 21, 2009 at 5:41 AM, Joseph Smith joe@settoplinux.org wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
These kinds of things are normally warnings. That's part of the reason we're using scan-build and trying to remove as many warnings as we can.
Thanks, Myles
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
ron
On 22.04.2009 22:50 Uhr, ron minnich wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
ron
BTW: I did a new scanbuild run today: http://www.coresystems.de/~stepan/coreboot-scanbuild/
Patches and bug fixes are welcome.
If anyone succeeds to get sparse running with coreboot, i'll give it a try, too. It didn't work all too well when i tried.
Stefan
On Wed, 22 Apr 2009 22:54:08 +0200, Stefan Reinauer stepan@coresystems.de wrote:
On 22.04.2009 22:50 Uhr, ron minnich wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
ron
BTW: I did a new scanbuild run today: http://www.coresystems.de/~stepan/coreboot-scanbuild/
Patches and bug fixes are welcome.
If anyone succeeds to get sparse running with coreboot, i'll give it a try, too. It didn't work all too well when i tried.
Wow looks like there are alot of bugs in romcc.c !
Joseph Smith wrote:
Wow looks like there are alot of bugs in romcc.c !
I only looked at the very first ones:
API Argument with 'nonnull' attribute passed null romcc.c:10780
The thing to note here is that there are conditions to the error. Code can very well be making sure that those conditions are in fact never met, and I don't think scanbuild does a complex enough analysis to know for sure. (Quite understandably!)
I agree it would be nice to have perfect analysis, and/or code more suitable for analysis, but just want to point out that there can be false positives depending on the coding style.
//Peter
On 22.04.2009 23:26 Uhr, Peter Stuge wrote:
Joseph Smith wrote:
Wow looks like there are alot of bugs in romcc.c !
I only looked at the very first ones:
API Argument with 'nonnull' attribute passed null romcc.c:10780
The thing to note here is that there are conditions to the error. Code can very well be making sure that those conditions are in fact never met, and I don't think scanbuild does a complex enough analysis to know for sure. (Quite understandably!)
I agree it would be nice to have perfect analysis, and/or code more suitable for analysis, but just want to point out that there can be false positives depending on the coding style.
Absolutely agreed. Not all findings by scan-build make sense (for us). There are cases where it will find an access to memory which is not backed by a C variable to be undefined. (something like *(u8 *)0xdeadbeef) ... Makes a lot of sense in (most) user space applications, but we need to be careful. I tried to fix a couple of findings, even if they were not strictly required (such as attribute((noreturn)) in a userspace function calling exit() ... the attribute is not inherited in scan-build as they don't do interprocedural checks yet) to improve the overall results.
There are far better ways of doing static code analysis, most of them involve a lot of time and money. That said, if someone with a PolySpace license (Carl-Daniel?) and a few couple of days of time reads this, please help us verify our code! Same for QA-C et al.
Stefan
On Wed, Apr 22, 2009 at 1:54 PM, Stefan Reinauer stepan@coresystems.de wrote:
If anyone succeeds to get sparse running with coreboot, i'll give it a try, too. It didn't work all too well when i tried.
I have not been paying attention. this looks better than what I have seen of sparse.
ron
On Wed, 22 Apr 2009 13:50:54 -0700, ron minnich rminnich@gmail.com wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
Why can't I just send the build output to a text file and then look through it for all the warnings/errors?
$ make > buildlog.txt
On 23.04.2009 1:09 Uhr, Joseph Smith wrote:
On Wed, 22 Apr 2009 13:50:54 -0700, ron minnich rminnich@gmail.com wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
Why can't I just send the build output to a text file and then look through it for all the warnings/errors?
$ make > buildlog.txt
You can..
btw.. qa.coreboot.org holds logs of each revision too (the last few 200-1000 depending when I clean up)
http://qa.coreboot.org/log_buildbrd.php?revision=4187&device=ip1000&...
But please note that gcc does not catch all the tricky mistakes we make.
On 23.04.2009 01:28, Stefan Reinauer wrote:
On 23.04.2009 1:09 Uhr, Joseph Smith wrote:
On Wed, 22 Apr 2009 13:50:54 -0700, ron minnich rminnich@gmail.com wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
Why can't I just send the build output to a text file and then look through it for all the warnings/errors?
$ make > buildlog.txt
You can..
btw.. qa.coreboot.org holds logs of each revision too (the last few 200-1000 depending when I clean up)
http://qa.coreboot.org/log_buildbrd.php?revision=4187&device=ip1000&...
But please note that gcc does not catch all the tricky mistakes we make.
Or you run cd util/abuild; abuild -t thomson/ip1000 and look at coreboot-builds/thomson_ip1000/make.log
Regards, Carl-Daniel
On 23.04.2009 1:35 Uhr, Carl-Daniel Hailfinger wrote:
On 23.04.2009 01:28, Stefan Reinauer wrote:
On 23.04.2009 1:09 Uhr, Joseph Smith wrote:
On Wed, 22 Apr 2009 13:50:54 -0700, ron minnich rminnich@gmail.com wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
Why can't I just send the build output to a text file and then look through it for all the warnings/errors?
$ make > buildlog.txt
You can..
btw.. qa.coreboot.org holds logs of each revision too (the last few 200-1000 depending when I clean up)
http://qa.coreboot.org/log_buildbrd.php?revision=4187&device=ip1000&...
But please note that gcc does not catch all the tricky mistakes we make.
Or you run cd util/abuild; abuild -t thomson/ip1000 and look at coreboot-builds/thomson_ip1000/make.log
or
util/abuild/abuild -t thomson/ip1000 $PWD
to build on the top level.
You can also specify a payload directory with -p
mkdir payloads cp /somewhere/filo.elf payloads then add a file payloads/payload.sh which prints the name of the payload to use (and takes the mainboard as a parameter) such as echo "`dirname $0`/build/filo.elf"
then you can build a fully working image with payload by specifying:
util/abuild/abuild -t thomson/ip1000 -p ./payloads $PWD
Specify -c max or -c 2 if you have an SMP system, to speed compilation up.
Stefan
On 23.04.2009 01:44, Stefan Reinauer wrote:
On 23.04.2009 1:35 Uhr, Carl-Daniel Hailfinger wrote:
On 23.04.2009 01:28, Stefan Reinauer wrote:
On 23.04.2009 1:09 Uhr, Joseph Smith wrote:
On Wed, 22 Apr 2009 13:50:54 -0700, ron minnich rminnich@gmail.com wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
> This really sounds like an unitialized variable or a bad pointer. > > > > > Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
Why can't I just send the build output to a text file and then look through it for all the warnings/errors?
$ make > buildlog.txt
You can..
btw.. qa.coreboot.org holds logs of each revision too (the last few 200-1000 depending when I clean up)
http://qa.coreboot.org/log_buildbrd.php?revision=4187&device=ip1000&...
But please note that gcc does not catch all the tricky mistakes we make.
Or you run cd util/abuild; abuild -t thomson/ip1000 and look at coreboot-builds/thomson_ip1000/make.log
or
util/abuild/abuild -t thomson/ip1000 $PWD
to build on the top level.
You can also specify a payload directory with -p
mkdir payloads cp /somewhere/filo.elf payloads then add a file payloads/payload.sh which prints the name of the payload to use (and takes the mainboard as a parameter) such as echo "`dirname $0`/build/filo.elf"
then you can build a fully working image with payload by specifying:
util/abuild/abuild -t thomson/ip1000 -p ./payloads $PWD
Specify -c max or -c 2 if you have an SMP system, to speed compilation up.
Thanks for the writeup, this is now at http://www.coreboot.org/Abuild
Regards, Carl-Daniel
On 23.04.2009 1:56 Uhr, Carl-Daniel Hailfinger wrote:
Thanks for the writeup, this is now at http://www.coreboot.org/Abuild
Thanks!
On Wed, 22 Apr 2009 19:09:48 -0400, Joseph Smith joe@settoplinux.org wrote:
On Wed, 22 Apr 2009 13:50:54 -0700, ron minnich rminnich@gmail.com wrote:
On Tue, Apr 21, 2009 at 4:41 AM, Joseph Smith joe@settoplinux.org
wrote:
This really sounds like an unitialized variable or a bad pointer.
Wouldn't gcc catch these and error when building?
not always. that's what sparse can be useful for.
Why can't I just send the build output to a text file and then look through it for all the warnings/errors?
$ make > buildlog.txt
Could this cause an issue? coreboot-v2-4187//src/superio/smsc/smscsuperio/superio.c: In function 'enable_dev': coreboot-v2-4187//src/superio/smsc/smscsuperio/superio.c:325: warning: passing argument 4 of 'pnp_enable_devices' from incompatible pointer type
YAHOO!!!! I HAVE VGA!! Well there is definitely something wacked out on x86emu and yabel. For the hell of it I tried VM86 and VGA comes right up with no errors. And VM86 is way faster x86emu and yabel. With my debug level still at 9 and a 5 second delay for filo, I am at the filo prompt in 15 seconds :-) This used to take about 25-30 seconds with x86emu.
One question, is this normal for VM86? (from bootlog)
PCI: 00:02.0 init
On mainboard, rom address for PCI: 00:02.0 = fff00000
PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040
PCI ROM Image, Vendor 8086, Device 3577,
PCI ROM Image, Class Code 030000, Code Type 00
copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes
biosint: INT# 0xd
biosint: eax 0x23fddfef ebx 0x0 ecx 0x2f6 edx 0x3b4
biosint: ebp 0x10fac esp 0xc89 edi 0x4028 esi 0x24028
biosint: ip 0xffff cs 0xc000 flags 0x813
biosint: Oops, exception 13
Stack contents: 0xffff 0xc000 0x0813 0xbffd 0xf7fb 0xffdf 0xffff 0xbfff 0xabf3 0xff55 0x55ff 0xf3fa 0x5cfd 0xffeb 0xffff 0xf9ff 0xff7f 0x7fbd 0xfffd 0xffff 0xf3ff 0xffdf 0x7ffe 0xdffb 0xfffb 0xffd7 0x5fff 0xf1f7 0xf6ee 0x7faf 0xffff 0xedff 0xeff5 0xffbd 0xfbff 0x7ebf 0xffeb 0xf75f 0x5fff 0xfffa 0xfff6 0xb75f 0xffff 0xf7ff 0x5ffd 0xfdfd 0xfbff 0xfefd 0xf7f7 0xffaf 0xfbff 0xffff 0xebef 0xfb7e 0xdfff 0xff73 0xaf97 0xffff 0xdfbf 0xffff 0xfbff 0xfffb 0xbf7f 0xe9ef 0x7ddf 0xfe9d 0xfff7 0xffff 0x3bff 0xffcf 0xffff 0x5f7f 0xbfbb 0xff7f 0xdfff 0xebfe 0x7fff 0xffaf 0xffff 0xef8f 0x7f5f 0xffbd 0xff7f 0xbf6f 0xf3ef 0xff5e 0xf7ff 0xbfff 0xd3ff 0xff5e 0xf7df 0xffff 0xdf5f 0x7fbf 0xffff 0xefbf 0x7fdf 0xbfbf 0xffff 0xffb7 0xf7ff 0xff7f 0x7fff 0xff77 0xdbef 0xbfd7 0xffff 0xdfdb 0x7fce 0xffed 0xfeff 0xf9ff 0xf7ff 0xfbff 0xbaff 0xffcf 0xabbb 0xff56 0xffff 0xffff 0x3fcf 0xffde 0x7fff 0xfffa 0x7fc7 0xffd7 0xefff 0xe3af 0xfef7 0xbfeb 0x7fef 0xbfdd 0xbbfb 0xffff 0xf7ff 0xbefe 0xafff 0xdb5f 0xdffb 0xebff 0xdfff 0xff9f 0xfffd 0xf5ff 0x7ddf 0xffbd 0xfaef 0xbeff 0xfbbb 0xffd7 0xffff 0xfbff 0xa7eb 0xfff6 0xdfff 0xeffe 0xfeff 0xffed 0xeaff 0xbffb 0xd9fd 0xfffd 0xffff 0x7fc5 0xebab 0xfbdf 0xdfbf 0xbf7e 0xe7f6 0xafd6 0xfffe 0xfdfe 0x5cf9 0xfffb 0xfeff 0xfbfd 0xfffd 0xffbe 0xffff 0xffff 0xffff 0xfbaf 0xffff 0xfef7 0x7fff 0xffff 0x7fff 0xfff7 0xeffb 0x7fbf 0xeeff 0x6dbf 0xb4f7 0x7fa0 0xfbfe 0xdf3d 0xb7bb 0xbfd7 0xffff 0xff7f 0xfffe 0xffd7 0xf5df 0xfbff 0xfdcd 0xffaf 0xffff 0xeb9f 0x5cff 0x7fbb 0xef7f 0xffdf 0xaeff 0xff77 0x7fff 0x7fff 0xa3aa 0xfb7e 0xffff 0xeff7 0xbddf 0xffaf 0xff7f 0xffee 0xdefd 0xfeb9 0xfbf5 0x5f8f 0xb7ff 0xa357 0x7ffb 0x3fff 0x37af 0xff5e 0xffdf 0xe7ff 0xfcd7 0xffe9 0xfeff 0xefff 0x7bff 0xdfdf 0xffff 0xdfdf 0xffff 0xf773 0xd7bb 0xdfff 0xbfeb 0xf74f 0x7ffa 0xf7ff 0xdfff 0xdfea 0xfef7 0xebdf 0xdc77 0xfeff 0xe77f 0xfffd 0xebfb 0xfff7 0xbfff 0xfefb 0xefff 0xff7f 0xffff 0xfd7f 0xfeff 0xfea7 0xfbff 0xedf7 0x7cdd 0x7fed 0xfee7 0xdeff 0xe75d 0xfff6 0x7fff 0xfebf 0xdfbb 0xffff 0xffff 0xf7ff 0x5edf 0xfdeb 0xeefd 0xf7f7 0xfdfd 0x7fbb 0xfeef 0xbffd 0xa9fe 0xffde 0xfffe 0xbf7f 0xeffb 0xf7fe 0x7dff 0xeb7e 0xfdd7 0xfff9 0xfb7f 0xffff 0x7c7f 0xff9f 0xfef5 0x9edf 0xe7be 0xff77 0xffdb 0xfff6 0xbf9b 0xf7f7 0xffff 0xfff2 0xdf1d 0xfe6d 0xffff 0xed7e 0x7d77 0xfc9d 0x7eef 0x5efd 0xfffb 0xff57 0x75df 0xff7f 0xfb2b 0xff57 0xfffa 0xff97 0xd9df 0xfffd 0xffff 0xefdf 0x55ff 0xffeb 0xff6f 0xdf7d 0xe7fb 0xff56 0xffff 0xffff 0xfffe 0xf777 0xdfff 0xffff 0xffff 0xfff5 0xffff 0xf1ff 0xffdf 0xffff 0xffff 0xffdd 0xffeb 0xeb5f 0xffff 0xfeff 0xfbab 0xfb77 0xfdff 0xffff 0xffdf 0xff3f 0xffff 0xffef 0x7fff 0xffef 0xffff 0xffff 0xf7bf 0xff7f 0xffff 0xfff7 0xf7ff 0xff7e 0xb4ff 0x1e03 0x7f45 0xac03 0x710f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0xe4ba 0x010f 0x94e0 0x0649 0x0000 0x01c0 0x8000 0x0000 0xf600 0x712f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0x3eba 0x40ba 0x0000 0x4000 0x04fc 0x6421 0xfabf 0x040f 0x0921 0xf400 0xf4bf 0x46bf 0x4100 0x00b0 0x6600
biosint: Bailing out
On Wed, 22 Apr 2009 23:58:21 -0400, Joseph Smith joe@settoplinux.org wrote:
YAHOO!!!! I HAVE VGA!! Well there is definitely something wacked out on x86emu and yabel. For
the
hell of it I tried VM86 and VGA comes right up with no errors. And VM86
is
way faster x86emu and yabel. With my debug level still at 9 and a 5
second
delay for filo, I am at the filo prompt in 15 seconds :-) This used to take about 25-30 seconds with x86emu.
One question, is this normal for VM86? (from bootlog)
PCI: 00:02.0 init
On mainboard, rom address for PCI: 00:02.0 = fff00000
PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040
PCI ROM Image, Vendor 8086, Device 3577,
PCI ROM Image, Class Code 030000, Code Type 00
copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes
biosint: INT# 0xd
biosint: eax 0x23fddfef ebx 0x0 ecx 0x2f6 edx 0x3b4
biosint: ebp 0x10fac esp 0xc89 edi 0x4028 esi 0x24028
biosint: ip 0xffff cs 0xc000 flags 0x813
biosint: Oops, exception 13
Stack contents: 0xffff 0xc000 0x0813 0xbffd 0xf7fb 0xffdf 0xffff 0xbfff 0xabf3 0xff55 0x55ff 0xf3fa 0x5cfd 0xffeb 0xffff 0xf9ff 0xff7f 0x7fbd 0xfffd 0xffff 0xf3ff 0xffdf 0x7ffe 0xdffb 0xfffb 0xffd7 0x5fff 0xf1f7 0xf6ee 0x7faf 0xffff 0xedff 0xeff5 0xffbd 0xfbff 0x7ebf 0xffeb 0xf75f 0x5fff 0xfffa 0xfff6 0xb75f 0xffff 0xf7ff 0x5ffd 0xfdfd 0xfbff 0xfefd 0xf7f7 0xffaf 0xfbff 0xffff 0xebef 0xfb7e 0xdfff 0xff73 0xaf97 0xffff 0xdfbf 0xffff 0xfbff 0xfffb 0xbf7f 0xe9ef 0x7ddf 0xfe9d 0xfff7 0xffff 0x3bff 0xffcf 0xffff 0x5f7f 0xbfbb 0xff7f 0xdfff 0xebfe 0x7fff 0xffaf 0xffff 0xef8f 0x7f5f 0xffbd 0xff7f 0xbf6f 0xf3ef 0xff5e 0xf7ff 0xbfff 0xd3ff 0xff5e 0xf7df 0xffff 0xdf5f 0x7fbf 0xffff 0xefbf 0x7fdf 0xbfbf 0xffff 0xffb7 0xf7ff 0xff7f 0x7fff 0xff77 0xdbef 0xbfd7 0xffff 0xdfdb 0x7fce 0xffed 0xfeff 0xf9ff 0xf7ff 0xfbff 0xbaff 0xffcf 0xabbb 0xff56 0xffff 0xffff 0x3fcf 0xffde 0x7fff 0xfffa 0x7fc7 0xffd7 0xefff 0xe3af 0xfef7 0xbfeb 0x7fef 0xbfdd 0xbbfb 0xffff 0xf7ff 0xbefe 0xafff 0xdb5f 0xdffb 0xebff 0xdfff 0xff9f 0xfffd 0xf5ff 0x7ddf 0xffbd 0xfaef 0xbeff 0xfbbb 0xffd7 0xffff 0xfbff 0xa7eb 0xfff6 0xdfff 0xeffe 0xfeff 0xffed 0xeaff 0xbffb 0xd9fd 0xfffd 0xffff 0x7fc5 0xebab 0xfbdf 0xdfbf 0xbf7e 0xe7f6 0xafd6 0xfffe 0xfdfe 0x5cf9 0xfffb 0xfeff 0xfbfd 0xfffd 0xffbe 0xffff 0xffff 0xffff 0xfbaf 0xffff 0xfef7 0x7fff 0xffff 0x7fff 0xfff7 0xeffb 0x7fbf 0xeeff 0x6dbf 0xb4f7 0x7fa0 0xfbfe 0xdf3d 0xb7bb 0xbfd7 0xffff 0xff7f 0xfffe 0xffd7 0xf5df 0xfbff 0xfdcd 0xffaf 0xffff 0xeb9f 0x5cff 0x7fbb 0xef7f 0xffdf 0xaeff 0xff77 0x7fff 0x7fff 0xa3aa 0xfb7e 0xffff 0xeff7 0xbddf 0xffaf 0xff7f 0xffee 0xdefd 0xfeb9 0xfbf5 0x5f8f 0xb7ff 0xa357 0x7ffb 0x3fff 0x37af 0xff5e 0xffdf 0xe7ff 0xfcd7 0xffe9 0xfeff 0xefff 0x7bff 0xdfdf 0xffff 0xdfdf 0xffff 0xf773 0xd7bb 0xdfff 0xbfeb 0xf74f 0x7ffa 0xf7ff 0xdfff 0xdfea 0xfef7 0xebdf 0xdc77 0xfeff 0xe77f 0xfffd 0xebfb 0xfff7 0xbfff 0xfefb 0xefff 0xff7f 0xffff 0xfd7f 0xfeff 0xfea7 0xfbff 0xedf7 0x7cdd 0x7fed 0xfee7 0xdeff 0xe75d 0xfff6 0x7fff 0xfebf 0xdfbb 0xffff 0xffff 0xf7ff 0x5edf 0xfdeb 0xeefd 0xf7f7 0xfdfd 0x7fbb 0xfeef 0xbffd 0xa9fe 0xffde 0xfffe 0xbf7f 0xeffb 0xf7fe 0x7dff 0xeb7e 0xfdd7 0xfff9 0xfb7f 0xffff 0x7c7f 0xff9f 0xfef5 0x9edf 0xe7be 0xff77 0xffdb 0xfff6 0xbf9b 0xf7f7 0xffff 0xfff2 0xdf1d 0xfe6d 0xffff 0xed7e 0x7d77 0xfc9d 0x7eef 0x5efd 0xfffb 0xff57 0x75df 0xff7f 0xfb2b 0xff57 0xfffa 0xff97 0xd9df 0xfffd 0xffff 0xefdf 0x55ff 0xffeb 0xff6f 0xdf7d 0xe7fb 0xff56 0xffff 0xffff 0xfffe 0xf777 0xdfff 0xffff 0xffff 0xfff5 0xffff 0xf1ff 0xffdf 0xffff 0xffff 0xffdd 0xffeb 0xeb5f 0xffff 0xfeff 0xfbab 0xfb77 0xfdff 0xffff 0xffdf 0xff3f 0xffff 0xffef 0x7fff 0xffef 0xffff 0xffff 0xf7bf 0xff7f 0xffff 0xfff7 0xf7ff 0xff7e 0xb4ff 0x1e03 0x7f45 0xac03 0x710f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0xe4ba 0x010f 0x94e0 0x0649 0x0000 0x01c0 0x8000 0x0000 0xf600 0x712f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0x3eba 0x40ba 0x0000 0x4000 0x04fc 0x6421 0xfabf 0x040f 0x0921 0xf400 0xf4bf 0x46bf 0x4100 0x00b0 0x6600
biosint: Bailing out
I guess I spoke too soon, when booting Linux I am getting a bunch of page_fault Kernel panics :-( WTF!
On Thu, 23 Apr 2009 01:19:25 -0400, Joseph Smith joe@settoplinux.org wrote:
On Wed, 22 Apr 2009 23:58:21 -0400, Joseph Smith joe@settoplinux.org wrote:
YAHOO!!!! I HAVE VGA!! Well there is definitely something wacked out on x86emu and yabel. For
the
hell of it I tried VM86 and VGA comes right up with no errors. And VM86
is
way faster x86emu and yabel. With my debug level still at 9 and a 5
second
delay for filo, I am at the filo prompt in 15 seconds :-) This used to take about 25-30 seconds with x86emu.
One question, is this normal for VM86? (from bootlog)
PCI: 00:02.0 init
On mainboard, rom address for PCI: 00:02.0 = fff00000
PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040
PCI ROM Image, Vendor 8086, Device 3577,
PCI ROM Image, Class Code 030000, Code Type 00
copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes
biosint: INT# 0xd
biosint: eax 0x23fddfef ebx 0x0 ecx 0x2f6 edx 0x3b4
biosint: ebp 0x10fac esp 0xc89 edi 0x4028 esi 0x24028
biosint: ip 0xffff cs 0xc000 flags 0x813
biosint: Oops, exception 13
Stack contents: 0xffff 0xc000 0x0813 0xbffd 0xf7fb 0xffdf 0xffff 0xbfff 0xabf3 0xff55 0x55ff 0xf3fa 0x5cfd 0xffeb 0xffff 0xf9ff 0xff7f 0x7fbd 0xfffd 0xffff 0xf3ff 0xffdf 0x7ffe 0xdffb 0xfffb 0xffd7 0x5fff 0xf1f7 0xf6ee 0x7faf 0xffff 0xedff 0xeff5 0xffbd 0xfbff 0x7ebf 0xffeb 0xf75f 0x5fff 0xfffa 0xfff6 0xb75f 0xffff 0xf7ff 0x5ffd 0xfdfd 0xfbff 0xfefd 0xf7f7 0xffaf 0xfbff 0xffff 0xebef 0xfb7e 0xdfff 0xff73 0xaf97 0xffff 0xdfbf 0xffff 0xfbff 0xfffb 0xbf7f 0xe9ef 0x7ddf 0xfe9d 0xfff7 0xffff 0x3bff 0xffcf 0xffff 0x5f7f 0xbfbb 0xff7f 0xdfff 0xebfe 0x7fff 0xffaf 0xffff 0xef8f 0x7f5f 0xffbd 0xff7f 0xbf6f 0xf3ef 0xff5e 0xf7ff 0xbfff 0xd3ff 0xff5e 0xf7df 0xffff 0xdf5f 0x7fbf 0xffff 0xefbf 0x7fdf 0xbfbf 0xffff 0xffb7 0xf7ff 0xff7f 0x7fff 0xff77 0xdbef 0xbfd7 0xffff 0xdfdb 0x7fce 0xffed 0xfeff 0xf9ff 0xf7ff 0xfbff 0xbaff 0xffcf 0xabbb 0xff56 0xffff 0xffff 0x3fcf 0xffde 0x7fff 0xfffa 0x7fc7 0xffd7 0xefff 0xe3af 0xfef7 0xbfeb 0x7fef 0xbfdd 0xbbfb 0xffff 0xf7ff 0xbefe 0xafff 0xdb5f 0xdffb 0xebff 0xdfff 0xff9f 0xfffd 0xf5ff 0x7ddf 0xffbd 0xfaef 0xbeff 0xfbbb 0xffd7 0xffff 0xfbff 0xa7eb 0xfff6 0xdfff 0xeffe 0xfeff 0xffed 0xeaff 0xbffb 0xd9fd 0xfffd 0xffff 0x7fc5 0xebab 0xfbdf 0xdfbf 0xbf7e 0xe7f6 0xafd6 0xfffe 0xfdfe 0x5cf9 0xfffb 0xfeff 0xfbfd 0xfffd 0xffbe 0xffff 0xffff 0xffff 0xfbaf 0xffff 0xfef7 0x7fff 0xffff 0x7fff 0xfff7 0xeffb 0x7fbf 0xeeff 0x6dbf 0xb4f7 0x7fa0 0xfbfe 0xdf3d 0xb7bb 0xbfd7 0xffff 0xff7f 0xfffe 0xffd7 0xf5df 0xfbff 0xfdcd 0xffaf 0xffff 0xeb9f 0x5cff 0x7fbb 0xef7f 0xffdf 0xaeff 0xff77 0x7fff 0x7fff 0xa3aa 0xfb7e 0xffff 0xeff7 0xbddf 0xffaf 0xff7f 0xffee 0xdefd 0xfeb9 0xfbf5 0x5f8f 0xb7ff 0xa357 0x7ffb 0x3fff 0x37af 0xff5e 0xffdf 0xe7ff 0xfcd7 0xffe9 0xfeff 0xefff 0x7bff 0xdfdf 0xffff 0xdfdf 0xffff 0xf773 0xd7bb 0xdfff 0xbfeb 0xf74f 0x7ffa 0xf7ff 0xdfff 0xdfea 0xfef7 0xebdf 0xdc77 0xfeff 0xe77f 0xfffd 0xebfb 0xfff7 0xbfff 0xfefb 0xefff 0xff7f 0xffff 0xfd7f 0xfeff 0xfea7 0xfbff 0xedf7 0x7cdd 0x7fed 0xfee7 0xdeff 0xe75d 0xfff6 0x7fff 0xfebf 0xdfbb 0xffff 0xffff 0xf7ff 0x5edf 0xfdeb 0xeefd 0xf7f7 0xfdfd 0x7fbb 0xfeef 0xbffd 0xa9fe 0xffde 0xfffe 0xbf7f 0xeffb 0xf7fe 0x7dff 0xeb7e 0xfdd7 0xfff9 0xfb7f 0xffff 0x7c7f 0xff9f 0xfef5 0x9edf 0xe7be 0xff77 0xffdb 0xfff6 0xbf9b 0xf7f7 0xffff 0xfff2 0xdf1d 0xfe6d 0xffff 0xed7e 0x7d77 0xfc9d 0x7eef 0x5efd 0xfffb 0xff57 0x75df 0xff7f 0xfb2b 0xff57 0xfffa 0xff97 0xd9df 0xfffd 0xffff 0xefdf 0x55ff 0xffeb 0xff6f 0xdf7d 0xe7fb 0xff56 0xffff 0xffff 0xfffe 0xf777 0xdfff 0xffff 0xffff 0xfff5 0xffff 0xf1ff 0xffdf 0xffff 0xffff 0xffdd 0xffeb 0xeb5f 0xffff 0xfeff 0xfbab 0xfb77 0xfdff 0xffff 0xffdf 0xff3f 0xffff 0xffef 0x7fff 0xffef 0xffff 0xffff 0xf7bf 0xff7f 0xffff 0xfff7 0xf7ff 0xff7e 0xb4ff 0x1e03 0x7f45 0xac03 0x710f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0xe4ba 0x010f 0x94e0 0x0649 0x0000 0x01c0 0x8000 0x0000 0xf600 0x712f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0x3eba 0x40ba 0x0000 0x4000 0x04fc 0x6421 0xfabf 0x040f 0x0921 0xf400 0xf4bf 0x46bf 0x4100 0x00b0 0x6600
biosint: Bailing out
I guess I spoke too soon, when booting Linux I am getting a bunch of page_fault Kernel panics :-( WTF!
Ah, looks like "biosint: Oops, exception 13" is a CPU-generated exception. Maybe I need to take a look at the CPU code the IP1000 uses??? Maybe it need a microcode update???
On Thu, 23 Apr 2009 15:18:23 -0400, Joseph Smith joe@settoplinux.org wrote:
On Thu, 23 Apr 2009 01:19:25 -0400, Joseph Smith joe@settoplinux.org wrote:
On Wed, 22 Apr 2009 23:58:21 -0400, Joseph Smith joe@settoplinux.org wrote:
YAHOO!!!! I HAVE VGA!! Well there is definitely something wacked out on x86emu and yabel. For
the
hell of it I tried VM86 and VGA comes right up with no errors. And VM86
is
way faster x86emu and yabel. With my debug level still at 9 and a 5
second
delay for filo, I am at the filo prompt in 15 seconds :-) This used to take about 25-30 seconds with x86emu.
One question, is this normal for VM86? (from bootlog)
PCI: 00:02.0 init
On mainboard, rom address for PCI: 00:02.0 = fff00000
PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040
PCI ROM Image, Vendor 8086, Device 3577,
PCI ROM Image, Class Code 030000, Code Type 00
copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes
biosint: INT# 0xd
biosint: eax 0x23fddfef ebx 0x0 ecx 0x2f6 edx 0x3b4
biosint: ebp 0x10fac esp 0xc89 edi 0x4028 esi 0x24028
biosint: ip 0xffff cs 0xc000 flags 0x813
biosint: Oops, exception 13
Stack contents: 0xffff 0xc000 0x0813 0xbffd 0xf7fb 0xffdf 0xffff 0xbfff 0xabf3 0xff55 0x55ff 0xf3fa 0x5cfd 0xffeb 0xffff 0xf9ff 0xff7f 0x7fbd 0xfffd 0xffff 0xf3ff 0xffdf 0x7ffe 0xdffb 0xfffb 0xffd7 0x5fff 0xf1f7 0xf6ee 0x7faf 0xffff 0xedff 0xeff5 0xffbd 0xfbff 0x7ebf 0xffeb 0xf75f 0x5fff 0xfffa 0xfff6 0xb75f 0xffff 0xf7ff 0x5ffd 0xfdfd 0xfbff 0xfefd 0xf7f7 0xffaf 0xfbff 0xffff 0xebef 0xfb7e 0xdfff 0xff73 0xaf97 0xffff 0xdfbf 0xffff 0xfbff 0xfffb 0xbf7f 0xe9ef 0x7ddf 0xfe9d 0xfff7 0xffff 0x3bff 0xffcf 0xffff 0x5f7f 0xbfbb 0xff7f 0xdfff 0xebfe 0x7fff 0xffaf 0xffff 0xef8f 0x7f5f 0xffbd 0xff7f 0xbf6f 0xf3ef 0xff5e 0xf7ff 0xbfff 0xd3ff 0xff5e 0xf7df 0xffff 0xdf5f 0x7fbf 0xffff 0xefbf 0x7fdf 0xbfbf 0xffff 0xffb7 0xf7ff 0xff7f 0x7fff 0xff77 0xdbef 0xbfd7 0xffff 0xdfdb 0x7fce 0xffed 0xfeff 0xf9ff 0xf7ff 0xfbff 0xbaff 0xffcf 0xabbb 0xff56 0xffff 0xffff 0x3fcf 0xffde 0x7fff 0xfffa 0x7fc7 0xffd7 0xefff 0xe3af 0xfef7 0xbfeb 0x7fef 0xbfdd 0xbbfb 0xffff 0xf7ff 0xbefe 0xafff 0xdb5f 0xdffb 0xebff 0xdfff 0xff9f 0xfffd 0xf5ff 0x7ddf 0xffbd 0xfaef 0xbeff 0xfbbb 0xffd7 0xffff 0xfbff 0xa7eb 0xfff6 0xdfff 0xeffe 0xfeff 0xffed 0xeaff 0xbffb 0xd9fd 0xfffd 0xffff 0x7fc5 0xebab 0xfbdf 0xdfbf 0xbf7e 0xe7f6 0xafd6 0xfffe 0xfdfe 0x5cf9 0xfffb 0xfeff 0xfbfd 0xfffd 0xffbe 0xffff 0xffff 0xffff 0xfbaf 0xffff 0xfef7 0x7fff 0xffff 0x7fff 0xfff7 0xeffb 0x7fbf 0xeeff 0x6dbf 0xb4f7 0x7fa0 0xfbfe 0xdf3d 0xb7bb 0xbfd7 0xffff 0xff7f 0xfffe 0xffd7 0xf5df 0xfbff 0xfdcd 0xffaf 0xffff 0xeb9f 0x5cff 0x7fbb 0xef7f 0xffdf 0xaeff 0xff77 0x7fff 0x7fff 0xa3aa 0xfb7e 0xffff 0xeff7 0xbddf 0xffaf 0xff7f 0xffee 0xdefd 0xfeb9 0xfbf5 0x5f8f 0xb7ff 0xa357 0x7ffb 0x3fff 0x37af 0xff5e 0xffdf 0xe7ff 0xfcd7 0xffe9 0xfeff 0xefff 0x7bff 0xdfdf 0xffff 0xdfdf 0xffff 0xf773 0xd7bb 0xdfff 0xbfeb 0xf74f 0x7ffa 0xf7ff 0xdfff 0xdfea 0xfef7 0xebdf 0xdc77 0xfeff 0xe77f 0xfffd 0xebfb 0xfff7 0xbfff 0xfefb 0xefff 0xff7f 0xffff 0xfd7f 0xfeff 0xfea7 0xfbff 0xedf7 0x7cdd 0x7fed 0xfee7 0xdeff 0xe75d 0xfff6 0x7fff 0xfebf 0xdfbb 0xffff 0xffff 0xf7ff 0x5edf 0xfdeb 0xeefd 0xf7f7 0xfdfd 0x7fbb 0xfeef 0xbffd 0xa9fe 0xffde 0xfffe 0xbf7f 0xeffb 0xf7fe 0x7dff 0xeb7e 0xfdd7 0xfff9 0xfb7f 0xffff 0x7c7f 0xff9f 0xfef5 0x9edf 0xe7be 0xff77 0xffdb 0xfff6 0xbf9b 0xf7f7 0xffff 0xfff2 0xdf1d 0xfe6d 0xffff 0xed7e 0x7d77 0xfc9d 0x7eef 0x5efd 0xfffb 0xff57 0x75df 0xff7f 0xfb2b 0xff57 0xfffa 0xff97 0xd9df 0xfffd 0xffff 0xefdf 0x55ff 0xffeb 0xff6f 0xdf7d 0xe7fb 0xff56 0xffff 0xffff 0xfffe 0xf777 0xdfff 0xffff 0xffff 0xfff5 0xffff 0xf1ff 0xffdf 0xffff 0xffff 0xffdd 0xffeb 0xeb5f 0xffff 0xfeff 0xfbab 0xfb77 0xfdff 0xffff 0xffdf 0xff3f 0xffff 0xffef 0x7fff 0xffef 0xffff 0xffff 0xf7bf 0xff7f 0xffff 0xfff7 0xf7ff 0xff7e 0xb4ff 0x1e03 0x7f45 0xac03 0x710f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0xe4ba 0x010f 0x94e0 0x0649 0x0000 0x01c0 0x8000 0x0000 0xf600 0x712f 0x0a49 0x80bd 0x0000 0x0400 0x0121 0xe400 0x010f 0xe200 0x000f 0x0000 0x01c0 0xb400 0x0003 0x0200 0x0100 0xff00 0x00ff 0x7c00 0x3eba 0x40ba 0x0000 0x4000 0x04fc 0x6421 0xfabf 0x040f 0x0921 0xf400 0xf4bf 0x46bf 0x4100 0x00b0 0x6600
biosint: Bailing out
I guess I spoke too soon, when booting Linux I am getting a bunch of page_fault Kernel panics :-( WTF!
Ah, looks like "biosint: Oops, exception 13" is a CPU-generated
exception.
Maybe I need to take a look at the CPU code the IP1000 uses??? Maybe it need a microcode update???
And why would INT 13 be called anyways? It has nothing to do with VGA???
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On 23.04.2009 21:34 Uhr, Joseph Smith wrote:
And why would INT 13 be called anyways? It has nothing to do with VGA???
It's exception 13 (decimal 13)
int13 is exception 0x13...
exceptions 0...0xf are not interrupts but hardware exceptions
0: division by zero ... 13: illegal instruction ...
The code makes some assumptions and then jumps into the wild. A microcode update will not help, unfortunately.
On Thu, 23 Apr 2009 21:39:08 +0200, Stefan Reinauer stepan@coresystems.de wrote:
On 23.04.2009 21:34 Uhr, Joseph Smith wrote:
And why would INT 13 be called anyways? It has nothing to do with VGA???
It's exception 13 (decimal 13)
int13 is exception 0x13...
exceptions 0...0xf are not interrupts but hardware exceptions
0: division by zero ... 13: illegal instruction ...
The code makes some assumptions and then jumps into the wild. A microcode update will not help, unfortunately.
Ok then, why is it doing it??? There seems to be alot of assembly in VM86 which I am not so good at...
On Wed, Apr 22, 2009 at 8:58 PM, Joseph Smith joe@settoplinux.org wrote:
YAHOO!!!! I HAVE VGA!! Well there is definitely something wacked out on x86emu and yabel. For the hell of it I tried VM86 and VGA comes right up with no errors. And VM86 is way faster x86emu and yabel. With my debug level still at 9 and a 5 second delay for filo, I am at the filo prompt in 15 seconds :-) This used to take about 25-30 seconds with x86emu.
One question, is this normal for VM86? (from bootlog)
PCI: 00:02.0 init
On mainboard, rom address for PCI: 00:02.0 = fff00000
PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040
PCI ROM Image, Vendor 8086, Device 3577,
PCI ROM Image, Class Code 030000, Code Type 00
copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes
biosint: INT# 0xd
biosint: eax 0x23fddfef ebx 0x0 ecx 0x2f6 edx 0x3b4
biosint: ebp 0x10fac esp 0xc89 edi 0x4028 esi 0x24028
biosint: ip 0xffff cs 0xc000 flags 0x813
biosint: Oops, exception 13
this is really, really bad.
You don't want this to happen.
It's going to be way easier to debug if you run in linux, user more x86emu, and turn on instruction tracing. Something's going very wrong.
Many of these vga bioses are very badly written and will fail on weird ways. I think you've got one.
ron
On Fri, 24 Apr 2009 08:15:58 -0700, ron minnich rminnich@gmail.com wrote:
On Wed, Apr 22, 2009 at 8:58 PM, Joseph Smith joe@settoplinux.org
wrote:
YAHOO!!!! I HAVE VGA!! Well there is definitely something wacked out on x86emu and yabel. For
the
hell of it I tried VM86 and VGA comes right up with no errors. And VM86
is
way faster x86emu and yabel. With my debug level still at 9 and a 5
second
delay for filo, I am at the filo prompt in 15 seconds :-) This used to
take
about 25-30 seconds with x86emu.
One question, is this normal for VM86? (from bootlog)
PCI: 00:02.0 init
On mainboard, rom address for PCI: 00:02.0 = fff00000
PCI Expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040
PCI ROM Image, Vendor 8086, Device 3577,
PCI ROM Image, Class Code 030000, Code Type 00
copying VGA ROM Image from fff00000 to 0xc0000, 0x10000 bytes
biosint: INT# 0xd
biosint: eax 0x23fddfef ebx 0x0 ecx 0x2f6 edx 0x3b4
biosint: ebp 0x10fac esp 0xc89 edi 0x4028 esi 0x24028
biosint: ip 0xffff cs 0xc000 flags 0x813
biosint: Oops, exception 13
this is really, really bad.
You don't want this to happen.
It's going to be way easier to debug if you run in linux, user more x86emu, and turn on instruction tracing. Something's going very wrong.
Many of these vga bioses are very badly written and will fail on weird ways. I think you've got one.
Well, After alot of trial and error, I think I may have found the issue. I still don't know how to fix it yet though. It appears to be something with IRQ Routing. I think the graphics is NOT supposed to have an IRQ asigned to it. In the past I have seen bios settings that you have an option to asign an IRQ to the graphics or not. If you look at lspci from the proprietary bios everything has an IRQ but the graphics device. I setup the irq routing and PIRQ's just the way the proprietary bios is and it boots ok (no errors from VM86) but in Linux it says everything is IRQ 0. In the current coreboot code the IRQ routing is setup the same as the RM4100.
Can I just remove the graphics device in irq_tables.c? Or will that really screw up the routing?
I have three different vga bios's and they all do the same thing.
On Fri, Apr 24, 2009 at 8:36 AM, Joseph Smith joe@settoplinux.org wrote:
Can I just remove the graphics device in irq_tables.c? Or will that really screw up the routing?
won't hurt anything to try.
ron
On Fri, 24 Apr 2009 10:59:26 -0700, ron minnich rminnich@gmail.com wrote:
On Fri, Apr 24, 2009 at 8:36 AM, Joseph Smith joe@settoplinux.org
wrote:
Can I just remove the graphics device in irq_tables.c? Or will that
really
screw up the routing?
won't hurt anything to try.
Or should I just tell it to use IRQ 0 like: {0x00,(0x02<<3)|0x0, {{0x60, 0x0001}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
On Fri, Apr 24, 2009 at 12:05 PM, Joseph Smith joe@settoplinux.org wrote:
Or should I just tell it to use IRQ 0 like: {0x00,(0x02<<3)|0x0, {{0x60, 0x0001}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
no, just delete the line
ron
Well, I have confirmed the problem. Looks there is something crazy about how the ethernet and modem (even though the IP1000 doesn't actually have a modem) are setup. If I disable the ICH4 ethernet and enable the AC97 ICH4 modem, sure as shit it boots up everytime (VGA too) and all IRQS look great. If I enable both of them EVERYTHING gets IRQ 0, and I have issues. If I enable ethernet and disable the modem (this is the way it should be) EVERYTHING gets IRQ 0, and I have issues.....
Anyone seen this kind of thing before? I have no idea how to fix this one....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
great. If I enable both of them EVERYTHING gets IRQ 0, and I have issues. If I enable ethernet and disable the modem (this is the way it should be) EVERYTHING gets IRQ 0, and I have issues.....
Seems like just you are having a IRQ routing problem? Do you use MP-table or PIR?
Rudolf
On Wed, 29 Apr 2009 22:22:00 +0200, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
great. If I enable both of them EVERYTHING gets IRQ 0, and I have
issues.
If I enable ethernet and disable the modem (this is the way it should
be)
EVERYTHING gets IRQ 0, and I have issues.....
Seems like just you are having a IRQ routing problem? Do you use
MP-table
or PIR?
I use irq_tables.c generated from getpir. I really don't think this a a irq routing problem considering both devices are on a different INT and both devices use a different PIRQ. |-INT B modem {0x00,(0x1d<<3)|0x0, {{0x60, 0x1ef8}, {0x63, 0x1ef8}, {0x62, 0x1ef8}, {0x6b, 0x01ef8}}, 0x0, 0x0},
|-INT A Ethernet {0x01,(0x08<<3)|0x0, {{0x68, 0x1ef8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
but you have been speaking that it gets IRQ0 right?
Do you mean it is that one from the PCI space bios IRQ?
Rudolf
On Wed, 29 Apr 2009 23:55:14 +0200, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
but you have been speaking that it gets IRQ0 right?
Do you mean it is that one from the PCI space bios IRQ?
Every PCI device gets an IRQ 0. This tells me that there is something wrong with the interrupt controllers, like lower IO space that is not readable or writeable. I will explain in depth later when I have some time to attach some before and after bootlogs.
On Wed, Apr 29, 2009 at 3:04 PM, Joseph Smith joe@settoplinux.org wrote:
Every PCI device gets an IRQ 0. This tells me that there is something wrong with the interrupt controllers, like lower IO space that is not readable or writeable. I will explain in depth later when I have some time to attach some before and after bootlogs.
Only maybe true. teh other possibility is that linux was unhappy with the IRQ table, and there are lots of reasons this can happen. linux is not very good at notifying you about issues with IRQ tables -- it just skips it if it does not like it.
ron
On Wed, 29 Apr 2009 18:04:02 -0400, Joseph Smith joe@settoplinux.org wrote:
On Wed, 29 Apr 2009 23:55:14 +0200, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
but you have been speaking that it gets IRQ0 right?
Do you mean it is that one from the PCI space bios IRQ?
Every PCI device gets an IRQ 0.
Note to self: If every PCI device gets an IRQ 0 it means your irq table is not readable by the OS because the check sum is invalid.
On 24.04.2009 17:15 Uhr, ron minnich wrote:
It's going to be way easier to debug if you run in linux, user more x86emu, and turn on instruction tracing.
How so?
Stefan
On Fri, Apr 24, 2009 at 9:47 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 24.04.2009 17:15 Uhr, ron minnich wrote:
It's going to be way easier to debug if you run in linux, user more x86emu, and turn on instruction tracing.
How so?
I'll just say it's been easier for me :-)
ron
On Fri, 24 Apr 2009 10:58:39 -0700, ron minnich rminnich@gmail.com wrote:
On Fri, Apr 24, 2009 at 9:47 AM, Stefan Reinauer stepan@coresystems.de wrote:
On 24.04.2009 17:15 Uhr, ron minnich wrote:
It's going to be way easier to debug if you run in linux, user more x86emu, and turn on instruction tracing.
How so?
I'll just say it's been easier for me :-)
Hmm, but how will that help me?
On 20.04.2009 18:53 Uhr, Joseph Smith wrote:
On Mon, 20 Apr 2009 17:50:00 +0200, Stefan Reinauer stepan@coresystems.de wrote:
On 20.04.2009 17:38 Uhr, ron minnich wrote:
On Mon, Apr 20, 2009 at 8:27 AM, Joseph Smith joe@settoplinux.org
wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds
over
the past 6 months or so. The unexpected exception errors are random
errors
and are different every time, but seem to happen right about the time
the
vga rom loads. I think it has something to do with x86emu and yabel
loading
the vga rom. If I change it to boot up with out graphics it boots up
every
time, no problem. If I enable the vga device (2.0) and allocate vga
memory
but not load the vga rom it boots up every time no problem. So this
tells
me it doesn’t like something the rom emulator is doing, right? This
is
very strange because I do not have this problem with the RM4100… just
the
IP1000 (brother boards).
You could well be tickling a but in either emulator. These are hard to find. It's handy to have a user-mode wrapper so you can run these emulators under linux -- much easier to find that way. Is this possible with YABEL?
Could I try something like vbetool?
Not right now, but you can connect to coreboot via gdb over serial, which gives you a user space frontend with single stepping...
Do you mean http://www.coreboot.org/Debugging ?? I tried that, but the errors are different everytime and not always in the exact place so it is hard to put a finger on it using this method.
Did you try a backtrace in those cases? What did it say?
Stefan
Do you mean http://www.coreboot.org/Debugging ?? I tried that, but the errors are different everytime and not always in
the
exact place so it is hard to put a finger on it using this method.
Did you try a backtrace in those cases? What did it say?
Stefan
Here is my GDB dumps they all seem to be related to x86emu but different every time? Do you see anything useful??
(gdb) file /home/joe/coreboot-v2/targets/thomson/ip1000/ip1000/fallback/coreboot_ram Reading symbols from /home/joe/coreboot-v2/targets/thomson/ip1000/ip1000/fallback/coreboot_ram...(no debugging symbols found)...done. (gdb) set remotebaud 115200 (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 warning: unrecognized item "S04" in "qSupported" response 0x0000002f in ?? () (gdb) bt #0 0x0000002f in ?? () #1 0x00014914 in rdb () #2 0x000c4984 in ?? () #3 0x00000001 in ?? () #4 0x00000007 in ?? () #5 0x0000d7ae in x86emuOp_call_near_IMM () #6 0x0000002f in ?? () #7 0x0000bf73 in X86EMU_exec () #8 0x00018e86 in ?? () #9 0x00027b6c in ?? () #10 0x00000000 in ?? ()
(gdb) file /home/joe/coreboot-v2/targets/thomson/ip1000/ip1000/fallback/coreboot_ram Reading symbols from /home/joe/coreboot-v2/targets/thomson/ip1000/ip1000/fallback/coreboot_ram...(no debugging symbols found)...done. (gdb) set remotebaud 115200 (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response 0x00014911 in rdb () (gdb) bt #0 0x00014911 in rdb () #1 0x000ffff7 in ?? () #2 0x00000001 in ?? () #3 0x00000007 in ?? () #4 0x00000005 in ?? () #5 0x00000003 in ?? () #6 0x0000002f in ?? () #7 0x000ffff7 in ?? () #8 0x0000bf73 in X86EMU_exec () #9 0x00018e86 in ?? () #10 0x00027b6c in ?? () #11 0x00000000 in ?? ()
(gdb) file /home/joe/coreboot-v2/targets/thomson/ip1000/ip1000/fallback/coreboot_ram Reading symbols from /home/joe/coreboot-v2/targets/thomson/ip1000/ip1000/fallback/coreboot_ram...(no debugging symbols found)...done. (gdb) set remotebaud 115200 (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response 0x0000002f in ?? () (gdb) bt #0 0x0000002f in ?? () #1 0x000148ff in rdw () #2 0x000c63ca in ?? () #3 0x00000002 in ?? () #4 0x00027b2c in ?? () #5 0x0000b75b in fetch_data_word () #6 0x000ffff7 in ?? () #7 0x0000d981 in x86emuOp_mov_AX_M_IMM () #8 0x000c63ca in ?? () #9 0x00000001 in ?? () #10 0x000000ef in ?? () #11 0x0000d95c in x86emuOp_mov_AX_M_IMM () #12 0x00000000 in ?? ()
Joseph Smith wrote:
Here is my GDB dumps they all seem to be related to x86emu but different every time? Do you see anything useful??
There is debugging support in x86emu. Look for X86EMU_trace_on(). You may also have to enable some debug flag in the x86emu source.
It'll show full trace information for each emulated instruction.
//Peter
On Mon, Apr 20, 2009 at 5:38 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Apr 20, 2009 at 8:27 AM, Joseph Smith joe@settoplinux.org wrote:
You could well be tickling a but in either emulator. These are hard to find. It's handy to have a user-mode wrapper so you can run these emulators under linux -- much easier to find that way. Is this possible with YABEL?
I know that Ben Herrenschmidt used biosemu (the predecessor of YABEL) as a cmdline utility in linux... i think he did send me the code some time ago... i can look into that, but since i am on vacation right now, i wont have time for that until sometime in May...
Pattrick
On Sat, 25 Apr 2009 22:58:11 +0200, Pattrick Hueper phueper@hueper.net wrote:
On Mon, Apr 20, 2009 at 5:38 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Apr 20, 2009 at 8:27 AM, Joseph Smith joe@settoplinux.org
wrote:
You could well be tickling a but in either emulator. These are hard to find. It's handy to have a user-mode wrapper so you can run these emulators under linux -- much easier to find that way. Is this possible with YABEL?
I know that Ben Herrenschmidt used biosemu (the predecessor of YABEL) as a cmdline utility in linux... i think he did send me the code some time ago... i can look into that, but since i am on vacation right now, i wont have time for that until sometime in May...
That would be greatly appreciated Pattrick. When ever you get a chance.
On Mon, 20 Apr 2009 11:27:38 -0400, Joseph Smith joe@settoplinux.org wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds over the past 6 months or so. The unexpected exception errors are random
errors
and are different every time, but seem to happen right about the time the vga rom loads. I think it has something to do with x86emu and yabel
loading
the vga rom. If I change it to boot up with out graphics it boots up
every
time, no problem. If I enable the vga device (2.0) and allocate vga
memory
but not load the vga rom it boots up every time no problem. So this tells me it doesn’t like something the rom emulator is doing, right? This is very strange because I do not have this problem with the RM4100… just the IP1000 (brother boards).
I am getting some reports that if you let it sit at the unexpected exception error for a minute and then cycle the power it will boot up the second round. Do I need to add a delay somewhere??? This is driving me crazy!
On Wed, Apr 22, 2009 at 2:32 PM, Joseph Smith joe@settoplinux.org wrote:
On Mon, 20 Apr 2009 11:27:38 -0400, Joseph Smith joe@settoplinux.org wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds over the past 6 months or so. The unexpected exception errors are random
errors
and are different every time, but seem to happen right about the time the vga rom loads. I think it has something to do with x86emu and yabel
loading
the vga rom. If I change it to boot up with out graphics it boots up
every
time, no problem. If I enable the vga device (2.0) and allocate vga
memory
but not load the vga rom it boots up every time no problem. So this tells me it doesn’t like something the rom emulator is doing, right? This is very strange because I do not have this problem with the RM4100… just the IP1000 (brother boards).
I am getting some reports that if you let it sit at the unexpected exception error for a minute and then cycle the power it will boot up the second round. Do I need to add a delay somewhere??? This is driving me crazy!
Have you tried vm86? The one in jetway/j7f2 is already set up for a 512k rom, you'd just need to plug it in.
On Wed, 22 Apr 2009 16:15:38 -0400, Corey Osgood corey.osgood@gmail.com wrote:
On Wed, Apr 22, 2009 at 2:32 PM, Joseph Smith joe@settoplinux.org
wrote:
On Mon, 20 Apr 2009 11:27:38 -0400, Joseph Smith joe@settoplinux.org wrote:
Hello, I keep getting unexpected exception errors on my IP1000 with builds
over
the past 6 months or so. The unexpected exception errors are random
errors
and are different every time, but seem to happen right about the time
the
vga rom loads. I think it has something to do with x86emu and yabel
loading
the vga rom. If I change it to boot up with out graphics it boots up
every
time, no problem. If I enable the vga device (2.0) and allocate vga
memory
but not load the vga rom it boots up every time no problem. So this
tells
me it doesn’t like something the rom emulator is doing, right? This
is
very strange because I do not have this problem with the RM4100…
just
the IP1000 (brother boards).
I am getting some reports that if you let it sit at the unexpected exception error for a minute and then cycle the power it will boot up
the
second round. Do I need to add a delay somewhere??? This is driving me crazy!
Have you tried vm86? The one in jetway/j7f2 is already set up for a 512k rom, you'd just need to plug it in.
Thanks, I think I will try that, then I would at least know that it is an issue with the emulator, but as Ron said "You could well be tickling a but in either emulator."
-
Carl-Daniel Hailfinger -
Corey Osgood -
Joseph Smith -
Myles Watson -
Pattrick Hueper -
Peter Stuge -
ron minnich -
Rudolf Marek -
Stefan Reinauer