LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 ... 4 5 [6]   Go Down

Author Topic: LisaEm 1.2.7-RC3a support bug reports  (Read 5443 times)

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

D.Finni

  • Sr. Member
  • ****
  • Karma: +15/-0
  • Offline Offline
  • Posts: 62
Re: LisaEm 1.2.7-RC3 support bug reports
« Reply #76 on: August 23, 2020, 05:14:43 pm »

Here's another crash for you. This happens on 10.12.6.

ROMless Boot -> Choose ProFile Hard Drive -> click OK
Hard Drive Size? -> Click Cancel -> crash

This sequence however does not cause a crash when using a Lisa ROM file.

 Text file attached below.
Logged

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3 support bug reports
« Reply #77 on: August 23, 2020, 07:09:52 pm »

Here's another crash for you. This happens on 10.12.6.

ROMless Boot -> Choose ProFile Hard Drive -> click OK
Hard Drive Size? -> Click Cancel -> crash

This sequence however does not cause a crash when using a Lisa ROM file.

 Text file attached below.

Great, thanks for finding this, thank you!
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #79 on: September 17, 2020, 08:12:00 am »

So been having fun implementing pty support for the serial ports. Some weird things:

0. Serial port A hangs LOS. I haven't been able to figure out exactly why, but regression testing shows this has been the case since at least LOS 1.0 beta. I've also found a bug in the fliflo (fifo+lifo library) that broke some serial access which I've fixed.

1. LisaTerm (or perhaps the OS itself) will chop off output after X characters of input, that is it will accept the first ~64 chars of input, and then discard the rest until it stops coming in and then accept more later. I haven't worked out the exact timing of these, so working on a bit of code, where if LOS is the active OS (I don't yet have a way to detect just LisaTerminal), it will slow the input down. I don't know how Xenix/UniPlus will behave, will revisit that once those OS's boot.

I tested this by running seq 100 200 - the output stops at "112" right before outputting the "2" character. Why 100-200 instead of 1 1000? Because this way, the output is exactly 5 bytes per line. The 3 number chars + cr+ new line. So this adds up to roughly 60 chars.

On another attempt I tried to output a string of text that was around 80 chars via echo and it stopped exactly at the 64th one. So that seems to be the size of the buffer. Changing the baud rate up doesn't affect this at all.

But wait! It gets worse!

2. ANSI color codes confuse it. Modern linux/macos  implementations insist on sending color, so setting TERM=vt100 is not enough. I can limit colors for things like ls and grep upto a point by setting environment variables before the execve bash, but not for everything.

As an example, ls -l itself will bold the output of some filenames right after the date/size, and LisaTerm discards the output immediately before the file name. Ditto for colorized grep.

3. Forget about using vi, it's horribly broken, the vt100 implementation in LisaTerm doesn't allow it to work properly. It can sort of work, but not quite. ed, or jed, haven't tried emacs, are your best bet.

4. I'm considering writing a small ANSI/xterm/vt100 escape sequence filter command line tool to remove color sequences and potentially any other things that break LisaTerminal by causing it to abort outputting text. It would have to do it's own fork/exec pty allocation. This way it can sit outside of LisaEm and be invoked by the user via preferences when pty is used.

I can build this into to LisaEm, but perhaps it might be more useful as a standalone unix cli filter tool.

I suppose this is analogous to ancient web browsers not understanding SSL, or modern HTML 1.x and requiring a filtering proxy in the form of a Raspberry Pi that connects to the outside world over wifi, and then presents TCP/IP traffic over SLIP/PPP for things like the MacPlus/SE or even MacWorks. :)

5. Using the default cooked output causes the pty to freeze, so the fix is to switch to raw before doing the execve, but then, the terminal is all messed up and I have to run stty sane to get echoing and other things to behave.

I'm adding back some of the options one by one of cooked/sane mode to the code to figure out which tcsetattr option is the culprit, but there's dozens of them.

I also seemed to have broken a couple of things in this effort:

1. BOOT ROM now throws an I/O error, so some of the z8530 behavior got messed up, and I'll need to fix that.

2. Mouse behavior in LOS, but not the BOOT ROM behaves as if everything is dragging, it's as if the mouse up event isn't being received even though it's sent and accepted by LOS, not sure what's going on there.

