Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: The Os 3.1.4 Thread  (Read 157327 times)

0 Members and 1 Guest are viewing this topic.

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #555 on: July 28, 2019, 06:01:18 PM »
I was trying to reproduce as well and haven't seen it for a 2nd time.    I tried both ways of saying "yes" and "no" but haven't reproduced.  Unfortunately, I don't have any more details of what led up to it except I'm attaching some photos of when it happened the first time.


Sorry, I cannot reproduce this here. I need better instructions for reproduction. If the RAM disk becomes full, you get a requester whether the incomplete object should be removed. If I say "no", the RAM is still full, but I see a small amount of RAM left. If I say "yes", the RAM is released.
 

Offline utri007

Re: The Os 3.1.4 Thread
« Reply #556 on: July 28, 2019, 11:00:46 PM »
Do I remember right that CDTV will be supported in future?  Stephen Leary aka Terrible fire has rebuild cdtv.device, so that he could support CDTV with his accelerators.

Because of copyrights everyone needs to build it himself.

Quote
The build environment requires.

CDTV.H from the original CDTV Developer CD. Place it in the build folder.
Python 2.7 - to generate the cdtv.i file from the CDTV.H (can be done on linux etc)
VASM - My assembler of choice.
Amiga NDK 3.9
Gnu Make
MD5SUM (to verify the file checksum only)
OR...

You can use docker. Add the CDTV.H file then..

docker build . -t terriblefire/vbcc

Then to build the sources

docker run --rm --volume "$PWD":/usr/src/compile --workdir /usr/src/compile -i -t terriblefire/vbcc make

He has a message for a Amiga os devs

Quote
I am happy for the original copyright holders and those with an AmigaOS development license to compile and include this code in a binary ROM that they distribute. Actually please do!!! I want this to happen. Make improvements to the CDTV Extended ROM while you are at it!!!





ACube Sam 440ep Flex 800mhz, 1gb ram and 240gb hd and OS4.1FE
A1200 Micronic tower, OS3.9, Apollo 060 66mhz, xPert Merlin, Delfina Lite and Micronic Scandy, 500Gb hd, 66mb ram, DVD-burner and WLAN.
A1200 desktop, OS3.9, Blizzard 060 66mhz, 66mb ram, Ide Fix Express with 160Gb HD and WLAN
A500 OS2.1, GVP+HD8 with 4mb ram, 1mb chip ram and 4gb HD
Commodore CDTV KS3.1, 1mb chip, 4mb fast ram and IDE HD
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #557 on: July 28, 2019, 11:24:29 PM »
Is this a "superfloppy" with no partition information on it, or a partitioned disk? Thumbdrives that are pre-formatted for the PC are the latter, thus use the instructions in the FAQ. Also note the name of the drive, it should end with a 'C' or a '0' to indicate the partition number, and the right DOS type as indicated in the FAQ.

Let me check this some more...
[Edit]  Got it to work using DosType 0x4D534800 for a partition table drive -- user mistake :)

Quote
No, the FAQ does certainly not mention a mount flag like Fat32. Fat32 support is built into CrossDos, this is what it says. "DirectSCSI" *is* a mount flag, but you only need that for broken devices that do not support reads beyond the 4GB barrier. I am not aware that the usbscsi.device is broken, but I could be wrong. So, nothing of the above. Mount flags are just used as indicated in the FAQ:

When I look at: http://us4.aminet.net/aminet/docs/help/AmigaOS_3.1.4-FAQ.txt -- Line 652

'Note: CrossDOS supports long file names, the mount flags "EnableNSD", "DirectSCSI", Fat32, Fat16, Fat12 and Fat8.'

So "Fat32, Fat16, Fat12 and Fat8" text after the "mount flag" wording is what confused me but thanks for the clarification.
« Last Edit: July 29, 2019, 03:03:36 AM by my_pc_is_amiga »
 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #558 on: July 29, 2019, 04:32:16 AM »
