A bug perhaps ::: Could anyone confirm, please?

[Error]

I've encountered a really nasty bug and I am not quite sure what could be the problem, thus I would like to ask any of You outta there to confirm or bail out this post as a WinUAE... bug?

all You have to do is:

• set up Your WinUAE so that it uses uaescsi.device with Your CDROM
• launch it [no matter, with or without startup seq]
• call attached program [note: it's enclosed in endless loop]
• call some deep diggin hd operation, say, DIR sys: OPT A >NIL: [it's important that the action takes some more time before it finishes, say, 30 seconds]
• check if either of: attached program or dir operation freezes.

attached program dumps some useless text every time a loop is executed, thus it's enough to, say, press enter to see if it keeps filling Your CLI window ; for DIR operation it's enough to check if leds are still flashing / command returned.

Please perform it about three - four times before confirming / bailing out. Thanks in advance

ps. problem noticed running WinUAE .8.24 under WinXP, with FFS 45.9, both HDD and CDRW on same 40 ribbon cable

[thomas]

I tried it and it runs forever, no freeze at all. I tried dir work: all several times and work has about 32000 files, so the command needed at least a minute to finish.

[Error]

no freeze at all

I must be doing something wrong then.. I always get this in my winuaelog.txt after a freeze:

exter_int_helper: unknown native action

don't know what to do. can't test my isobuilder with my program . I get exactly same as running the above program and, say, dir opt a.

Cheers.

[Toni Wilen]

exter_int_helper: unknown native action

This shouldn't never happen. I guess the only possible reason is memory corruption somewhere...

Does the problem disappear if you boot without startup-sequence? Without startup-sequence + setpatch? etc..

[Error]

I guess the only possible reason is memory corruption somewhere...

hmm.. You know the source for TestUnitReady, You know the DIR command.. and it happens all the time, no matter I run with or without s-seq, with kick 3.1 or 3.5

hmm.. haven't tried setpatch, yet, I'll give it a try.. just a second...

tested w. kick 3.1 and setpatch 43.7 only. No success.

hmm. perhaps I do sth wrong in testprog.. do I?

I will be disconnected for a couple of days [weekend], so don't worry, I'll resume bugging Ya after I come back hehe

Tried to enable / disable JIT, enable "more accurate" emulation, different CPUs, different settings of CE/IB/FC... I tried everything .. I get same problems even with .8.22r5...

the only thing why I don't want to switch to Windows partitions is that I share same disk between Amiga, WinUAE and Amithlon, and I tried to mount windows partitions under Amithlon once [learning that it was quite bad idea ]...

uhmmmm... dunno (

[Error]

hmm I think I should start a bit differently here..

is there someone who actually uses Amiga HDD here? well I noticed that it doesn't happen with windows - handled disks at all [too few disk accesses], only with regular HDDs added with "add harddrive" option..

[Fackamato]

Just a note - there is no kickstart 3.5 AFAIK, it's fake (3.1)

[Error]

there is no kickstart 3.5 AFAIK, it's fake

well but it works fine, guys patched few functions in exec.library, workbench.library and possibly scsi.device, not sure about the third one. Patch was quite big [130kb] so I don't think it was a copy of kick3.1, was it

Cheers!

[WintermuteX]

I have to second this ..
KS 3.5 is a fake AFAIK!
just do a byte compare with a KS 3.1 and a KS 3.0 .. i guess it's nothing more than some changed strings and version information

[Error]

just do a byte compare

after I chose byte compare I got *tons* of changes.. but resync comparison revealed the truth...

shall I send You differences?

I got more than 0x4000 (16kb) of changes, including stuff like "latepatch" etc... some code has been removed, some new added etc, nvm;

pretty weird fake ain't it...

anyways, I'll stick to my fake 3.1 :P some progs shout they require newer workbench or exec libraries, and I don' t have to patch a thing any more...

about the original topic: I found out it is a bug in controller, just don't know whether hardware or software, same thing happens on Peg machines... so the original topic is closed