Jump to content
IGNORED

#FujiNet Testing and Bug Reporting Thread


Recommended Posts

NLOGIN crashes my system(s).

 

To reproduce:

  1. boot to SDX
  2. type D1:NDEV
  3. type D1:NLOGIN N1: username password

The result is a crash and an all white screen --- usually with some black artifacts on the left hand side.

If using the IDE+, the onboard SDX cart gets disabled.

 

To workaround:

  1. boot to SDX
  2. type D1:NDEV
  3. type D1:FCONFIG
  4. type D1:NLOGIN N1: username password

Odd I know. But running FCONFIG prior allows NLOGIN to work.

 

I have tested on 3 800xls and 1 130xe.

I have tested with stock hardware, SYSCHECK memory upgrade, Antonia memory upgrade, AVG memory upgrade.

I have tested with 3  different versions of fujinet hardware including the latest.

I have tested with several versions of SDX running from Uno Cart, AVG Cart, IDE+

I have tested at just about all SIO speeds

I have tested with old Fujinet firmware

 

Link to comment
Share on other sites

  • 10 months later...

Referencing this elsewhere thread as a bug report here...

 

I played around a bit and discovered that when FujiNet takes awhile to mount a disk, ALL mounted disks momentarily go offline -- and if you happen to be actively writing to a mounted disk at this time, then all remaining mounted disks go offline PERMANENTLY (until you reboot FujiNet and the Atari). And when it comes back up, none of your previously-mounted disks show up in the drive slot list. Example: I had CopyMate XE in D1, physical drive at D2, blank disk images in D3 and D4. I had copied a physical disk into D3. When it was complete, I flipped my physical disk over and started copying it to D4. While that was happening I ejected the D3 image (via the web interface), then mounted a new image into D3. FujiNet showed that delay while mounting D3 and immediately my Atari started making that "grumbling" noise and then threw up a write error -- just like it makes if you eject a physical disk in mid-write. Pressing START to try again brings up the same error. I tried re-mounting the images in D3 and D4. Both showed that delay, ultimately telling me it was successful and showing up in the FujiNet web interface, but CopyMate still didn't see it and continued to generate the error. Cold-booting my Atari did NOT boot from FujiNet, instead bringing me to Self-Test (w/OPTION). I rebooted FujiNet, then the Atari, and booted into FujiNet. All of my drive slots were empty except for CopyMate in D1. It "feels" like some kind of memory leak. When the FujiNet is rebooted I almost never have that "delay when mounting" issue, but the longer I swap virtual disks the more it crops up, and apparently if I do it too much the whole FujiNet needs to be rebooted.

 

TZJB suggested running FujiNet Flasher in monitor mode to capture the gory details so I did. The accompanying report follows this workflow:

 

Boot from CopyMate XE 3.7 mounted on virtual D1, hosted from my home server.

Physical drive on D2.

Using web interface, mount empty ATR images (hosted from my home server) on D3 and D4.

Copy first disk (Jumpman, in this instance) from D2 to D3.

Copy second disk (Paint, in this instance) from D2 to D4.

Eject both mounted disks.

 

In following this workflow, mounting Jumpman.atr to D3 took about 10 seconds but then reported "operation successful". Mounting Paint.atr to D4 was instant. Both D3 and D4 showed the appropriate ATR files in their respective drives. However, CopyMate did not see any disk in D3. At that point I ejected D3 and re-mounted Jumpman.atr (which was instant and successful), at which time CopyMate was able to see the disk.

 

This 10 second delay with the successful-not-successful issue happens fairly regularly, and the longer I use the FujiNet without rebooting the more frequent it gets until eventually it seems like it's impossible to mount any disk images. At that point I have to reboot both the FujiNet and the Atari. When that happens and FujiNet comes back online, the web interface often shows different media mounted than what the Atari screen interface shows.

 

Captured log from Flasher is here:

 

https://www.dropbox.com/s/t91mnm4p78j1ifd/2023-04-06-19-00.txt?dl=0

 

PS: Running firmware 0.5.64f05da8 2023-03-18 20:36:30.

Edited by SlagOMatic
  • Like 2
Link to comment
Share on other sites

@SlagOMatic Thanks for the detailed report, we are looking into it. Have you by chance tried with files on SD to see if it's tnfs related only?

 

I've also encountered another bug while testing. Mount 4 disks, boot dos, do a listing for each disk from dos works, press disk swap button then D1 and D4 are not readable anymore

  • Thanks 2
Link to comment
Share on other sites

On 4/7/2023 at 9:16 AM, mozzwald said:

@SlagOMatic Thanks for the detailed report, we are looking into it. Have you by chance tried with files on SD to see if it's tnfs related only?

 

