English Amiga Board


Go Back   English Amiga Board > Support > support.Other

 
 
Thread Tools
Old 15 January 2019, 14:19   #21
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
@patrik

One of the Developers tested on his machine: A1200 BlizzardPPC (68060)

3.1 and OS 3.9 setpatch -> 0.21 s

3.1 and OS 3.1.4 setpatch -> 0.25 s

Not much of a difference here.

BTW, I asked about the extra delay in MMULibs and that is because some time is taken to setup the MMU tables, which also requires to go through ENVARC:MMU-Configuration.
gulliver is offline  
Old 16 January 2019, 08:57   #22
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by gulliver View Post
@patrik

One of the Developers tested on his machine: A1200 BlizzardPPC (68060)

3.1 and OS 3.9 setpatch -> 0.21 s

3.1 and OS 3.1.4 setpatch -> 0.25 s

Not much of a difference here.
Interesting. Tested the same thing (kickstart 3.1 ("softkicked" with BlizKick/maprom) and SetPatch 45.15 and got the same result as him):
Code:
2.Ram Disk:> SYS:Tools/ShowConfig
PROCESSOR:      CPU 68040
CUSTOM CHIPS:   AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS:   Kickstart version 40.68, Exec version 40.10, Disk version 45.194
RAM:    Node type $A, Attributes $5 (FAST), at $60000000-$68F7FFFF (143.5 meg)
        Node type $A, Attributes $703 (CHIP), at $1000-$1FFFFF (~2.0 meg)
BOARDS:
 Board + ROM (HD?) (unidentified):   Prod=8512/17($2140/$11) (@$EA0000 128K)
2.Ram Disk:> version 68060.library FULL
68060.library 46.7 (19-Oct-99)
© 1994-1999 by Phase5, written by Ralph Schmidt
2.Ram Disk:> version C:SetPatch FULL
SetPatch 45.15 (11-May-18)
2.Ram Disk:> SYS:UHC/C/time C:SetPatch QUIET
0.238065s
2.Ram Disk:>
So something with the combination of kickstart 3.1.4 and SetPatch 45.15 creates this 3s+ delay.

Quote:
Originally Posted by gulliver View Post
BTW, I asked about the extra delay in MMULibs and that is because some time is taken to setup the MMU tables, which also requires to go through ENVARC:MMU-Configuration.
Still, 3s is a lot of computation time on a 68060.
patrik is offline  
Old 16 January 2019, 09:18   #23
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,529
Quote:
Originally Posted by patrik View Post
Still, 3s is a lot of computation time on a 68060.
No, that's not much. Windows 10 needs 1 hour on my 4 x 2.66 GHz CPU to cleanup the updates. How many instructions is that?
PeterK is offline  
Old 16 January 2019, 09:45   #24
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
Quote:
Originally Posted by PeterK View Post
No, that's not much. Windows 10 needs 1 hour on my 4 x 2.66 GHz CPU to cleanup the updates. How many instructions is that?
Auch! that hurts to compute if you see it from a humble 68k perspective

@patrik

From ThoR ..."Believe me, it is not SetPatch that is slow. The mmu.library is guilty here. It takes a while to build up the MMU pages with all the flexibility. Due to a feature of the 68060/68040 CPU, caches also need to stay off while it operates, and there are two copies of the tables to build."...
gulliver is offline  
Old 16 January 2019, 10:42   #25
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by gulliver View Post
From ThoR ..."Believe me, it is not SetPatch that is slow. The mmu.library is guilty here. It takes a while to build up the MMU pages with all the flexibility. Due to a feature of the 68060/68040 CPU, caches also need to stay off while it operates, and there are two copies of the tables to build."...
We are still talking about two separate issues, right?

1. SetPatch 45.15 takes 3s+ when run first time on kickstart 3.1.4.
2. Using 68060.library+mmu.library from the ThoR MMU.lib distribution adds an additional 3s+ execution time the first time you run SetPatch (affects all SetPatch versions).
patrik is offline  
Old 16 January 2019, 20:37   #26
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
Well acording to ThoR both issues are caused by MMULibs and the way SetPatch now properly deals with the 68060.

I am still not convinced entirely...

BTW, I opened a bug in our database to put more eyes on this matter.

------------------------------
Another tester reports:

SetPatch 45.21 from 3.1.4 (beta version) = ~5 seconds