3. Still have XproFile/BLU/dc42 work to complete before RC4's release.


I think after I'm done with LisaEm 2.0, I'll work on a replacement LisaTerm program... one with XModem as well.




« Last Edit: September 17, 2020, 08:35:07 am by rayarachelian »
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

stepleton

  • Sr. Member
  • ****
  • Karma: +38/-0
  • Offline Offline
  • Posts: 103
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #80 on: September 17, 2020, 02:39:48 pm »

Thanks for the hard work as usual. I'm tempted to connect my own 2/10's serial port to my laptop and see what happens if I run getty. I may report back if I do...

Can you elaborate on "LOS 1.0 beta"? Do you mean a LisaEm beta, or do you have an unreleased LOS kicking around?  :)

I know that LisaTerminal wasn't available until Lisa Office System 1.2, so it's not surprising to hear that serial stuff is a bit strange in Office System <=1.0...
Logged

stepleton

  • Sr. Member
  • ****
  • Karma: +38/-0
  • Offline Offline
  • Posts: 103
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #81 on: September 17, 2020, 04:58:16 pm »

Things seem to work OK for me on real hardware. The only caveat is that you have to enable XOn/XOff software handshaking under "Computer Compatibility..." or else the computer can't even keep up with 2400 bps.

With that on, though, 19200 works all right. I've set $TERM to vt100 and `ls -l` will boldface certain files, but no usage issues. vi works fine as well, although it helps to resize the LisaTerminal window just a bit. See attached photo...
« Last Edit: September 17, 2020, 08:02:19 pm by stepleton »
Logged

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #82 on: September 18, 2020, 10:02:28 am »

Things seem to work OK for me on real hardware. The only caveat is that you have to enable XOn/XOff software handshaking under "Computer Compatibility..." or else the computer can't even keep up with 2400 bps.

Thanks for trying on real hardware, Tom.
Unfortunately, even with software handshaking on in LisaTerm, it still trims after 64 chars. I'm sending a lot quicker from the pty than real hardware ever could, so now it has to be slowed down to the point where LOS/LisaTerm doesn't discard the buffer, and I haven't yet found that exact threshhold.

I suppose the rationale for 64 bytes is that since the Lisa was so slow that it can't even do 2400bps as you've noticed, that 64 bytes were enough, and this is an issue caused by running LOS on too modern a system under emulation.

With that on, though, 19200 works all right. I've set $TERM to vt100 and `ls -l` will boldface certain files, but no usage issues. vi works fine as well, although it helps to resize the LisaTerminal window just a bit. See attached photo...

Oh I see, I'm guessing you weren't connected to a linux system in that photo or had already disabled color in vi itself.
It seems that in Linux, vt100's termcap is considered color vs BSD's termcap which correctly sets vt100 as mono. see this thread: https://unix.stackexchange.com/questions/58982/disable-colours-on-terminal-and-ssh#comment81353_58992, and the screenshot below, as well as about grep and ls not honoring even xterm-nocolor further in down this reply.

There's some details on disabling color in various CLI tools, here as well as a proposed new variable to disable color, which various tools might|not honor: https://no-color.org/

I've fixed the "stty sane" issue, now that I'm setting these termios after cfmakeraw. That fixed a lot of the issues, including the hanging on startup when cfmakeraw isn't invoked:

Code: [Select]
  new_term_settings.c_iflag |= ICRNL | IXON;
  new_term_settings.c_oflag |= OPOST;
  new_term_settings.c_lflag |= ECHO | ECHOCTL  | ECHOE | ECHOK | ECHOKE |ICANON | ISIG;
...
    setenv("TERM","vt100",1); // LisaTerm, Xenix, UniPlus aren't going to understand modern xterm-color256 here.
    setenv("NO_COLOR","nocolor",1);
    setenv("LS_COLORS","none",1); // color output breaks LisaTerm.
    setenv("GREP_OPTIONS","--color=never",1);
    setenv("LC_ALL","C",1);

