Hi @Bodie

Sounds good! Oops 'pun' not intended~ :)

I put my SB128 at the bottom PCIslot furthest from AGP. Isn't bus noise inherent in sound devices and system IRQ triggers? I'm in the same company with Tomazkid....most of the time everthing runs reasonable with no problems. I got Tunenet v56 playing jazz in the background and it's--

@Snuffy

I've used TuneNet tonight too and it's working great. I can stream music, no problem at all.

You have to put download something at high speed to cause the lockup.

Download a big file from a fast site and use your favourite mp3-player and put it on playing 10 songs or so...

@DaveAE

Tried some AIFFs on loop, and didn't last any longer than MP3s. So I guess we can chuck mpega.library out of the mix...

_________________
After a decade away from the scene, I am back!

@all

Tried to follow the thread lately, can't figure out that are the conclusions

Can anyone enlighten me plz?

10X,
Jack

_________________

"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg

@jack

I'm feeling at a dead end now to be honest

In summary (Between the various tests going on here):

- (Audio only) Playing audio (Using many different players), while offline or an idle network (ie. No surfing, RDesktopping etc...) allows the playing of audio til the cows come home

- (Network only) Networking without audio & the user can continually surf (For example)

- (Audio + Network) Playing audio (Again, any player) & networking is causing an audio lock up where the whole system locks up & the audio gets 'jammed' in a very short loop, causing a buzzing noise. Only a reboot (Soft or Hard) can escape the crash

- (Network only) Playing 'movie' files with audio muted has not caused the crash even when networking is also being executed

- (VCore & 3rd Party tests) Varying VCores have been tried out by people, completely clean installs (For example, this crash has occured since the ORIGINAL OS4 Pre CD installation), with 'user-startup' files removed & 'WBStartup' directories removed

- (Heat tests) New fans have been installed, cases left open & even tests with minimal cooling have been carried out to see if heat causes any change in the stability

- Some people appear to have reduced the frequency of crashes (In some rare cases, completely) but others continue to get this crash but no single conclusion has been brought to light

- (Audio + Network) We're had tests with single LARGE files being downloaded & also small files (eg. Websites with a few images) to see if 'chunks' of downloads cause more or less chance of a crash, still while audio is being played. We get the crash in both cases.

- (Audio + Network) We've had tests with single streaming audio (TuneNet, Amplifier, AmigaAmp) with no other networking that has caused the crash

- (PCI tests) Some have tried moving their sound card to other slots

- (A1 model) Without checking the entire thread, I believe the crash has occured on A1-XE's, A1-SE's & uA1 motherboards

- The crash causes a complete lock up so a Reaper report cannot be submitted

- And I can't think of anything else at the moment