I loaded up the 3.1.4.1 env. but using 3.9 Multiview 45.9.  No issues using the BMP datatype with the older multiview 45.9.  It seems like newer multiview 45.22 is having some issue.   I am keeping 3.1.4 picture.datatype 46.13 loaded.

I copied the picture.datatype from OS 3.9 and OS3.9bb2 versions to my 3.1.4 installation and still see same issue in the 3.1.4 environment.  I also tried bmpdt.lha on aminet and see same issue. Adpro that doesn’t use data types is okay with same BMP picture. 

 

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #559 on: August 03, 2019, 12:17:46 AM »
I have deneb usb card using pio device driver on a 68040 a4000t. With 3.1.4.1 I have experienced workbench GUI freezing when I remove a usb thumb drive. I have a shell window open and that was still working okay . With info I see usb drive removed from device list.  Later I loaded up 3.9 and haven’t yet encountered this issue.

With 3.1.4.1 I tried putting in pc dos disk in floppy to see if same issue - this is working okay. Then  I tried Jaz disk with mount file for CrossDos- this worked also

I seemed to have hit an issue with HDToolBox. With a jaz disk in the drive, HDToolBox gets stuck when scanning scsi.device at the unit number of the jaz disk. Also when booting  I’ve experienced the scsi bus did not find all disks and only the jaz disk showed up in the early boot menu
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #560 on: August 03, 2019, 03:55:40 PM »
I loaded up the 3.1.4.1 env. but using 3.9 Multiview 45.9.  No issues using the BMP datatype with the older multiview 45.9.  It seems like newer multiview 45.22 is having some issue.   I am keeping 3.1.4 picture.datatype 46.13 loaded.
That looks more like an issue with the datatypes you are using. The datatypes that come with the Os have been tested and work fine.

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #561 on: August 03, 2019, 04:02:52 PM »
I have deneb usb card using pio device driver on a 68040 a4000t. With 3.1.4.1 I have experienced workbench GUI freezing when I remove a usb thumb drive.
Well,  so there is an issue with the USB stack, or the deneb device driver. Device mounting and loading did not change from 3.1 to 3.1.4 at all. Aminet provides a tool to detect deadlock situations and provide debug information in such a case, but this requires a serial terminal, connected via a null-modem connector at 96008N1. It could also be a hardware lockup, in which case there is nothing that can be done by software. The tool you are looking for is "Locksmith", see Aminet. It installs a keyboard interrupt handler that prints details about the lock-up over the serial port.

I seemed to have hit an issue with HDToolBox. With a jaz disk in the drive, HDToolBox gets stuck when scanning scsi.device at the unit number of the jaz disk. Also when booting  I’ve experienced the scsi bus did not find all disks and only the jaz disk showed up in the early boot menu
There is no single scsi.device. You mean the SCSI scsi.device of an A3000 or A4000T? The JAZ comes in various combinations, SCSI, some IDE, some parallel. If scanning the SCSI bus locks up then this is because there is an electrical problem at the SCSI bus, typically the result of bad termination or bad cabling. HDToolbox uses regular SCSI Inquiry commands to find out more about the device. However, if you want to learn more about the problem, please download SCSISnoop from aminet, and install Sashimi, and run SCSISnoop on the device and unit of the JAZ drive. Then capture the output of SCSISnoop over Sashimi and provide it here.

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #562 on: August 05, 2019, 05:45:19 AM »
Thanks Thomas for the debug tools.   The Jaz drive is a real SCSI device and is using the 2nd.scsi.device on the A4000T at unit 1.  I'm attaching the SCSISnoop for when 3.1.4.1 HDToolbox is launched vs. the 3.9 version (both being used in the 3.1.4.1 env.).   I also noticed when I use the SCSIQuery, it also is does the  defect check and it is there that Jaz drive hangs.   The 3.9 HDToolbox doesn't look like it does that step.


