@thread

More info on IRQs for those interested:
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=18362&forum=33

Link in post#1 shows where the convo originated.
Links throughout to George Breese of VIA, and Ian Stedman's analysis after he was called in to look at the issues. Plenty of informative links within the thread.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

USB was mentioned in this thread and referred to earlier in this thread,
The following from May, 2006 was not read/commented on much probably due to appearing in a thread titled "demo of new OS4 hardware (not A1 or Amy)":

ssolie quote:
Quote:

You may want to re-think your stance on the 'hw-bugs-free' and buy a used A1. The SE is a lemon, stay away from it. The XE has the Ethernet vs VIA IDE problem which is nasty but you can avoid it with an IDE controller or apply a fix to the board. Some XEs also have the USB port debouncing issue which you can avoid by just not hot plugging devices or a hub. The MicroA1 has no known problems that I'm aware of. So yeah, there are some probs. with the A1 boards but only the Ethernet vs VIA IDE prob is a showstopper and it has a workaround.

DaveAE response:
Quote:

USB+HD (even on sii0680) can cause irq loss and freezes. USB+audio can cause stutter (for some). Eth+audio will cause freezes.The microA1 has extra logic which makes VIA IDE work with DMA but can cause heavily delayed IRQ's.So, unless new hw shows the same problem, all A1 flavours are no good for any serious 'multi-media' (gosh I hate that term) use.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@amipal

Quote:

It certainly makes it difficult to diagnose problems when you're not sure if it is the hardware or the software!

I think it's a bit of both. One flash drive is fine, another will crash.

@TetiSoft

Quote:

AFAIR the "original Amiga" was also not a perfect hardware.Do you remember the ZorroIII DMA problems with the first Buster revisionson the A3000? Do you remember the missing interrupt line on the A3k CPUslot which had to be added/soldered by hand to be able to use a CPU boardwith SCSI controller? Do you remember the A1200 PCMCIA bug? The A1200 videobug (it flickered in some modes when the background was 100% white). TheA1200 floppy drive incompatibility? The incompatibilities of the A2000A model?

No. No. Yes. Really? Never saw that that I can recall. Yeah I think I do. No, to far back for me.

I never owned an A3000, but have a friend that does. He is into electroncs so may have worked around it. He did have the A3000/UX model IIRC. He had a big tower at least.

I remember that PCMCIA bug, and used to work around it, and thought it was the most direct bug to the A1 USB. Actually, my A1200 has a resistor solder on a chip so may have ben fixed when my A1200 also needed a service to properly work with an accelerator. As to the floppy drive problem, I beleive, for no good reason that Commodore removed the disk ready hardware line? A lot of games used this, and were left waiting, and there was also a hardware hack to fix it or work around it.

Quote:

I dont say the AOne is extraordinary hardware, but before comparing it withAmiga hardware dont forget to remember that the original Amiga hardware wasalso not absolutely perfect. At least not all models.

I do agree with you there. Except for one thing, the AmigaOne isn't a real Amiga. It was a ten year late spinoff that really, apart from a big endian CPU, has nothing relating to the original Amiga in the hardware alone. Well that just IMHO.

@TetiSoft

Quote:

Of course its a bug in the USB stack and not in the docky or AmiDock,and of course you already have send lots of crashlogs plus an exactdescription of "a certain USB drive" to the USB stack authors?

If it's not CPUDocky then something else will get trampled on. But it alwasys happens during a USB operation. I don't know who the USB authors are. Is there yet some kind of user bug tracker central HQ where we (meaning users and me) can post bugs and crashlogs? I take it you know a place where these people (developers) are listed and can be emailed?

My drive? A RunDisk pro 2.0. 512MB. Has UR24 on the back. It is strange, and this could be causing problems, the plug has no shielding. If I use a cable in between my USB slot and the drive it works fine. As well as a hub inbetween.

Here is a crashlog that happens when I plug it in. Directly to my front USB port. From motherboard front USB header.


Dump of context at 0x01676EE0
Trap type: DSI exception
Machine State (raw): 0x00003032
Machine State (verbose): [Super] [FPU on] [IAT on] [DAT on] [Recoverable]
Temporary stack trace:
#0: in module Kickstart/kernel+0x00015418 (0x01215418)
#1: in module Kickstart/kernel+0x0001A464 (0x0121A464)
#2: in module Kickstart/timer.device.kmod+0x0000145C (0x0144D27C)
#3: in module Kickstart/kernel+0x00011430 (0x01211430)

