Greetings all,
I've just subscribed. I've been googling around for quite a while now, looking for an interesting project that isn't already almost done, and that isn't essentially closed to significant contributions from people outside whatever organization sponsors the project. That leaves out a lot of otherwise interesting projects-- such as the kernel trace work at opersys.com, or Fedora, or the crash-dump project (lkcd) just for a few examples.
I confess I'm not just interested in "open source" for any altruistic reason-- I'm really looking for a way to establish credentials in the OS "community" (a much-overused word). I bet such be will be increasingly important in future years.
A little context: I'm using Fedora (FC3) here at work (nobody seems to mind that I can't read half of HP's internal web pages, which mostly only work right with IE; and I *certainly* don't mind! :-) I naturally poked around Redhat's site looking for Fedora work, but all they really offer is a bugzilla listing. 98% of reported FC bugs are either with badly outdated releases, or expansion hardware I don't have.
However there *does* seem to be an issue with FC3 and the 2.6.11 kernel-- with several reports of solid system hangs/lockups, where the computer essentially freezes in place. Now on an Alpha, all you'd have to do is hit the halt button, type "cra" at the ">>>" prompt, and reboot; once in multiuser you'll have a crash dump waiting for your debugging pleasure. But I've never seen the PC that had a halt button that didn't instantly put you in POST, which kinda limits the chances of copying memory to the swap partition. So at least on the PC architecture, there doesn't seem to be a reliable way to do a postmortem on a wedged kernel.
Obviously, the BIOS is a problem. Which leads me to you. What needs doing?
thanks!
I like the idea.
We really need this capability.
ron
On Thu, 2005-05-19 at 09:46 -0600, Ronald G. Minnich wrote:
I like the idea.
We really need this capability.
Man! You mean after ALL THESE YEARS, I finally thought of something useful? ...wait, I gotta put my teeth back in... there that's better.
OK, I'd like some help then, a mentor maybe, to direct my studies in getting up to speed. Feel free to reply off-list: what's the best way to start? If I need to read 3.8MB of source, which are the important parts?
Thats a great idea man.
I'm also an OpenBIOS 'newbie' (although not new to writing bring-up firmware on other platforms), and am interested in getting involved.
One question.. I seem to have noticed that there doesnt appear to be a lot of chipset specific code in CVS (or perhaps i'm just missing it somewhere). I read in the x86/entry.S that the cpu is expected to be in protected mode with flat memory setup already. Does this mean that theres a 'missing link' that needs to be done to get the chipsets up and memory initialized? Or is it just somewhere else that I've missed?.
Thanks
-San
Douglas Frank wrote:
On Thu, 2005-05-19 at 09:46 -0600, Ronald G. Minnich wrote:
I like the idea.
We really need this capability.
Man! You mean after ALL THESE YEARS, I finally thought of something useful? ...wait, I gotta put my teeth back in... there that's better.
OK, I'd like some help then, a mentor maybe, to direct my studies in getting up to speed. Feel free to reply off-list: what's the best way to start? If I need to read 3.8MB of source, which are the important parts?
On Thu, 19 May 2005, San Mehat wrote:
One question.. I seem to have noticed that there doesnt appear to be a lot of chipset specific code in CVS (or perhaps i'm just missing it somewhere). I read in the x86/entry.S that the cpu is expected to be in protected mode with flat memory setup already. Does this mean that theres a 'missing link' that needs to be done to get the chipsets up and memory initialized? Or is it just somewhere else that I've missed?.
the idea now is that on raw iron, openbios runs on top of linuxbios.
I'm working on ideas for a merge, so you just build one thing.
ron
* Douglas Frank frank@zk3.dec.com [050519 18:09]:
Man! You mean after ALL THESE YEARS, I finally thought of something useful? ...wait, I gotta put my teeth back in... there that's better.
OK, I'd like some help then, a mentor maybe, to direct my studies in getting up to speed. Feel free to reply off-list: what's the best way to start? If I need to read 3.8MB of source, which are the important parts?
I've added a new task to the openbios issue tracking system regarding this thing: https://www.openbios.org/roundup/openbios/task12
First you should get a test machine so you can flash LinuxBIOS+OpenBIOS and experiment with it..
Copying away memory is pretty close to the reset vector I guess. IIRC LinuxBIOS unconditionally initializes the ram controller after a reset, because it is so fast anyways..
Maybe it shouldn't?
Stefan
Stefan Reinauer stepan@openbios.org writes:
- Douglas Frank frank@zk3.dec.com [050519 18:09]:
Man! You mean after ALL THESE YEARS, I finally thought of something useful? ...wait, I gotta put my teeth back in... there that's better.
OK, I'd like some help then, a mentor maybe, to direct my studies in getting up to speed. Feel free to reply off-list: what's the best way to start? If I need to read 3.8MB of source, which are the important parts?
I've added a new task to the openbios issue tracking system regarding this thing: https://www.openbios.org/roundup/openbios/task12
First you should get a test machine so you can flash LinuxBIOS+OpenBIOS and experiment with it..
Copying away memory is pretty close to the reset vector I guess. IIRC LinuxBIOS unconditionally initializes the ram controller after a reset, because it is so fast anyways..
And reinitializing the whole system makes for a very reliable reboot.
Maybe it shouldn't?
An interesting question is how much of this overlaps with kexec-on-panic. It could be that all we need to do is get the routing right nmi/panic button to the kernel's kexec-on-panic handler.
I meant to reply earlier but I lost track of this thread.
Eric
-
Douglas Frank -
ebiederman＠lnxi.com -
Ronald G. Minnich -
San Mehat -
Stefan Reinauer