I guess it depends on which vi, you're using. There's, vim, nvi, elvis, and ofc the original BSD vi written by Bill Joy (which is exceedingly rare now). Default on ubuntu is vim. Telling vim to not use color is a setting that has to be done via vimrc or command line before your launch it - So, I can't set it via a var, nor can I set aliases before doing a fork - at least I'm not aware of a way.
It's also likely that vim would work, but because it might be sending more than 64 chars on startup in a single burst, it's causing LisaTerm to discard the rest and leaving the terminal display in a bad state. I'll still have to fix that pacing issue before I'll know for sure.

In terms of disabling color, it's actually a big mess.
Setting TERM=xterm-nocolor doesn't work for everything either, for example, neither grep nor ls honor that if their default options were set to do color.
ls doesn't remove colors unless LS_COLORS is unset. and
Code: [Select]
alias grep='grep --color=auto' being the default setting for modern linux.

The bolding done by ls and grep inplace of color, when color is turned off doesn't seem to be an issue for LisaTerm. So at least that's good.

It seems the solution is to build a .bashrc/.bashprofile specific for use with LisaTerm with aliases for things like vim, grep, etc. and have the user use that with LisaEm.
Also, while GREP_OPTIONS apparently work to disable color, but grep now throws a warning saying it's deprecated  >:( , so I'll have to remove that one:
Code: [Select]
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ export GREP_OPTIONS="--color=never"
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ alias grep
alias grep='grep --color=auto'
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ unalias grep
ray@predator:~/code/lisa/lisaem-1.2.7/bin$ grep lisa pty.log                 
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
src/lisa/io_board/z8530-pty.c:init_child:126 port:-25024 slave_orig_term_settings: c_iflag: 00000500
Perhaps the thinking, if there was any, is that it's 2020, and you're unlikely to be using a monochrome terminal, and if you are these tools will rely on your terminal ignoring color codes rather than behaving badly...

I suppose I could implement the "authentic" thing and see what baud rate is being set and pace it to that limit, that might be a good option.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

blusnowkitty

  • Sr. Member
  • ****
  • Karma: +28/-0
  • Offline Offline
  • Posts: 75
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #83 on: September 18, 2020, 12:06:59 pm »

For what it's worth, I watched a video by curiousmarc not too long ago where they interfaced an antique Baudot TTY to a modern Linux PC with the help of an Arduino to do the vt100 to Baudot conversion, and also to act as a buffer so they wouldn't overwhelm the TTY. There was probably also stuff in there to strip modern-day colour and control codes too. Maybe that could be an option for LisaEm - buffer modern input and strip colour before it gets to the Lisa?
« Last Edit: September 18, 2020, 12:09:54 pm by blusnowkitty »
Logged
You haven't lived until you've heard the sound of a Sony 400k drive.

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #84 on: September 18, 2020, 02:23:10 pm »

For what it's worth, I watched a video by curiousmarc not too long ago where they interfaced an antique Baudot TTY to a modern Linux PC with the help of an Arduino to do the vt100 to Baudot conversion, and also to act as a buffer so they wouldn't overwhelm the TTY. There was probably also stuff in there to strip modern-day colour and control codes too. Maybe that could be an option for LisaEm - buffer modern input and strip colour before it gets to the Lisa?

That's exactly the plan. It might just be the modern 256/24 bit color xterm stuff that confuses LisaTerm, but right now the biggest issue is pacing. If color is still an issue after I slow things down and find an acceptable rate to avoid tripping that 64 char limit, I'll write a small filter program to strip out color codes as well. I might also build the color stripping into LisaEm itself as that'll likely be more efficient than having to allocate a second pty, and/or provide an external program to do that also - in that thread there seems to be interest in such a tool and it might be useful for other projects too.

Maybe I'll add a checkbox to the Serial Ports to honor guest bps rate, if that's checked it should slow down I/O to whatever LisaTerm sets, but if it's not it should only slow it down whenever LOS is running, and only to whatever the maximum is before it drops characters.

So more experimentation to do to figure out what works and what's possible.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

D.Finni

  • Sr. Member
  • ****
  • Karma: +15/-0
  • Offline Offline
  • Posts: 62
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #85 on: September 18, 2020, 02:40:23 pm »

I don't know if it's a coincidence, or if they referred to the same code, but the ROM serial drivers for classic Macintosh also default to a 64-byte input buffer. There's a device driver call that allows you to define your own buffer of arbitrary size.
Logged