There is no single scsi.device. You mean the SCSI scsi.device of an A3000 or A4000T? The JAZ comes in various combinations, SCSI, some IDE, some parallel. If scanning the SCSI bus locks up then this is because there is an electrical problem at the SCSI bus, typically the result of bad termination or bad cabling. HDToolbox uses regular SCSI Inquiry commands to find out more about the device. However, if you want to learn more about the problem, please download SCSISnoop from aminet, and install Sashimi, and run SCSISnoop on the device and unit of the JAZ drive. Then capture the output of SCSISnoop over Sashimi and provide it here.
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #563 on: August 06, 2019, 07:04:28 AM »
Thanks Thomas for the debug tools.   The Jaz drive is a real SCSI device and is using the 2nd.scsi.device on the A4000T at unit 1.  I'm attaching the SCSISnoop for when 3.1.4.1 HDToolbox is launched vs. the 3.9 version (both being used in the 3.1.4.1 env.).   I also noticed when I use the SCSIQuery, it also is does the  defect check and it is there that Jaz drive hangs.   The 3.9 HDToolbox doesn't look like it does that step.
Thanks, I seem to remember this when creating the IOTools. Collecting the defect data from a JAZ drive may take a while, so it probably does not hang, but is just busy. Instead of the size of the defect list, the IO drives had a custom SCSI command to read out the lifetime of the medium, but that helps little if you need the precise list of defect sectors. So just give it some time to process the results. The time should be rather measured in minutes but seconds, but the command will succeed after quite a while.

This said, all the defect management by HDToolBox is pretty much nonsense for even remotely modern drives - they do that all themselves. In principle, HDToolBox can collect such defect lists (which it does) and store it in the RDB of the disk (which it does) where it could be used by the device running the system, to work around such defects. This made some sense in the time of RLL and MFM disks which had no defect management in their firmware (which firmware?), but in how far the scsi.device implementation of this is working I do not know. For (real) scsi based disks (and anything more modern), this is just bogus as the drive manages defects itself.

One way or another, HDToolbox is a dinasour, and this defect management should really go as it is non-sensical. But then again, I would prefer not to waste any more time in this dinasour, and let it get extinct for good. The hdwrench library of 3.9 is in better shape and omits this step (for reasons), but its unfortunately not available for 3.1.4 and successors.
 
The following users thanked this post: my_pc_is_amiga

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #564 on: August 07, 2019, 06:35:45 AM »
Thanks Thomas for the details.   Yes, HDToolbox is working fine after sometime (I needed to have a little more patience...).   I didn't really time it but it does take a awhile to show up.   

Upon booting, I still see issue where only the JAZ disk shows up in the early boot menu and none of my bootable hard disks shows up.  The JAZ disk shows up as MSH0 unbootable and no other hard disk in early boot (even though I have a scsi ID 3 and 6 hooked up).  And so in this scenario I get to a "insert floppy" screen from the ROM.  Without a disk in the JAZ it is okay and 3 and 6 comes up just fine and everything boots.

In regards to the usb stack and mounting devices, I tried LockSmith and then got into the situation where Workbench GUI is freezing while I remove a usb device.  But I could not get locksmith to send anything on serial port on the deadlock.   I did a check with Lockout and Locksmith is working with that test scenario.  So maybe something else is causing a hang besides semaphores?
 

guest11527

  • Guest
Re: The Os 3.1.4 Thread
« Reply #565 on: August 07, 2019, 10:06:01 AM »
Upon booting, I still see issue where only the JAZ disk shows up in the early boot menu and none of my bootable hard disks shows up.  The JAZ disk shows up as MSH0 unbootable and no other hard disk in early boot (even though I have a scsi ID 3 and 6 hooked up).  And so in this scenario I get to a "insert floppy" screen from the ROM.  Without a disk in the JAZ it is okay and 3 and 6 comes up just fine and everything boots.
Did you install an RDB on it and made it bootable with the HDToolBox? Which hostadapter is the JAZ connected to? It is mostly a matter of the hostadapter to ensure the creation of the mount entries - which is what you see in the boot menu. There is also a "last drive" flag in the RDB which indicates that the corresponding host adapter should not scan for any other drives behind the selected SCSI ID, thus disabling any drives with an ID higher than the drive the RDB was written to.