Crashed task: CPUClock.CPUTask (0x6CB7E1E0)
0: 5BE03568 01678E40 00000000 5BE03564 6D3B5BE0 6D3B5BE0 00000007 00000000
8: E8CE205D 00000001 E8CE205D 6D3B5C10 00000000 00000000 00000000 00000000
16: 00000000 00000000 00000000 00000000 00000000 01793B4A 6FFFE484 00000000
24: 00000000 E8CE206C 00000000 016827D0 5BE03550 00000007 6D3B5BE0 016827D0
CR: 48000024 XER: 20000000 CTR: 0121542C LR: 0121A288
DSISR: 40000000 DAR: 5BE0356C
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation
Dump of context at 0x01672EE0
Trap type: DSI exception
Machine State (raw): 0x00003032
Machine State (verbose): [Super] [FPU on] [IAT on] [DAT on] [Recoverable]
Temporary stack trace:
#0: in module Kickstart/kernel+0x00015418 (0x01215418)
#1: in module Kickstart/kernel+0x0001A464 (0x0121A464)
#2: in module Kickstart/timer.device.kmod+0x0000145C (0x0144D27C)
#3: in module Kickstart/kernel+0x00011430 (0x01211430)

Crashed task: CPUClock.CPUTask (0x6CB7E1E0)
0: 5C107028 01674E40 00000000 5C107024 6D3B5C10 6D3B5C10 00000007 00000000
8: 00000000 00000001 00000000 6C2CFB10 00000000 00000000 00000000 00000000
16: 00000000 00000000 00000000 00000001 00000001 01793B4A 6FFFE484 01600000
24: 00000000 E8CE50D5 00000000 016827D0 5C107010 00000007 6D3B5C10 016827D0
CR: 44004084 XER: 20000000 CTR: 0121542C LR: 0121A288
DSISR: 40000000 DAR: 5C10702C
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation

Registers pointing to code:
r1 : native kernel module Kickstart/kernel+0x00478E40
r21: native kernel module Kickstart/kernel+0x00593B4A
r27: native kernel module Kickstart/kernel+0x004827D0
r31: native kernel module Kickstart/kernel+0x004827D0
ip : native kernel module Kickstart/kernel+0x00015418
lr : native kernel module Kickstart/kernel+0x0001A288
ctr: native kernel module Kickstart/kernel+0x0001542C

Stack Backtrace:
native kernel module Kickstart/kernel+0x00015418
native kernel module Kickstart/kernel+0x0001A464
native kernel module Kickstart/timer.device.kmod+0x0000145C
native kernel module Kickstart/kernel+0x00011430

Disassembly of crash site:
01215408: 7CA42B78 mr r4,r5
0121540C: 4BFFFFDC b 0x12153E8
01215410: 38030004 addi r0,r3,4
01215414: 90040000 stw r0,0(r4)
>01215418: 81230008 lwz r9,8(r3)
0121541C: 90890000 stw r4,0(r9)
01215420: 91240004 stw r9,4(r4)
01215424: 90830008 stw r4,8(r3)
01215428: 4E800020 blr
0121542C: 7C832378 mr r3,r4
Stack pointer (0x01678E40) is outside bounds
Redzone is OK (4)

68k register dump
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000


Dump of context at 0x01672EE0
Trap type: DSI exception
Machine State (raw): 0x00003032
Machine State (verbose): [Super] [FPU on] [IAT on] [DAT on] [Recoverable]
Temporary stack trace:
#0: in module Kickstart/kernel+0x0001541C (0x0121541C)
#1: in module Kickstart/kernel+0x0001A464 (0x0121A464)
#2: in module Kickstart/timer.device.kmod+0x0000145C (0x0144D27C)
#3: in module Kickstart/kernel+0x00011430 (0x01211430)

Crashed task: CPUClock.CPUTask (0x6CB7E1E0)
0: 5BE03568 01678E40 00000000 5BE03564 6D3B5BE0 6D3B5BE0 00000007 00000000
8: E8CE205D 00000001 E8CE205D 6D3B5C10 00000000 00000000 00000000 00000000
16: 00000000 00000000 00000000 00000000 00000000 01793B4A 6FFFE484 00000000
24: 00000000 E8CE206C 00000000 016827D0 5BE03550 00000007 6D3B5BE0 016827D0
CR: 48000024 XER: 20000000 CTR: 0121542C LR: 0121A288
DSISR: 42000000 DAR: 00000001
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a store operation