It SEEMS that ANY audio being played (whether it be MP3, AIFF's, audio from a movie (ie. MPlayer) or audio from games causes this lock up while the system is actively (Not just online but idle) networking in one way or another.

Some of us can actually 'demo' the crash in that we can guarantee that it will happen under given circumstances. Others don't seem to have it happen to them. It seems intermitent to some but then regular to others (Annoying).

It's extremely frustrating that no one in a position to do anything about this has actually been able to report that they can also replicate the crash.


I think that just about sums it up, if anyone thinks I've missed something, let me know.

FuZion.

@jack

Today I've been downloading three Debian ISOs while running the DNET client and downloading email via YAM every 15 minutes.

Started at 19:00, still going when I got in 22:44. Only stopped the downloads because they were messing up a slow forum I was posting on.

Of course, if I was to chuck audio into the mix, I wouldn't have expected it to last for even an hour. In fact, most of the time it falls over just as you go out of the door!

Last edited by amipal on 05-Jul-2005 at 10:47 PM.

_________________
After a decade away from the scene, I am back!

@FuZion

I notice that AWeb crashes regulary here if I try to use AmigaAmp at the same time, but seems to be rock solid if AmigaAmp isn't playing anything in the background. This problem only started for me after I installed Update3 (if it existed before, it was rare). On some occasions, I can be using AWeb happily, switch to WB to load up AmigaAmp and start it playing, and the next link I click on in AWeb causes the Grim Reaper.

It may be coincidence, but it seems a little too coincidental.

Chris

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@FuZion

Quote:

- (Audio + Network) We're had tests with single LARGE files being downloaded & also small files (eg. Websites with a few images) to see if 'chunks' of downloads cause more or less chance of a crash, still while audio is being played. We get the crash in both cases.

Don't know what others have experienced but for me a single LARGE download with audio does NOT cause any crash.

Can't say exactly how long a 2 gb download takes but my AOne has no problem downloading ONE file up to the 2gb limit with audio going for the duration.

Haven't checked how many files are the limit for myself yet though.

_________________
Fixed A1G4XE 7455 RX933PC with fried CPU
Sapphire Radeon 9100 128mb
ESI Juli@ 24bit 192kHz Envy24HT
Sil 680 Ultra Ata 133 E-ide
SeaGate Barracuda 120gb 8mb cache

@Chris_Y

Cheers for that Chris. See if you can replicate it with Amplifier & TuneNet too. The more info we can get on this one, the more chance we've got of narrowing down the perpetrator (Oooh, big word).

FuZion.

@Steff

Sorry yeah, I should have mentioned the scenario. A couple of people have been downloading linux .iso files (I think it was), because they're pretty large. I can't remember who though, this thread is getting long

FuZion.

@FuZion

I also tested everything from cooling vcore etc and
always had this problem.

Maybe there is some problems with freeing irq time or
whats it called. I remember when i had prelude on a4000
and ioblix. Or maybe it was some other card.
One of the cards driver had a bug where it didnt let any
free irq (i believe it was called like that) to others.
That made programs that wanted to play sound like jabberwocky
to never play anything. Just freezes and waits.

Later it was fixed as i reported it.
However this was on a4000.

For the a1 it could be whatever. HW or software.

Its just strange it freezes the whole computer.

@all
The problem is not only one for sure.

1-Audio+ethernet
2-vcore or heat

_________________
ikir

@Kicko

We check if the IRQ is for the audio driver, otherwise we return immediately. If this wasn't the case, it would hang immediately if two devices were using the same interrupt.

@all
Anyone tried with Miami instead of Roadshow?

Does it happen under Linux as well?

_________________
Audio Evolution
http://www.audio-evolution.com

@DaveAE

Quote:

We check if the IRQ is for the audio driver, otherwise we return immediately. If this wasn't the case, it would hang immediately if two devices were using the same interrupt.

Btw, with interrupt servers (AddIntServer()) there is/used to be that thing with the Z flag upon return of the server routine. If it was set Exec would continue calling the following servers in the chain. If it was clear, the loop would be left and no other interrupt server in the chain would be called.

Theoretically if an interrupt server decided that the IRQ is not for him, but left the routine with the Z flag set wrongly (cleared instead of set) the interrupt server for which the IRQ really was would not be called. And if it is such a IRQ that needs to be manually cleared/reset to avoid it being called again and again and again, then this problem would get you basically into a freeze situation.

What I myself never undestood (not being really much of lowlevel hw coder) was if that feature is safe at all. Can't it be that two devices using same interrupt generate interrupt at the same time (maybe there was some short time where interrupts were disabled and in this timeframe both devices generate an interrupt) and if first interrupt server returns "yes it is mine interrupt, do not call other interrupt servers" then the second device's interrupt server would not be executed although it should.

Or not?

@Georg

The IRQ on the other card would remain high, so the interrupt chain would be called again until it's cleared. Theoratically, there could be a bug in there. I do know however that in the situation of this freeze, the audio card's interrupt still gets called and is handled correctly.

_________________
Audio Evolution
http://www.audio-evolution.com

@DaveAE

Quote:

The IRQ on the other card would remain high, so the interrupt chain would be called again until it's cleared

Yes but they would again be called in same order with again the buggy one returning "it's mine" although it isn't and so the interrupt server of the one to which it belongs (behind it in the server chain list) gets no chance to clear it.

interrupt chain[IRQ 123]
DEVICE 1
DEVICE 2

interrupt triggered by device 2:

interrupt handling:
interrupt chain handling: go through chains
device "1" says "it's mine" although it isn't.
leave interrupt chain handling
[device 2 server does not get called]

interrupt handling (again, because IRQ not cleared)
interrupt chain handling: go through chains
device "1" says "it's mine" although it isn't
leave interrupt chain handling
[device 2 server does not get called]

Interrupt handling (again, because IRQ not cleared)
interrupt chain handling: go through chains
device "1" says "it's mine" although it isn't
leave interrupt chain handling
[device 2 server does not get called]

[... forever ...]

Device 1 in this example would not notice anything. For it everything would continue to work normally.

@Georg

Yes, but like I said, the audio drivers do this correctly and AFAIK, the eth3com device has been checked for this long time ago as well.

Last edited by DaveAE on 06-Jul-2005 at 03:00 PM.

_________________
Audio Evolution
http://www.audio-evolution.com

@DaveAE

Ok, then one final random wild theory: from somewhere out there on the net:

"The situation is much simpler if all UARTs sharing the same interrupt are used by the same program. This program has to be aware of the sharing mechanism, but programs that can make use of more than one serial port (especially libraries) usually are. Now there's only one problem to be solved: lock-up situations. As I already wrote, the ICUs in the PC are programmed to use raising edge trigger mode, and you can't change this without crashing the system. Now consider the following situation. Two UARTs share one IRQ line. UART #1 raises the line because it needs service; the service routine is called and detects that UART #1 needs service. Before it can perform the serivce, UART #2 raises the IRQ, too. Now UART #1 is serviced, the line should go to the 'low' state but it doesn't because of the other UART keeping it high; the handler checks the next UART in its table and sees that UART #2 needs service, too. Now UART #1 receives another character and keeps the line high while UART #2 is being serviced. How should the handler know that this has happened? If it just issued EOI and returned, the IRQ line would never have gone 'low' during the service, so there won't be any future raising edges to be detected, and thus no more interrupts!

What does the service routine do to avoid lock-ups? It has to mask the interrupt in the ICU; this resets the edge detector. If it unmasks the interrupt again at the end of the handler and the line is still 'high', this will trigger the edge detector and the interrupt will be scheduled again. See the 'known problems' section for a very solid method of handling interrupts suggested by Richard Clayton"

They are talking about DOS and serial port programming. But the interrupt stuff should nevertheless be interesting.

Does AOS4 mask the irq in the 8259a before sending EOI (end of interrupt) and only unmask it again after the interrupt handling routine has been called?

@Georg

Interrupts are at 'level', not at edge. If two cards have their interrupt high, they keep it high until the IRQ handler sets it to low. No such problems as you/he describes happen. If you or someone else wants to test it: set the IRQ for the PCI card to another value in the U-boot menu. I'm not sure which one the ethernet controller uses though. Anyway, if what you say happens, it should happen to all of us, and real quick too.

That said, I'll see if I can find some time to reproduce it, but my time is very limited.

_________________
Audio Evolution
http://www.audio-evolution.com

@DaveAE
Quote:

The IRQ on the other card would remain high, so the interrupt chain would be called again until it's cleared.

Would this be broken if the Uboot settings were wrongly Edge instead of Level, or are those settings overridden when the OS takes over ?

Scott Woodall

[edit: too slow, missed your last post there]

Last edited by swoodall on 06-Jul-2005 at 07:20 PM.