RMI status

[Randall Stewart]

On Feb 11, 2010, at 6:55 AM, C. Jayachandran wrote:

> On Thu, Feb 11, 2010 at 7:47 PM, Randall Stewart <rrs at lakerest.net>  
> wrote:
>> All:
>>
>> With an svn update to the latest head (of yesterday 2/10 am), I added
>> JC's patch for the rge fix (which I committed yesterday).. and then I
>> started a buildworld over NFS and headed off to work.
>>
>> JC had mentioned a panic way into the buildworld that he saw, I did
>> NOT see it.. basically my buildworld completed yesterday at about
>> 2pm Pacific :-) [not to bad about 7 hours for a buildworld single  
>> core]..
>> YEAH!!!
>
> Great news!
>
>> Now I am not sure if JC's panic was something that has been fixed and
>> he missed it.. or still looming. (JC please do an svn update and  
>> retry
>> to see if you can independently recreate my result). If it panics
>> on you again I will have to work on trying to recreate it.
>
> I usually try buildworld with '-j16' to stress the system, I got the
> crash after a few hours of buildworld. Anyway I will update to the
> latest trunk, remove my local changes and see if I get the same issue.
> If I can get it to crash consistently on my setup, I'll do some more
> work on this.

Ahh.. I don't use a -jN since there is only one core
currently... That would use more memory... maybe running
the kernel out of memory below the magic 512Meg mark. If that
happens things will break...




>
>> I am going to consider RMI stable at this point (unless JC cannot
>> reproduce my results).. and now move on to my to-do list:
>>
>> - SMP (Neel has a great start here so hopefully we can use
>>       some of his great work and jump RMI to at least 8 core
>>       pretty quickly .. I will leave threads off until I can
>>       figure out a nice way to fix the pcpu issue).
>> - Drivers yet to work
>>   o PCI
>>   o USB
>
> I had worked on the original PCI and USB drivers (6.4) so I can take
> these up in parallel if you don't mind.


I would be GLAD to hand that off to you ;-)


>
>> - n64..
>
> Any plan of doing n32?  n32 with 64-bit physical address support may
> be a better suited base configuration for XLR than o32, because we can
> use all of the memory and the 64 bit support, without having to go
> full 64-bit.

Not sure.. Warner, what do you think.. should we mess with n32?

R


>
>> So basically I am going to move on and see if I can break it now that
>> I have it stable.. I will try to only break things inside #ifdef  
>> SMP though
>> ;-)
>
> Regards,
> JC.
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)