stepleton

  • Sr. Member
  • ****
  • Karma: +38/-0
  • Offline Offline
  • Posts: 103
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #86 on: September 18, 2020, 03:53:35 pm »

Code: [Select]
tom@ostepletron:~$ uname -a
Linux ostepletron 4.15.0-115-generic #116-Ubuntu SMP Wed Aug 26 14:04:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
tom@ostepletron:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic
tom@ostepletron:~$ vi --version | head -n 1
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 18 2020 18:29:15)

Definitely connected to a Linux system, with TERM set to vt100 and no other special measures taken to disable colour in vim or elsewhere. Looks like I'm using the 3.0 version of the Office System for some reason; not sure why.

In unrelated news but talking of vintage vi, my investigations of the obscure Whitechapel MG-1 workstation led me to learn about its direct ancestor em, the "editor for mortals". It doesn't say so on that page, but apparently people didn't appreciate that the command to edit a file was so close to the command to delete the file.
« Last Edit: September 18, 2020, 03:59:39 pm by stepleton »
Logged

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #87 on: September 23, 2020, 08:53:25 am »

Definitely connected to a Linux system, with TERM set to vt100 and no other special measures taken to disable colour in vim or elsewhere. Looks like I'm using the 3.0 version of the Office System for some reason; not sure why.

Right you were sir, it looks like after (somewhat) fixing the buffering issues, colors don't cause issues. Tested the normal 16 color fore/background colors, 256 colors, and even 24 bit RGB colors, LisaTerm mostly ignores them properly. The only weird side effect was caused by this shade of green, which enabled blinking due to the ;5; inside it:

Code: [Select]
printf "\x1b[38;5;106m 256 green\n"

I used the values in this answer to test: https://stackoverflow.com/questions/4842424/list-of-ansi-color-escape-sequences/33206814#33206814