I've also encountered another bug while testing. Mount 4 disks, boot dos, do a listing for each disk from dos works, press disk swap button then D1 and D4 are not readable anymore

Have not tried with SD but I will test and report back.

 

In the meantime, I've noticed that when this issue happens there are notifications on the TNFS server. Here's a copy-paste of the TNFS command window output:

 

Last login: Tue Apr  4 21:05:29 on ttys000
server@-Server ~ % sudo sh /Users/server/Desktop/Atari\ TNFS.sh
Password:
Starting tnfsd version 20.0813.1 using root directory "/Volumes/RAID5/Retro Gaming/ROMs & ISOs/Atari 8-bit"
192.168.2.18 s=41a7 c=17 q=41 | Invalid session ID
192.168.2.18 s=41a7 c=17 q=42 | Invalid session ID
192.168.2.18 s=41a7 c=17 q=43 | Invalid session ID
192.168.2.18 s=41a7 c=17 q=44 | Invalid session ID
192.168.2.18 s=41a7 c=17 q=45 | Invalid session ID
Allocating new session for 0x00
Allocated new session for 0x41a7
Allocating new session for 0x00
Allocated new session for 0x3af1
Allocating new session for 0x00
Allocated new session for 0xacd9
Allocating new session for 0x00
Allocated new session for 0xc2a
Allocating new session for 0x00
Allocated new session for 0xb782
Allocating new session for 0x00
Allocated new session for 0xdac8
Allocating new session for 0x00
Allocated new session for 0x8ed8
Allocating new session for 0x00
Allocated new session for 0x9fe
Found we already 8 sessions for this IP - returning oldest entry
192.168.2.18 s=00 c=00 q=00 | Freeing existing session
Allocating new session for 0x41a7
Allocated new session for 0x41a7
Found we already 8 sessions for this IP - returning oldest entry
192.168.2.18 s=00 c=00 q=00 | Freeing existing session
Allocating new session for 0x41a7
Allocated new session for 0x41a7
Found we already 8 sessions for this IP - returning oldest entry
192.168.2.18 s=00 c=00 q=00 | Freeing existing session
Allocating new session for 0x41a7
Allocated new session for 0x41a7
Found we already 8 sessions for this IP - returning oldest entry
192.168.2.18 s=00 c=00 q=00 | Freeing existing session
Allocating new session for 0x41a7
Allocated new session for 0x41a7

 

(For reference, 2.18 is my FujiNet.) There seems to be a correlation here. Whenever there's an "Allocating new session..." message by itself there's a delay when mounting an ATR file but the mount is successful. But when there's a "Found we already 8 sessions..." message preceding the "Allocating new session..." message, there's a delay when mounting an ATR file but the mount IS NOT successful.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

@SlagOMatic Here is a new firmware that I would like you to test when you have time. This is built with a newer ESP-IDF (v5.0.1) and also has a bug fix related to webui disk mounting. Previously, when a disk was mounted from the webui it only changed the file pointer but did not actually mount the disk. This build fixes that issue and I'm curious if it fixes the issues you are having. Thanks!

 

fujinet-ATARI-0.5.1d0a0f52-BETA.zip

  • Like 2
Link to comment
Share on other sites

I fixed another bug related to TNFS. When a TNFS Timeout would occur, the packet sequence number was being increased when it should remain the same since it was not successfully transmitted. I've fixed this in the attached firmware file. @SlagOMatic or anyone else who is having TNFS issues, please test this build and report. Thanks

 

fujinet-ATARI-0.5.1b7ccf31-BETA.zip

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

On 4/26/2023 at 1:37 PM, mozzwald said:

I fixed another bug related to TNFS. When a TNFS Timeout would occur, the packet sequence number was being increased when it should remain the same since it was not successfully transmitted. I've fixed this in the attached firmware file. @SlagOMatic or anyone else who is having TNFS issues, please test this build and report. Thanks

 

fujinet-ATARI-0.5.1b7ccf31-BETA.zip 1.81 MB · 0 downloads

I'd like to test this out.  But can someone tell me how to get this installed?  I have the firmware flasher utility... and I see an option for Custom Firmware File.  Do I just select this .ZIP file?

 

Link to comment
Share on other sites

7 minutes ago, chad5200 said:

I'd like to test this out.  But can someone tell me how to get this installed?  I have the firmware flasher utility... and I see an option for Custom Firmware File.  Do I just select this .ZIP file?

 

Correct, just select the ZIP file and hit the Flash FujiNet Firmware button

Link to comment
Share on other sites

On 4/26/2023 at 1:37 PM, mozzwald said:

I fixed another bug related to TNFS. When a TNFS Timeout would occur, the packet sequence number was being increased when it should remain the same since it was not successfully transmitted. I've fixed this in the attached firmware file. @SlagOMatic or anyone else who is having TNFS issues, please test this build and report. Thanks

 

fujinet-ATARI-0.5.1b7ccf31-BETA.zip 1.81 MB · 1 download

This update has absolutely fixed my issue which I detailed in this thread here:

 

As you can see, my guess as to the issue was described as:  'I am really thinking there are occasions where the "TNFS OUT OF ORDER SEQUENCE" error occurs but the FujiNet does not actually attempt to correct the packet sequence request because the log isn't even showing the follow up "tnfs_lseek" message.  Every time mine fails, it corresponds to that situation.  However, every time that a "TNFS OUT OF ORDER SEQUENCE" event occurs and it is followed up by a "tnfs_lseek success" it succeeds.'

 

Before this fix, it was easy for me to replicate the issue (as described in my thread) but now I have tried replicating it a couple hundred times and every time it is a success.

 

I am very happy this was addressed! I think this is a HUGE fix and I'll bet some people don't realize they were experiencing it... and if they did, they just rebooted and tried again and it worked.  But in my instance, I was trying to set up a Carina BBS for my friend which involves often loading files and it was very important that each file loaded successfully on demand.

 

THANK YOU!

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

2 minutes ago, chad5200 said:

As you can see, my guess as to the issue was described as:  'I am really thinking there are occasions where the "TNFS OUT OF ORDER SEQUENCE" error occurs but the FujiNet does not actually attempt to correct the packet sequence request because the log isn't even showing the follow up "tnfs_lseek" message.  Every time mine fails, it corresponds to that situation.  However, every time that a "TNFS OUT OF ORDER SEQUENCE" event occurs and it is followed up by a "tnfs_lseek success" it succeeds.'

 

Before this fix, it was easy for me to replicate the issue (as described in my thread) but now I have tried replicating it a couple hundred times and every time it is a success.

 

I am very happy this was addressed! I think this is a HUGE fix and I'll bet some people don't realize they were experiencing it... and if they did, they just rebooted and tried again and it worked.  But in my instance, I was trying to set up a Carina BBS for my friend which involves often loading files and it was very important that each file loaded successfully on demand.

 

THANK YOU!

Thanks for testing and confirming it works. This has been a long standing issue and I'm glad it's fixed. This will be pushed to the flasher after some other things are fixed/changed and more testing is done. I'm working on having github build the firmware automatically and will be starting that with a v1.0 build. No more git hash for version numbers which should make it easier to see if you need an upgrade.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Thank you chad5200 and mozzwald. It's a wonderful day for FujiNet owners the world over. Speaking if which, I will be owning again now that the more major usage issues are being addressed !!

I am awaiting another one. The world of 'have a free from me FujiNet' may now be at an end, I just may be keeping this one. 😮

Edited by _The Doctor__
  • Like 1
Link to comment
Share on other sites

error 404 for last update mozzwald posted

Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip
HTTP error: 404 Client Error: Not Found for url: https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip

@mozzwald

Edited by _The Doctor__
Link to comment
Share on other sites

@mozzwald

Retrieving firmware
Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip
sha256 88980e61bddfc425f8b38fcf27306e8aaa4fa2c7f292a6363ab300604fbbf782 OK
Using 'COM3' as serial port.
Using '921600' as baud rate.
Starting firmware upgrade...
File 1: bootloader.bin, Offset: 0x1000
File 2: partitions.bin, Offset: 0x8000
File 3: firmware.bin, Offset: 0x10000
File 4: spiffs.bin, Offset: 0x910000
FujiNet Version: v1.0-pre4
Version Date: 2023-05-01 00:40:20
Git Commit: b9957c2e
Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5)
 

already set up new profile. it's the same on windows 10 and 8.1

 

Edited by _The Doctor__
Link to comment
Share on other sites

28 minutes ago, _The Doctor__ said:

@mozzwald

Retrieving firmware
Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip
sha256 88980e61bddfc425f8b38fcf27306e8aaa4fa2c7f292a6363ab300604fbbf782 OK
Using 'COM3' as serial port.
Using '921600' as baud rate.
Starting firmware upgrade...
File 1: bootloader.bin, Offset: 0x1000
File 2: partitions.bin, Offset: 0x8000
File 3: firmware.bin, Offset: 0x10000
File 4: spiffs.bin, Offset: 0x910000
FujiNet Version: v1.0-pre4
Version Date: 2023-05-01 00:40:20
Git Commit: b9957c2e
Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5)
 

already set up new profile. it's the same on windows 10 and 8.1

 

Running it as administrator?

 

Something else on the system taking control of the serial port? Maybe reboot and run the flasher first thing