SetPatch 44.38 from 3.9 = ~2 seconds

Blizzard 1260 (maprom enabled), 64 MB Fast and a 3.1.4 ROM in hardware. The CPU libraries are from the Thomas MMU package.
gulliver is offline  
Old 16 January 2019, 21:54   #27
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by gulliver View Post
Well acording to ThoR both issues are caused by MMULibs and the way SetPatch now properly deals with the 68060.

I am still not convinced entirely...
I am using the Phase5 68060.library, as can be seen by my test output where I versioned 68060.library.

I did actually have the mmu.library in LIBS:, but assumed SetPatch would not attempt to load it without the ThoR 68060.library.

Anyway, to be 100% certain, I deleted it and re-ran the 3.1.4 SetPatch test to show that it makes no difference:
Code:
2.Ram Disk:> SYS:Tools/ShowConfig
PROCESSOR:      CPU 68040
CUSTOM CHIPS:   AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.143, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $5 (FAST), at $60000000-$68F7FFFF (143.5 meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 Board + ROM (HD?) (unidentified):   Prod=8512/17($2140/$11) (@$EA0000 128K)
2.Ram Disk:> version 68060.library FULL
68060.library 46.7 (19-Oct-99)
© 1994-1999 by Phase5, written by Ralph Schmidt
2.Ram Disk:> version mmu.library FULL
object not found
2.Ram Disk:> SYS:UHC/C/time C:SetPatch QUIET
3.424798s
2.Ram Disk:>
Your suggestion made me a bit curious what the 3.1.4 SetPatch opens etc, so monitored it with SnoopDos and found something interesting - there is a large jump in time after the scsi.device:1 open attempt:
Code:
 Time     Process Name       Action     Target Name                 Options Res.
 ----     ------------       ------     -----------                 ------- ----
 21:44:42 ramlib             Load       LIBS:asl.library                    OK  
 21:44:42 ramlib             OpenLib    utility.library             Ver 0   OK  
 21:44:42 ramlib             OpenLib    intuition.library           Ver 0   OK  
 21:44:42 ramlib             OpenLib    graphics.library            Ver 0   OK  
 21:44:42 ramlib             OpenLib    layers.library              Ver 0   OK  
 21:44:42 ramlib             OpenLib    gadtools.library            Ver 0   OK  
 21:44:42 ramlib             OpenLib    icon.library                Ver 0   OK  
 21:44:42 ramlib             OpenLib    keymap.library              Ver 0   OK  
 21:44:42 ramlib             OpenFont   topaz.font                  Size 8  OK  
 21:44:42 ramlib             FindSem    asl.library                         Fail
 21:44:42 ramlib             Load       LIBS:workbench.library              OK  
 21:44:42 ramlib             Load       LIBS:iffparse.library               OK  
 21:44:42 ramlib             OpenLib    utility.library             Ver 37  OK  
 21:45:07 [1] Initial CLI    FindVar    C:SetPatch                  Alias   Fail
 21:45:07 [1] Initial CLI    ChangeDir  System3.1.4:                            
 21:45:07 [1] Initial CLI    Lock       C:SetPatch                  Read    OK  
 21:45:07 [1] Initial CLI    Load       C:SetPatch                          OK  
 21:45:08 [1] Initial CLI    Lock       C:SetPatch                  Read    OK  
 21:45:08 [1] Initial CLI    ChangeDir  System3.1.4:                            
/21:45:08 [1] C:SetPatch     RunCommand QUIET                       4096    ----
 21:45:08 [1] C:SetPatch     FindSem    « SetPatch »                        Fail
 21:45:08 [1] C:SetPatch     FindSem    « SetPatch »                        Fail
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    utility.library             Ver 0   OK  
/21:45:08 [1] C:SetPatch     OpenLib    680x0.library               Ver 0       
 21:45:08 ramlib             Load       LIBS:680x0.library                  Fail
 21:45:08 ramlib             Load       680x0.library                       Fail
\21:45:08 [1] C:SetPatch     OpenLib    680x0.library               Ver 0   Fail
/21:45:08 [1] C:SetPatch     OpenLib    68060.library               Ver 0       
 21:45:08 ramlib             Load       LIBS:68060.library                  OK  
/21:45:08 ramlib             OpenLib    68060quick.library          Ver 0       
 21:45:08 ramlib             Load       LIBS:68060quick.library             Fail
\21:45:08 ramlib             OpenLib    68060quick.library          Ver 0   Fail
 21:45:08 ramlib             Load       68060quick.library                  Fail
 21:45:08 ramlib             OpenLib    utility.library             Ver 0   OK  
 21:45:08 ramlib             OpenLib    mathieeesingbas.library     Ver 0   OK  
 21:45:08 ramlib             OpenLib    mathieeedoubbas.library     Ver 0   OK  
/21:45:08 ramlib             OpenLib    mathsingtrans.library       Ver 0       
 21:45:08 ramlib             Load       LIBS:mathsingtrans.library          Fail
\21:45:08 ramlib             OpenLib    mathsingtrans.library       Ver 0   Fail
 21:45:08 ramlib             Load       mathsingtrans.library               Fail
/21:45:08 ramlib             OpenLib    mathdoubtrans.library       Ver 0       
 21:45:08 ramlib             Load       LIBS:mathdoubtrans.library          Fail
\21:45:08 ramlib             OpenLib    mathdoubtrans.library       Ver 0   Fail
 21:45:08 ramlib             Load       mathdoubtrans.library               Fail
 21:45:08 ramlib             OpenLib    expansion.library           Ver 0   OK  
 21:45:08 ramlib             OpenRes    card.resource                       OK  
 21:45:08 ramlib             FindPort   BOOT-MMU-Port                       Fail
 21:45:08 ramlib             OpenLib    expansion.library           Ver 0   OK  
\21:45:08 [1] C:SetPatch     OpenLib    68060.library               Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    utility.library             Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    intuition.library           Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    intuition.library           Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    intuition.library           Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    intuition.library           Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    layers.library              Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    intuition.library           Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     FindRes    ramlib                              OK  
 21:45:08 [1] C:SetPatch     FindRes    ramlib                              OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenLib    graphics.library            Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenRes    card.resource                       OK  
 21:45:08 [1] C:SetPatch     OpenLib    exec.library                Ver 0   OK  
 21:45:08 [1] C:SetPatch     OpenDev    scsi.device                 Unit 0  OK  
\21:45:08 [1] C:SetPatch     RunCommand QUIET                       4096    0   
 21:45:08 [1] C:SetPatch     OpenDev    scsi.device                 Unit 1  Fail
 21:45:11 [1] C:SetPatch     SetVar     RC=0                        Local   OK  
 21:45:11 [1] C:SetPatch     SetVar     Result2=0                   Local   OK  
 21:45:11 [1] Initial CLI    GetVar     echo                        Local   Fail
 21:45:11 [1] Initial CLI    GetVar     oldredirect                 Local   Fail
 21:45:11 [1] Initial CLI    GetVar     interactive                 Local   Fail
Quote:
Originally Posted by gulliver View Post
BTW, I opened a bug in our database to put more eyes on this matter.
Thanks .

Quote:
Originally Posted by gulliver View Post
------------------------------
Another tester reports:

SetPatch 45.21 from 3.1.4 (beta version) = ~5 seconds

SetPatch 44.38 from 3.9 = ~2 seconds

Blizzard 1260 (maprom enabled), 64 MB Fast and a 3.1.4 ROM in hardware. The CPU libraries are from the Thomas MMU package.
Seems to correspond with my findings, a couple of tens percent faster.
patrik is offline  
Old 19 January 2019, 15:44   #28
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Given that we from previous tests have seen that:
1. Setpatch 45.15 needs 3+ seconds with kickstart 3.1.4.
2. SetPatch 45.15 needs about 0.2-0.3 seconds with kickstart 3.1.
3. SnoopDosing SetPatch 45.15 shows some suspicios delay after the scsi.device:1 open.

Especially the latter made me curious.

So first a baseline with a completely normal kickstart 3.1.4:
Code:
2.Ram Disk:> SYS:Tools/ShowConfig
PROCESSOR:      CPU 68040
CUSTOM CHIPS:   AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.143, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $5 (FAST), at $60000000-$68F7FFFF (143.5 meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 Board + ROM (HD?) (unidentified):   Prod=8512/17($2140/$11) (@$EA0000 128K)
2.Ram Disk:> version 68060.library FULL
68060.library 46.7 (19-Oct-99)
© 1994-1999 by Phase5, written by Ralph Schmidt
2.Ram Disk:> version mmu.library FULL
object not found
2.Ram Disk:> version scsi.device FULL
scsi.device 45.7 (16-May-18)
2.Ram Disk:> version C:SetPatch FULL
SetPatch 45.15 (11-May-18)
2.Ram Disk:> SYS:UHC/C/time C:SetPatch QUIET
3.511627s
2.Ram Disk:>
The normal, very slow result.

So, back to the initial three points - kickstart 3.1 makes SetPatch 45.15 fast and SnoopDos shows that something around scsi.device causes the delay, so what happens if we LoadModule scsi.device 40.12 from kickstart 3.1 in the 3.1.4 system:
Code:
2.Ram Disk:> SYS:Tools/ShowConfig
PROCESSOR:      CPU 68040
CUSTOM CHIPS:   AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.143, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $5 (FAST), at $60000000-$68F7FFFF (143.5 meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 Board + ROM (HD?) (unidentified):   Prod=8512/17($2140/$11) (@$EA0000 128K)
2.Ram Disk:> version 68060.library FULL
68060.library 46.7 (19-Oct-99)
© 1994-1999 by Phase5, written by Ralph Schmidt
2.Ram Disk:> version mmu.library FULL
object not found
2.Ram Disk:> version scsi.device FULL
scsi.device 40.12 (21-Dec-93)
2.Ram Disk:> version C:SetPatch FULL
SetPatch 45.15 (11-May-18)
2.Ram Disk:> SYS:UHC/C/time C:SetPatch QUIET
0.340682s
2.Ram Disk:>
So the 3.1.4 SetPatch handling of the 3.1.4 scsi.device, or the 3.1.4 scsi.device itself is the reason for this very long delay.

Last edited by patrik; 19 January 2019 at 15:52.
patrik is offline  
Old 31 January 2019, 06:07   #29
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
It did finally hit me:

scsi.device 40.x does not correctly follow ATA standards (I believe they were not even defined yet back then), so the startup delay is notably inferior. This delay is required for proper drive spin up.

And as the delay occurs at aproximately the same time SetPatch is doing its thing, we end up blaming it.

If you go even further and compare scsi.device v40 vs v39 in an A1200 the difference will be enormous for the very same reason. In 3.0 the spin up delay was set up to a stupidly low value.

So yes, v39 scsi.device will be the fastest booting of all, but many harddisks will not be able to spin up fast enough to be ready and report that state to the system. So the machine will not be able to detect them upon boot and will show the rom insert floppy animation.
gulliver is offline  
Old 31 January 2019, 07:57   #30
pipper
Registered User

 
Join Date: Jul 2017
Location: San Jose
Posts: 143
But isn’t the time when the startup-sequence gets executed already way past the wait for hard drive spin up?
pipper is online now  
Old 31 January 2019, 09:25   #31
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
Quote:
Originally Posted by pipper View Post
But isn’t the time when the startup-sequence gets executed already way past the wait for hard drive spin up?
Yes, you are right. I still dont buy the MMU tables theory.

A case that neither my Doom 2 therapy, and my restless insomnia can probably solve. :-)
gulliver is offline  
Old 31 January 2019, 10:30   #32
amiwolf
Registered User

 
Join Date: Aug 2015
Location: Emerald City
Posts: 61
Could it simply be that the new scsi.device just does everything more slowly? When I replaced Don Adan's scsi.device 46.1 with scsi.device 45.7 on a bog standard 68000, 2MB Chip KS3.1 A600, Sysinfo 4 reported a speed drop of 136.5kB/s under PFS3AIO-19.2.
amiwolf is offline  
Old 31 January 2019, 11:04   #33
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
Quote:
Originally Posted by amiwolf View Post
Could it simply be that the new scsi.device just does everything more slowly? When I replaced Don Adan's scsi.device 46.1 with scsi.device 45.7 on a bog standard 68000, 2MB Chip KS3.1 A600, Sysinfo 4 reported a speed drop of 136.5kB/s under PFS3AIO-19.2.
Yes, it could be as simple as that.
gulliver is offline  
Old 31 January 2019, 11:18   #34
kolla
Banned
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,899
Quote:
Originally Posted by gulliver View Post
On the other hand, SetPatch 45.15 in AmigaOS 3.1.4 has a much bigger
patch database, and its job is done in a more safe fashion and trying
to play nice with the Operating System.
I am curious what OS 3.1.4 SetPatch needs to patch in the OS 3.1.4 kickstart that would require a much bigger patch database. Or are you saying that the OS 3.1.4 SetPatch patch database also contains patches for bugs in older kickstarts, and is meant to work with older kickstarts than those of OS 3.1.4?

Last edited by kolla; 31 January 2019 at 11:24.
kolla is offline  
Old 03 March 2019, 13:31   #35
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
This thread should perhaps be renamed 3.1.4 scsi.device makes 3.1.4 SetPatch very slow.

As we know from previous SnoopDos logs in this thread, 3.1.4 SetPatch opens/closes scsi.device unit 0 followed by scsi.device unit 1.

To simulate what the 3.1.4 SetPatch does, I wrote a small program I call OpenCloseDevice, which just opens/closes a device. I then used that to open/close scsi.device in the same order as SetPatch:
Code:
New Shell process 2
2.Ram Disk:> SYS:Tools/ShowConfig
PROCESSOR:      CPU 68040
CUSTOM CHIPS:   AA PAL Alice (id=$0023), AA Lisa (id=$00F8)
VERS:   Kickstart version 46.143, Exec version 46.45, Disk version 45.194
RAM:    Node type $A, Attributes $5 (FAST), at $60000000-$68F7FFFF (143.5
meg)
        Node type $A, Attributes $703 (CHIP), at $4000-$1FFFFF (~2.0 meg)
BOARDS:
 Board + ROM (HD?) (unidentified):   Prod=8512/17($2140/$11) (@$EA0000 128K)
2.Ram Disk:> SYS:UHC/C/time C:OpenCloseDevice scsi.device 0
Opened scsi.device:0 45.7
0.025496s
2.Ram Disk:> SYS:UHC/C/time C:OpenCloseDevice scsi.device 1
Failed opening scsi.device:1
C:OpenCloseDevice failed returncode 10
3.239154s
2.Ram Disk:> SYS:UHC/C/time C:OpenCloseDevice scsi.device 1
Failed opening scsi.device:1
C:OpenCloseDevice failed returncode 10
0.028486s
2.Ram Disk:>
Observe the 3.2s+ delay in the open/close of scsi.device unit 1. Also added an additional open/close of scsi.device unit 1, which shows that this delay only happens on the first open/close of scsi.device unit 1.

So two questions:
1. Why does the 3.1.4 SetPatch open both scsi.device unit 0 and unit 1?
2. Why does the first open of the 3.1.4 scsi.device unit 1 produce this enormous delay? Shouldn't any device scanning have been taken care of during boot already?

Last edited by patrik; 03 March 2019 at 13:36.
patrik is offline  
Old 03 March 2019, 17:21   #36
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 2,347
Interesting observation. In the case thor doesn't read this you should write him an email.
daxb is offline  
Old 05 March 2019, 13:28   #37
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 41
Posts: 1,993
@patrik

SetPatch does indeed play with scsi.device. From the top of my head I do remember three situations, there may be more. Last time I took a look at SetPatch was only to update the year string to 2019.

One of those situations is when it deals with the activity led and the other is when it tries to fix some specific issues hard drives models of the brand Conner had. And the last one I recall, is when it clears signal bit SIGF_SINGLE before allowing an open of scsi.device to begin.

Anyway both Thomas and Olaf are the experts in scsi.device matters, which is something I would not even touch with a ten foot pole.

I have added this new information you provided to our database, and that triggers and email to Thomas by default.
gulliver is offline  
Old 05 March 2019, 19:21   #38
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 39
Posts: 568
Quote:
Originally Posted by gulliver View Post
I have added this new information you provided to our database, and that triggers and email to Thomas by default.
Thanks!
patrik is offline  
Old 06 March 2019, 04:12   #39
Hewitson
Registered User
Hewitson's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 36
Posts: 3,319
Looks like theres yet another bug to add to the list. They had hundreds of beta testers willing to do it for free, yet decided to just "send it". Extremely unprofessional, it's the sort of behaviour you'd expect from Microsoft.
Hewitson is offline  
Old 06 March 2019, 08:23   #40
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 255
Quote:
Originally Posted by Hewitson View Post
Looks like theres yet another bug to add to the list. They had hundreds of beta testers willing to do it for free, yet decided to just "send it". Extremely unprofessional, it's the sort of behaviour you'd expect from Microsoft.
Looks like another rant from someone without background. Just for you: a) we do not have hundreds of beta-testers. 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.

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.
Thomas Richter 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 02:44.


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