[OpenBIOS] Back at it again( PCI Passthrough )

[Joe van Tunen]

On 5/9/18, 7:07 AM, "Segher Boessenkool" <segher at kernel.crashing.org> wrote:

    On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote:
    > Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
    
    Yes; and that is incorrect.  b?branch in interpret mode is only allowed
    for forward branches (which you have here), and it should simply skip that
    much forward (in the fcode stream) if the top of stack was 0.  Not compile
    anything.


The code in OpenBIOS is currently doing it differently. Someone put some effort in making it this way (though README.device says fcode.fs is partly untested). Before changing it, it should be proven that it can't work that way. This current method means all the bytes in the fcode stream are processed in some way. 


On May 9, 2018, at 4:55 AM, Jd Lyons via OpenBIOS <mailto:openbios at openbios.org> wrote:

    I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve):

The output is missing the changes you made to (debug-feval). What did you do to get that debug output? Did you just follow the instructions from README.debugger with b?branch and b(>resolve)? The debug output doesn't show what the second execute-tmp-comp is executing (the first execute-tmp-comp does nothing since depth hasn't returned to tmp-comp-depth yet). I don't see anything wrong with the debug output that you have so far. I think you need to look at debugging all the fcodes after the first b?branch. Can you do a debug trace of execute-tmp-comp?

    Just deleting the b(>resolve) I’m hanging on and replacing it with ff gets a little further,
    and what I’m thinking is these two b(>resolves) and the two b?branch that come before them
    have something to do with the children, NVDA,Display-A and NVDA,Display-B. Maybe something
    to do with display detection, or the set-mode command.

If there's a problem with b?branch, then you shouldn't be using the nvidia rom to test it - use a simplified fcode image instead.

ff is the fcode for end1, but that does nothing while in compile mode. OpenBIOS won't leave compile mode started by b?branch without a corresponding b(>resolve), and it eventually exceeds the temporary compile buffer size, trashing the dictionary, and then causing a hang. Maybe OpenBIOS needs a guard against that? "here!" should probably take two values, the new "here" value and a "limit". Then anything that adds to the dictionary should use that new limit instead of the usual limit.

    Get-mode, show-mode, and set-mode are called twice, I assume once for each display node, so
    something is going wrong with NVDA,Dispaly-A/B, I just don’t know what it is.

They are not executed, because OpenBIOS hasn't left compile mode, because you removed (b>resolve).



On 5/9/18, 11:34 AM, "Mark Cave-Ayland" <mark.cave-ayland at ilande.co.uk> wrote:

    I'm confused here: b?branch is FCode-only and executed as part of the 
    FCode evaluation. The tmp-comp-buf is used to hold the xts derived from 
    the FCode token stream until the point where the branch is resolved.
    
    However I still think for the moment we're digging way to deep here...

I agree. We haven't proved there's anything wrong with b?branch (except that the size of the temporary compile buffer could be exceeded but that's not the problem with the nvidia rom). Running that test fcode image that I mentioned would probably have shown that it works.



On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces at openbios.org on behalf of mark.cave-ayland at ilande.co.uk> wrote:

    I suspect that it's something within that branch failing which is only 
    visible at the final b(>resolve) once the condition is evaluated, so 
    with indentation:

    ...
        
    Most of that looks fairly normal, so I'd start by looking at the 0x9bd 
    and 0xa08 FCodes which will have been generated further up in your 
    output file.
    
    I suspect you'll end up converting chunks of FCode back into Forth to 
    figure out which part is failing.
    
I think a debug trace of execute-tmp-comp might work to get to what part of 0x9bd or 0xa08 is causing the exception?