English Amiga Board


Go Back   English Amiga Board > Support > support.Other

 
 
Thread Tools
Old 06 March 2019, 08:39   #41
kolla
Banned
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,899
Every customer is a beta tester, that much is obvious.
kolla is offline  
Old 06 March 2019, 09:03   #42
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Would you mind to read what I have written? Once again, this is *NOT* a missed beta test. It is exactly the result of the beta test that made this delay necessary.
Thomas Richter is offline  
Old 06 March 2019, 13:20   #43
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by Thomas Richter View Post
So, in short: There is no bug here. This is intentional, and a result of an IDE bus scan that is necessary for some hardware, or some hardware combinations.
How come a full scan is triggered at SetPatch time, isn't a full scan already done during scsi.device init time?
patrik is offline  
Old 06 March 2019, 14:56   #44
kolla
Banned
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,899
Quote:
Originally Posted by Thomas Richter View Post
It is exactly the result of the beta test that made this delay necessary.
I was speaking in general terms. If you count every OS 3.1.4 user as a beta tester, you probably get hundres of them. What's solved in "beta test" or not is kept secret by the clique of knights who say "woohoo!". (Would be interesting to see how many valid bug reports origin from official beta testers vs how many valid bug reports origin from outside the official beta testers.)

Gulliver writes that...
Quote:
SetPatch 45.15 in AmigaOS 3.1.4 has a much bigger
patch database
This gives a hint that SetPatch v45 patches more than just the OS 3.1.4 kickstart (which should not need much patching), so what OS releases does the OS 3.1.4 SetPatch officially support? Any v39+ kickstart?
kolla is offline  
Old 08 March 2019, 13:21   #45
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 3,309
Quote:
Originally Posted by Thomas Richter View Post
Looks like another rant from someone without background. Just for you: a) we do not have hundreds of beta-testers.
What do you call the hundreds of members on EAB who would have been more than willing to test the software before it was released?

Quote:
Originally Posted by Thomas Richter
b) the delay is not a bug. It is an IDE bus scan. The IDE bus scan is necessary as some IDE devices do not release a particular signal on the IDE bus before master *AND* slave are scanned. Missing the full scan would result in the drive LED being non-working. The times required for an IDE bus scan are coming from the IDE specs.

So, in short: There is no bug here. This is intentional, and a result of an IDE bus scan that is necessary for some hardware, or some hardware combinations.
No worries. Thanks for the explanation

Quote:
Originally Posted by Thomas Richter
Yes, we *DO* test software, and the IDE bus scan you see here is exactly the result of the beta-test, and some reading of the IDE specs.
Testing an OS involves having a large team of beta testers reporting bugs until it is considered stable enough for release..

Last edited by Hewitson; 08 March 2019 at 13:26.
Hewitson is offline  
Old 08 March 2019, 13:44   #46
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,184
I see you've removed your massive exaggeration about the Shell not working. Good stuff.

Anyway, on the other hand, throwing betatesters at a piece of software doesn't mean you'll find all the bugs, especially if the vast majority aren't experienced betatesters. you just have to look at the serious bugs in recent Windows updates to see that using large betatesting teams doesn't result in bug-free software.
Daedalus is offline  
Old 08 March 2019, 14:03   #47
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 3,309
Quote:
Originally Posted by Daedalus View Post
I see you've removed your massive exaggeration about the Shell not working. Good stuff.
Yes, I thought it was a bit of an exaggeration myself.

Quote:
Originally Posted by Daedalus
Anyway, on the other hand, throwing betatesters at a piece of software doesn't mean you'll find all the bugs, especially if the vast majority aren't experienced betatesters. you just have to look at the serious bugs in recent Windows updates to see that using large betatesting teams doesn't result in bug-free software.
No, it doesn't mean you'll find ALL the bugs. But the bug in the shell certainly would have been discovered.

As for Windows, I'm not convinced that Microsoft tests it at all. Remember how often 95 and 98 crashed? They were no where near in suitable condition for release. Newer versions aren't much better.
Hewitson is offline  
Old 08 March 2019, 15:42   #48
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Quote:
Originally Posted by kolla View Post
I was speaking in general terms. If you count every OS 3.1.4 user as a beta tester, you probably get hundres of them.
I don't regard users as beta testers. I never did. Happy now? We missed bugs. Big surprise with the small crew of people testing. You missed some, too. Even bigger surprise?

Quote:
Originally Posted by kolla View Post
This gives a hint that SetPatch v45 patches more than just the OS 3.1.4 kickstart (which should not need much patching), so what OS releases does the OS 3.1.4 SetPatch officially support? Any v39+ kickstart?
The patch database of SetPatch should cover pretty much everything that piled up since v37 if I recall correctly. So you can certainly run this version of SetPatch on top of a 3.0 system, and get the same patches the 3.0 SetPatch applied. The number of patches on a 3.1.4. system is minimal. I believe there is one bug in dos.library addressed I didn't want to fix in the sources, there is one workaround for WaitIO() that is not a bug in exec, but in programs using exec, so fixing exec is not exactly the right cure, there is the CPU-library support, and there is this scsi.device "Inquiry" scan that ensures that for some CF-cards, the drive LED works as expected. And there are some legacy compatibility patches like enabling the AGA modes or setting the memory speed on some systems.

3.1.4.1 will include some additional patches, though not really that much. I believe there are about three or four additional patches.
Thomas Richter is offline  
Old 08 March 2019, 21:03   #49
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
@Thomas:

How come a scan is triggered at SetPatch time, isn't a full master + slave scan already done during scsi.device init time?
patrik is offline  
Old 09 March 2019, 04:39   #50
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 3,309
Quote:
Originally Posted by Thomas Richter View Post
I don't regard users as beta testers. I never did. Happy now? We missed bugs. Big surprise with the small crew of people testing.
You had access to a huge crew of people who would test it. You chose not to take advantage of that.

Quote:
Originally Posted by Thomas Richter
You missed some, too. Even bigger surprise?
Considering I don't even have 3.1.4, no, it's not much of a surprise at all really.

I may start running it if it pops up on some dodgy Russian torrent site but I certainly won't be paying for it.
Hewitson is offline  
Old 09 March 2019, 09:17   #51
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Quote:
Originally Posted by Hewitson View Post
You had access to a huge crew of people who would test it. You chose not to take advantage of that.
Are you nuts? Do you seriously believe I kept udpates private and smuggled them into the distribution?


SetPatch was delivered as part of the regular beta test, for several months, along with all other updates, along with the Shell. So there was no "choice not to test".


So, seriously, what is your problem? We do not have a "huge crew", and certainly all updates are available to all beta testers without any restriction, along with release notes what exactly was new in the update, both as part of the announcement of a new beta, and again as part of the updated binaries.


Problably some of the beta testers want to confirm here. There is no conspiracy theory here.
Thomas Richter is offline  
Old 09 March 2019, 09:25   #52
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Quote:
Originally Posted by patrik View Post
@Thomas:

How come a scan is triggered at SetPatch time, isn't a full master + slave scan already done during scsi.device init time?

I do not recall the full details, though the initial scan works with a different command. The scsi.device uses an equivalent of "test unit ready" to wake up devices. Unfortunately, it turned out that this is not enough for all types of devices. From my memories, the problem is that the IDE "DASP"-line is dual use, drives both the drive busy LED, but is also involved in the master/slave identification process somewhat. Some CF cards do not release the line until a full scan with INQUIRY (or its IDE equivalent) is run, resulting in a permanently lid drive-busy LED. The mentioned patch addresses this.


This patch (actually, it does not patch anything, it just triggers a scan) came in at 45.6, a relatively early release of SetPatch. We finally released 45.15, which was about a year later. Since nobody complained or reported a bug for this patch, it remained in.
Thomas Richter is offline  
Old 09 March 2019, 11:09   #53
McTrinsic
Registered User

 
Join Date: Feb 2014
Location: Germany
Posts: 445
The idea that there is a ‚conspiracy‘ most probably is based on a hidden agenda by whoever spreads this.

The beta testers all did a diligent job to find issues and single them out. A lot of work was put into the root cause. More often than not issues were created by third party hacks. In one case we even found a bug in PFS3aio. Just to make sure: PFS3aio is awesome and not a hack. So indeed, after all, I can say we did not find all issues or they were not relevant for us. I don’t use scsi.device at all, how could I notice?

To be better able to test actual ROMs I opened up my machine and sort of fried it. Now my machine needs repair. But since it seems repairable I would say it was worth it .

Just would like to have it up and running soon again so that I can verify any issues reported in forums.
McTrinsic is offline  
Old 09 March 2019, 13:05   #54
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by Thomas Richter View Post
I do not recall the full details, though the initial scan works with a different command. The scsi.device uses an equivalent of "test unit ready" to wake up devices. Unfortunately, it turned out that this is not enough for all types of devices. From my memories, the problem is that the IDE "DASP"-line is dual use, drives both the drive busy LED, but is also involved in the master/slave identification process somewhat. Some CF cards do not release the line until a full scan with INQUIRY (or its IDE equivalent) is run, resulting in a permanently lid drive-busy LED. The mentioned patch addresses this.


This patch (actually, it does not patch anything, it just triggers a scan) came in at 45.6, a relatively early release of SetPatch. We finally released 45.15, which was about a year later. Since nobody complained or reported a bug for this patch, it remained in.
Very interesting, thank you for the details.

I guess this extra scan is not by IDE specification, but rather by observed behaviour of a few buggy devices?

Would it be possible to implement some solution so the 99.99% of us who don't have devices with this "feature" can avoid this delay? Like using a blacklist policy, only triggering it for the affected family of devices or creating a background process which can complete this scanning in the background while the normal booting continues?
patrik is offline  
Old 09 March 2019, 14:13   #55
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Quote:
Originally Posted by patrik View Post
Would it be possible to implement some solution so the 99.99% of us who don't have devices with this "feature" can avoid this delay?
How exactly should I do this? I do not have access to all devices that are used in the field, so I can hardly create a blacklist. All I can say is that this particular workaround did not cause any trouble during beta-testing, i.e. it did not break anything else, otherwise it wouldn't be part of the distribution. Opening up this again would require to go through testing, and in particular, we would need to ensure that the patch still works. An "INQUIRY" is a harmless command and should not have any negative side effects.

Starting this in background would not be very helpful. Remember, it only applies to the IDE "scsi" device, thus, whenever that is busy scanning the bus, the system cannot continue to load the startup-sequence either as the IDE bus is busy anyhow.
Thomas Richter is offline  
Old 09 March 2019, 14:22   #56
EzdineG
Registered User

 
Join Date: Apr 2017
Location: Springfield, MO
Posts: 256
3.1.4 SetPatch is very slow

Quote:
Originally Posted by Thomas Richter View Post
How exactly should I do this? I do not have access to all devices that are used in the field, so I can hardly create a blacklist.
What about a command line argument such as “QUICK” that would prevent the scan?

That way we can bypass it manually on machines that exhibit abnormally long wait times due to said scan.
EzdineG is offline  
Old 09 March 2019, 18:52   #57
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by Thomas Richter View Post
How exactly should I do this? I do not have access to all devices that are used in the field, so I can hardly create a blacklist.
Fair point.

Quote:
Originally Posted by EzdineG View Post
What about a command line argument such as “QUICK” that would prevent the scan?

That way we can bypass it manually on machines that exhibit abnormally long wait times due to said scan.
Or rather an opt-in argument for the few with this issue - the issue is harmless, it just causes the HD-led to not work properly. Otherwise those computers wouldn't be able to come as far as loading SetPatch.
patrik is offline  
Old 10 March 2019, 07:13   #58
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 3,309
Quote:
Originally Posted by Thomas Richter View Post
Are you nuts? Do you seriously believe I kept udpates private and smuggled them into the distribution?
I'm not accusing you of that at all.

Quote:
Originally Posted by Thomas Richter
SetPatch was delivered as part of the regular beta test, for several months, along with all other updates, along with the Shell. So there was no "choice not to test".

So, seriously, what is your problem? We do not have a "huge crew", and certainly all updates are available to all beta testers without any restriction, along with release notes what exactly was new in the update, both as part of the announcement of a new beta, and again as part of the updated binaries.
I have two problems. The first one being that this is a commercial product.

The second one being that it was, in mine and several other user's opinions, not tested thoroughly enough before release.

Quote:
Originally Posted by Thomas Richter
Problably some of the beta testers want to confirm here. There is no conspiracy theory here.
I'm not trying to imply that there is. Please don't take my criticism personally. I think you're an extremely talented coder and an encyclopedia of Amiga knowledge. My problem is more with Hyperion rather than yourself.
Hewitson is offline  
Old 10 March 2019, 10:12   #59
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Quote:
Originally Posted by Hewitson View Post
I'm not accusing you of that at all.
Yes, you are.
Quote:
Originally Posted by Hewitson View Post
I have two problems. The first one being that this is a commercial product.
Then don't buy it.
Quote:
Originally Posted by Hewitson View Post
The second one being that it was, in mine and several other user's opinions, not tested thoroughly enough before release.
But you do understand that this is not a bug, right?
Quote:
Originally Posted by Hewitson View Post
My problem is more with Hyperion rather than yourself.
How exactly should Hyperion contribute to beta-testing?
Thomas Richter is offline  
Old 06 May 2019, 17:33   #60
Scrambler77
Registered User

 
Join Date: Apr 2019
Location: Italy
Posts: 1
Hallo everyone. I'm having that issue too: KS 3.1.4/Workbench 3.1.4/SetPatch 45.15. 3.2 sec delay in startup-sequence.
Clean install. My A1200 has a Cobra 030 installed.
Scrambler77 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
SetPatch / CacheControl() dissident Coders. System 17 04 March 2018 17:01
Setpatch 3.9 Romupdate Yes or No ? Nibbler support.Hardware 0 06 February 2015 22:31
setpatch option andreas request.UAE Wishlist 4 13 August 2008 16:21
SetPatch: Unloading possible? mrleeman support.Apps 1 21 July 2008 10:06
where can i find setpatch 44.38 turrican3 request.Apps 5 07 May 2007 19:46

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.11146 seconds with 13 queries