3.1.4 SetPatch is very slow

[kolla]

Every customer is a beta tester, that much is obvious.

[Thomas Richter]

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.

[patrik]

Originally Posted by Thomas Richter

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?

[kolla]

Originally Posted by Thomas Richter

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...

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?

[Hewitson]

Originally Posted by Thomas Richter

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?

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

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..

[Daedalus]

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.

[Hewitson]

Originally Posted by Daedalus

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.

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.

[Thomas Richter]

Originally Posted by kolla

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?

Originally Posted by kolla

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.

[patrik]

@Thomas:

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

[Hewitson]

Originally Posted by Thomas Richter

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.

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.

[Thomas Richter]

Originally Posted by Hewitson

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]

Originally Posted by patrik

@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.

[McTrinsic]

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.

[patrik]

Originally Posted by Thomas Richter

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?

[Thomas Richter]

Originally Posted by patrik

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.

[EzdineG]

Originally Posted by Thomas Richter

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.

[patrik]

Originally Posted by Thomas Richter

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.

Originally Posted by EzdineG

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.

[Hewitson]

Originally Posted by Thomas Richter

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.

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.

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.

[Thomas Richter]

Originally Posted by Hewitson

I'm not accusing you of that at all.

Yes, you are.

Originally Posted by Hewitson

I have two problems. The first one being that this is a commercial product.

Then don't buy it.

Originally Posted by Hewitson

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?

Originally Posted by Hewitson

My problem is more with Hyperion rather than yourself.

How exactly should Hyperion contribute to beta-testing?

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.