I also fixed the error 56 in the Boot ROM - this was caused by enabling the pty too early, which sent the bash prompt to the Boot ROM before it's test and it wasn't expecting any data on the port. I added a bit of code that split up the initialization in two passes. On power up it connects the serial ports to nothing, then about ~20 seconds (relative to the 5MHz CPU clock, so if you run at 10MHz, it's 10s, etc.) after power on it connects the real device.

However, now I ran into error 55, so even though there's nothing on serial port A, it fails the tiny test the Boot ROM does on port A. This is likely from my attempts to fix serial port A from locking up the OS/

It seems the LOS/LisaTerm 64 byte buffer can be increased by picking a higher baud rate such as 19.2kbps, however, there is still some limit and my attempts to limit the number of bytes didn't quite work out.

If I now run `seq 100 300` it gets as far as 2nd character of "202", so it's getting a lot further.

Enabling Xon/off handling sort of helped as well, but as I'm buffering internally before it gets to LisaTerm, it's not fast enough to tell bash to stop sending, so there's some more to do. It's likely vim should also work once the buffer cut off bug is fixed. I could watch the LisaTerm send Xon and then stop sending on my side rather than let Xon/off make it to the pty and bash instead.

The downside is that this requires Xon/Xoff to always be set, which is probably ok if the OS happens to be LOS as LisaTerm doesn't do hardware handshaking. (And would require another checkbox added to preferences to select it).
But it's probably better to get the timing just right.

It's possible that LOS is using the VIA timers or the actual clock instead of CPU cycles, I haven't explored that and have been limiting based on CPU clock cycles, so that's a possible route as well. Likely I'll try this next and use the wall clock rather than the CPU clock to rate limit the bytes.

The next remaining issue seems to be cursor keys don't work right. Control-A, Control-E bash editing works right, cursor left/right don't work at all. Cursor up/down send - and , respectively. These likely will turn out to be a keyboard translation issue and not a LisaTerm issue.
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'

rayarachelian

  • Administrator
  • Sr. Member
  • *****
  • Karma: +17/-0
  • Offline Offline
  • Posts: 333
  • "But what's puzzling you is the nature of my game"
    • LisaEm
Re: LisaEm 1.2.7-RC3a support bug reports
« Reply #88 on: October 18, 2020, 10:54:55 am »

Trying to boot Xenix on LisaEm 1.2.7-RC3a setup as a 2/10 w/10MB internal widget (profile really) results in it trying to write to block 16456 and then read from the same block. After this it displays "Xenix pfcmd bad state 0306" and hangs.

Not quite sure why yet, been tracing the accesses to the profile code. I've also taken a RAM dump and captured the CPU addresses where the profile is being accessed so should be able to find and disassemble the profile driver. So either I'll find where that error comes from, or I'll find the entry points into the driver state machine and be able to intercept them,

Code: [Select]
33846686:src/storage/profile.c:do_profile_write:394:ProFile write request block #16456 0x00004048 deinterleaved:16456 0x00004048
34126893:src/storage/profile.c:ProfileLoop:1025:step6: Reading block#16456,0x004048 - buffer: 00.00.00.00(00 )[00 40 48]:0a:04 00 00 00 00 00 00| 19:34:09.2 15462333758

Looks like it's timing out at some of the states, and so it drops out of the state machine. (This isn't a complete protocol analysis, it's only showing the state transitions, not the data transfered back and forth but shows where we drop out, so I can go and look at those state transition points and look at the disassembly there.)

Code: [Select]
31336384:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367045
31336402:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367045
31336415:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367073
31336433:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367073
31336446:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367097
31336478:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367135
31336526:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367187
31336545:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:1 && P->last_cmd:1 if non zero, should see state transition.| 19:33:59.4 15455367187
31336566:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000012| 19:33:59.4 15455367219
31336602:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:33:59.4 15455367265
31336638:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:33:59.4 15455367305
31336663:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:33:59.4 15455367331
31336681:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:33:59.4 15455367331
....
31690210:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1  - BSY is now 1| 19:34:00.7 15455866919
31690250:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1  - BSY is now 1| 19:34:00.7 15455866977
31690290:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1  - BSY is now 1| 19:34:00.7 15455867035
31690330:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1  - BSY is now 1| 19:34:00.7 15455867093

31690370:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:1  - BSY is now 1| 19:34:00.7 15455867151

looks like we've timed out here waiting for 55 and lost!
31690449:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455867267
31690523:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455867357
31690541:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455867357
31694581:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:00.7 15455877698

...
33825423:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:08.2 15461543969
33832481:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:0 && P->last_cmd:1 if non zero, should see state transition.| 19:34:08.2 15461563787
33832500:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:1 && P->last_cmd:1 if non zero, should see state transition.| 19:34:08.2 15461563787
33832516:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000016| 19:34:08.2 15461563815
33832536:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000016| 19:34:08.2 15461563815
33832588:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:34:08.2 15461563903
33832710:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:34:08.2 15461564105
33832739:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:34:08.2 15461564137
33832757:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=01, last_a_accs:0  - BSY is now 1| 19:34:08.2 15461564137
33832779:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1  - BSY is now 1| 19:34:08.2 15461564181
33832790:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1  - BSY is now 1| 19:34:08.2 15461564197
33832809:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1  - BSY is now 1| 19:34:08.2 15461564197
33832858:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564279
33833025:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564541
33833052:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564587
33833077:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564633
33833102:src/storage/profile.c:ProfileLoop:847:In state 4 - waiting for command| 19:34:08.2 15461564679

and we miss the command here, so we start over

34125776:src/storage/profile.c:ProfileLoop:718:In state 0 now - idle - CMDLine is:1 && P->last_cmd:1 if non zero, should see state transition.| 19:34:09.2 15462332018
34125798:src/storage/profile.c:ProfileLoop:786:In state 2 - wasting while waiting for 55, got 01, last_a_accs:0 before turning BSY to 0: left:0000000000000032| 19:34:09.2 15462332018
34126030:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1  - BSY is now 1| 19:34:09.2 15462332400
34126049:src/storage/profile.c:ProfileLoop:804:In state 2 - waiting for 55, last PA=55, last_a_accs:1  - BSY is now 1| 19:34:09.2 15462332400
« Last Edit: October 18, 2020, 07:29:17 pm by rayarachelian »
Logged
Fate whispers to the warrior, 'You can not withstand the storm.'  The warrior whispers back, 'I am the storm.'
Pages: 1 ... 4 5 [6]   Go Up