Registers pointing to code:
r1 : native kernel module Kickstart/kernel+0x00478E40
r21: native kernel module Kickstart/kernel+0x00593B4A
r27: native kernel module Kickstart/kernel+0x004827D0
r31: native kernel module Kickstart/kernel+0x004827D0
ip : native kernel module Kickstart/kernel+0x0001541C
lr : native kernel module Kickstart/kernel+0x0001A288
ctr: native kernel module Kickstart/kernel+0x0001542C

Stack Backtrace:
native kernel module Kickstart/kernel+0x0001541C
native kernel module Kickstart/kernel+0x0001A464
native kernel module Kickstart/timer.device.kmod+0x0000145C
native kernel module Kickstart/kernel+0x00011430

Disassembly of crash site:
0121540C: 4BFFFFDC b 0x12153E8
01215410: 38030004 addi r0,r3,4
01215414: 90040000 stw r0,0(r4)
01215418: 81230008 lwz r9,8(r3)
>0121541C: 90890000 stw r4,0(r9)
01215420: 91240004 stw r9,4(r4)
01215424: 90830008 stw r4,8(r3)
01215428: 4E800020 blr
0121542C: 7C832378 mr r3,r4
01215430: 7CA42B78 mr r4,r5
Stack pointer (0x01678E40) is outside bounds
Redzone is OK (4)

68k register dump
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

@Hypex

Remove “CPUClock" it crashed when timing CPU usage (timer.device).

Last edited by NutsAboutAmiga on 19-Jul-2007 at 04:00 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Remove "CPUClock" it crashed when timing CPU usage (timer.device).

Okay I did so and it left nothing to buffer the effect of the USB crash, my system just froze, had to hard reset and it left no trace of a crash log.


Although, sometimes, it didn't always freeze up when I tested this in the past, so I may able to "catch" it some time in the near future.

Last edited by Hypex on 19-Jul-2007 at 04:07 PM.

@Hypex

Please test with the July update and include T:USB.log when it doesnt work.

@Hypex

Quote:

As to the floppy drive problem, I beleive, for no good reason that Commodore removed the disk ready hardware line? A lot of games used this, and were left waiting, and there was also a hardware hack to fix it or work around it.

IIRC (but I'm not sure) it was Escom who used floppy drives without the DSKRDY
pin (or without any signal on the pin). The absence of that pin e.g. causes the inability to autodetect if a
floppy drive is present, the disk.resource in ROM simply assumes each A1200
always has a floppy drive.

@TetiSoft

Quote:

Please test with the July update and include T:USB.log when it doesnt work.

Okay, will do.

@TetiSoft

Quote:

IIRC (but I'm not sure) it was Escom who used floppy drives without the DSKRDYpin (or without any signal on the pin). The absence of that pin e.g. causes the inability to autodetect if afloppy drive is present, the disk.resource in ROM simply assumes each A1200always has a floppy drive.

Guess that is a fair assuption. I think I also read that the ROM routine was modified to delay the amount of time for spinup so the system could live without it. Doesn't seem as accurate though.

@Hypex

Quote:

As to the floppy drive problem, I beleive, for no good reason that Commodore removed the disk ready hardware line? A lot of games used this, and were left waiting, and there was also a hardware hack to fix it or work around it.

It was Escom who couldn't get hold of proper floppies with RDY signal and used ones without. The OS never really used this signal, it just waited a bit so it worked. However, some NDOS games used it to check if the drive have already spinned up and they can proceed with the read/write operation. Without the signal they waited forever. The HW hack was probably to base this signal on the "motor on" signal with a small delay (made using a simple capacitor based circuit).

@yak

Quote:

It was Escom who couldn't get hold of proper floppies with RDY signal and used ones without. The OS never really used this signal, it just waited a bit so it worked. However, some NDOS games used it to check if the drive have already spinned up and they can proceed with the read/write operation. Without the signal they waited forever. The HW hack was probably to base this signal on the "motor on" signal with a small delay (made using a simple capacitor based circuit).

Yeah I think it was. Humans was one (unfinished) game that used this signal. A very polished and well done game for it's time. I hacked it so that it didn't wait forever, but it still didn't work on my A1200, perhaps I should have added a delay.

@hotrod
I thought this was more of a hardware problem with the amigaones...