Edited by mozzwald
added
Link to comment
Share on other sites

26 minutes ago, _The Doctor__ said:

@mozzwald

Retrieving firmware
Downloading https://fujinet.online/firmware/releases_atari/fujinet-ATARI-v1.0-pre4.zip
sha256 88980e61bddfc425f8b38fcf27306e8aaa4fa2c7f292a6363ab300604fbbf782 OK
Using 'COM3' as serial port.
Using '921600' as baud rate.
<snip>
Unexpected error: could not open port 'COM3': PermissionError(13, 'Access is denied.', None, 5)
 

already set up new profile. it's the same on windows 10 and 8.1

 

@_The Doctor__ - Have you updated your Fujinet-Flasher? A few months ago, @mozzwald created a new flasher program that defaults to a BPS rate of 460800. I don't know what other changes are in the updated flasher program. I was able to upload the new firmware, but I don't run Windows so I'll defer to another Windows user to see if the problem occurs with other Windows users.

 

Bob C

Link to comment
Share on other sites

FujiNet version
0.5.aac1c104 2023-05-01 00:40:20
is the reported version via web interface now
starting to wonder if the usb ports are not of the best quality or not always nicely soldered to the PCB
it's up and running on the Atari, I hope it passed all the sanity checks if there are any.
will be hitting the testing files on remote tnfs folders.
Edited by _The Doctor__
Link to comment
Share on other sites

means nothing because it works fine with everything else.... I got it to program if the web interface is correct in saying the update is from 5 1 2023 so 6 days ago

0.5.aac1c104 2023-05-01 00:40:20    is what the web config is showing.

The flasher is quirky. I simply stop trying all kinds of different cords. stuck with one and kept hitting the flash button on the fujinet flasher repeatedly until it finally went through. Everything else works like it should in terms of the log being sent etc so clearly the usb port works fine.

 

Beings 3 totally different Laptops from different manufacturers running different Windows versions with fresh user profiles all had issues, that leave use with a FujiNet device problem or the Flasher needing some work / probably both :(

 

The device seems more reliable on some network connections but overall something else is different as well. I may have to bump the SIO divisor down one more notch for use with SDX... it was fine before the update but now it chokes sometimes.

 

Over all I was able to use the device for a longer period of time tonight manipulating disks in and out of slots... will look at it some more tomorrow

 

Does the Flasher software check what was sent to the device and verify the data against what it has sent in some way or does the device just check what was sent to it's local memory versus what was flashed?

 

Edited by _The Doctor__
Link to comment
Share on other sites

49 minutes ago, MichaG said:

I've flashed the new version, too. Everything seems to work fine, but my MyIP and the build in Config say it is version 0.5.aac1c104, not 1.0-pre4.

This is something that needs changed in the auto build. Will be fixed for the next release

 

  • Like 2
Link to comment
Share on other sites

@mozzwald, @tschak909,

Disk slots work... but...

 

issue 1...

now if you set all the host slots... with slot 1 as SD card and not acting as a remote host...

and then go into and leave remote hosts one at a time...

after the 5th one you go into and look at then leave...

whatever 2 slots that are left WILL NOT work, it will instead take you to config... if you just leave config all is fine... IF YOU RECONNECT it will blank everything and you will have to manually fix it all.

 

issue 2

when you set a disk from a server into a drive slot, it no longer returns you to where you were... you have to traverse all the way there again...

perhaps we chose some earlier version to try the fix on and published it as the latest greatest with the fix applied?

 

issue 3 is a group

 

terminal emulation...

AT?

the screen has a number of items that don't work or are working but labelled incorrectly

ATPHONEBOOKLIST... should be ATPBLIST

ATPHONEBOOKCLR... should be ATPBCLEAR

AT[UN]SNIFF... should be AT+SNIFF and AT-SNIFF

ATA should be in the list   etc etc...

ATTERMVT52,ATTERMVT100,ATTERMDUMB,ATTERMANSI do nothing and should not be there... They are handled under AT+TERM=  just fine

 

The help listing could use a tweak with the atwificonnect stuck right at the blank spot just below, like

 

 

====================================

ATWIFICONNECT<ssid>,<key>         Set up WIFI

 

then the rest of the list

ATA                     |Answer Ring/ANSWER Mode

ATO                     |Answer Ring/Originate Mode

ATS0=<0|1>          |AutoAnswer Connect on/off

and so on...

information from setting ATPORT should not be padded with a line before or after it and should simply say

Listening for connections on port

 

ATPB without anything following it should not clear the phonebook!!!

after setting a PB slot sometimes you have to AT? before ATPBLIST to see what you just set up? weird

Edited by _The Doctor__
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...