In regards to the usb stack and mounting devices, I tried LockSmith and then got into the situation where Workbench GUI is freezing while I remove a usb device.  But I could not get locksmith to send anything on serial port on the deadlock.   I did a check with Lockout and Locksmith is working with that test scenario.  So maybe something else is causing a hang besides semaphores?
Then that's not semaphore related, but either the system is blocked with interrupts disabled (i.e. within a Disable()), or it is some kind of hardware lockup. I afraid there is nothing I can really do then.
 
The following users thanked this post: my_pc_is_amiga

Offline my_pc_is_amiga

Re: The Os 3.1.4 Thread
« Reply #566 on: August 12, 2019, 04:28:29 AM »
Did you install an RDB on it and made it bootable with the HDToolBox? Which hostadapter is the JAZ connected to? It is mostly a matter of the hostadapter to ensure the creation of the mount entries - which is what you see in the boot menu. There is also a "last drive" flag in the RDB which indicates that the corresponding host adapter should not scan for any other drives behind the selected SCSI ID, thus disabling any drives with an ID higher than the drive the RDB was written to.

I made this drive sometime ago and so can't remember exactly but it does look like it has a RDB on it and is showing up as not bootable in early startup menu.  After loading it up in HDToolbox, there was a message about some changes  were needed for the drive and so I did a save and now during boot it no longer stops at unit=1.   So there must have been some "last drive" flag set. 

Quote
Then that's not semaphore related, but either the system is blocked with interrupts disabled (i.e. within a Disable()), or it is some kind of hardware lockup. I afraid there is nothing I can really do then.

I did a lot more testing on this now and finally figured out that having the "Unmount partitions after removal" option enabled in the "LUN Defaults of the massstorage.class of the usb stack was causing issues.  I tried it with both the Deneb and a RapidRoad USB cards and both were doing the hang when that option was set.  Without this, it no longer hangs.  As a matter of fact, I actually started to see the issue in 3.9 as well when the option set.     


In regards, to 3.1.4 multiview (v45.22) and the warp BMP datatype, I was trying to see if I could do some captures with MuForce and so attaching some of the dumps from the serial port.   What doesn't make sense is that this log shows input.device having issue...don't really understand that.   With the 3.9 Multiview (v45.9) program in 3.1.4 env. I don't see graphic corruption issue -- when i did this comparison with v45.22 and v45.9, everything is exactly the same except for the multiview version.


And for the RAM issue that I had, I haven't been able to reproduce exact same issue.  However, I have experienced 800 0004 GURU while deleting the files from the RAM disk.  I'm attaching a MuForce output for this crash.
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #567 on: August 12, 2019, 05:51:12 AM »
Which input.device are you using? Poseidon comes with input.device backported from MorphOS (v50) to fix various issues with USB hidd and v40 input.device (multi-kbd/mouse support and more), so maybe you are using that?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline F1Lupo

Re: The Os 3.1.4 Thread
« Reply #568 on: August 12, 2019, 06:40:48 AM »
anyone else notice a slight slow down with the new FFS update? I'm now getting 1,310,720 bytes/sec but was getting 1,638,400 with previous version
____________________________________________________________________
c64-dual sids, A1000, A1200-060@50, A4000-CSMKIII
Indivision AGA & Catweasel MK4+= Amazing
! My Master Miggies-Amiga 1000 & AmigaOne X1000 !
--- www.mancave-ramblings.blogspot.ca ---
  -AspireOS.com & Amikit- Amiga for your netbook-
***X1000- I BELIEVE *** :angel:
 

Offline kolla

Re: The Os 3.1.4 Thread
« Reply #569 on: August 12, 2019, 09:09:56 AM »
Quote
was getting 1,638,400 with previous version

Really? That number looks way too, uhm... casual, to be real :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS