18-Apr-2024 19:10 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 335 items in your selection (but only 135 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 335]
[Forum] Try only to realise the truthANN.lu
Posted on 04-Jul-2004 14:02 GMT by Truth335 comments
View flat
View list
There is no DMA in the AmigaOne. http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=5558&forum=13
Try only to realise the truth : Comment 201 of 335ANN.lu
Posted by Kolbjørn Barmen on 05-Jul-2004 22:49 GMT
In reply to Comment 191 (Amon_Re):
For USB Audio read http://www.usb.org/developers/devclass_docs/audio10.pdf
Short quote "..all devices that are to manipulate audio, voice and sound related functionality. This includes both audio data (digital and analogue) and the functionality that is used to directly control the audio environment, such as volume and tone control.... handling of MIDI streams over the USB is directly relate to audio and thus covered in this document."

So the question is: can you do sound work with the pegasos with that so called "full USB support"? I think not. And again, no discredit intended. For equipment that uses USB-Audio, visit your neared music instrument shop, or search on google.
Try only to realise the truth : Comment 202 of 335ANN.lu
Posted by Anonymous on 06-Jul-2004 00:11 GMT
In reply to Comment 201 (Kolbjørn Barmen):
with the pegasos? Sure why not. With Morph OS? Hmm obviously no...
Try only to realise the truth : Comment 203 of 335ANN.lu
Posted by Joe "Floid" Kanowitz on 06-Jul-2004 02:17 GMT
In reply to Comment 202 (Anonymous):
with the pegasos? Sure why not. With Morph OS? Hmm obviously no...

So you're saying the Pegasos has *software* USB?! ;)
Try only to realise the truth : Comment 204 of 335ANN.lu
Posted by Anonymous on 06-Jul-2004 02:31 GMT
In reply to Comment 201 (Kolbjørn Barmen):
I think you and chris didn't speak about the same things...

You're talking about audio control over USB (control sound
amplificator from computer) and chris is talking about USB sound
cards, which isn't really the same thing...
Try only to realise the truth : Comment 205 of 335ANN.lu
Posted by priest on 06-Jul-2004 03:18 GMT
In reply to Comment 174 (itix):
>>"I agree that it would be nice to mention (even though it's a AmigaOS HW) that DMA does not work 100% on Linux."
>I never tried Linux, but aint there Linux for old classic Amiga? How DMA works there with SCSI controllers?

I do not have any experience of that. But I presume DMA works there. Doesn't it?
Try only to realise the truth : Comment 206 of 335ANN.lu
Posted by Amon_Re on 06-Jul-2004 04:01 GMT
In reply to Comment 194 (Johan Rönnblom):
It's broken when there's hardware fault. Example given, when you have a harddrive that no longer spindles, or one that'll die if you use it for more then 8 hours (IBM Deathstars for instance). Requiring a different approuch to getting it to work properly isn't being broken, by your definition all my hardware would be broken.
Mu ATI Rage128 card, because 3D accell doesn't work on it in linux, my powerbook 1400 because my PCMCIA slots don't work in linuxPPC, etc etc etc etc ad infinitum.
Try only to realise the truth : Comment 207 of 335ANN.lu
Posted by priest on 06-Jul-2004 04:29 GMT
a problem/bug the for multiOS HW platform:
"The CPU interface fails to make all needed PCI to Memory transactions transparent to the CPU."

a feature for the singleOS HW platform:
"This "so called "problem is the direct result of the Articia S's ability to handle memory access by the CPU and PCI bus. "

;-)
Try only to realise the truth : Comment 208 of 335ANN.lu
Posted by RealTruth on 06-Jul-2004 04:37 GMT
The real truth is that the DMA doesn't work correctly on the AmigaOne, no matter which OS is used and which "workaround" is used, it doesn't work correctly (i.e: as it should work in a desktop computer). This is now a proven fact (no no I won't caste my time posting URLs that have already been posted on these thread and before).

ANYBODY SAYING THE CONTRARY IS A LIAR AND IS WRONG.
Try only to realise the truth : Comment 209 of 335ANN.lu
Posted by James Carroll on 06-Jul-2004 04:48 GMT
In reply to Comment 208 (RealTruth):
yeah its good you can put a real name to that opinion.. very brave.
Try only to realise the truth : Comment 210 of 335ANN.lu
Posted by Menthos on 06-Jul-2004 04:54 GMT
In reply to Comment 196 (Johan Rönnblom):
Hehe, this is funny!

[irony mode on]
Pegasos2 is broken! We just haven't found the bug just yet! ;)
[irony mode off]
Try only to realise the truth : Comment 211 of 335ANN.lu
Posted by Amon_Re on 06-Jul-2004 05:02 GMT
In reply to Comment 208 (RealTruth):
The reason you won't post urls is because they prove neighter point.
Try only to realise the truth : Comment 212 of 335ANN.lu
Posted by priest on 06-Jul-2004 05:23 GMT
In reply to Comment 196 (Johan Rönnblom):
Care to specify a satisfying test case then?

Genesi test case for Teron HW is not applicable for AOS on A1:

1) Create a Linux partition with reiserfs using the IDE channel
NOT APPLICABLE: reiserfs is not AOS4 filesystem
2) Create a Linux partition with reiserfs using a 1394 (firewire) drive
NOT APPLICABLE: no firewire in A1
3) Create any Linux partition (any device possible)
NOT APPLICABLE: no Linux partitions supported on AOS4
4) Enable DMA for IDE using 'hdparm'
NOT APPLICABLE: no hdparm for AOS4
5) Copy some data ~1-2GB using 1) and 2)
NOT APPLICABLE: see steps 1-4
6) unmount 1)+2)
NOT APPLICABLE: see steps 1-4
7) run the 'reiserfsck' tool using an endless shell script for 1)+2)
NOT APPLICABLE: no reiserfsck for AOS4, see steps 1-4
8) Start a ftp of a huge file (>memory+swap) using 3) and calculate a checksum for that file using a endless shell script
NOT APPLICABLE: see previous steps
Try only to realise the truth : Comment 213 of 335ANN.lu
Posted by Anonymous on 06-Jul-2004 05:25 GMT
In reply to Comment 206 (Amon_Re):
This is just groundwork, in a few days there will be announcement of a new production run of Peg2s from b-plan.
Try only to realise the truth : Comment 214 of 335ANN.lu
Posted by priest on 06-Jul-2004 05:38 GMT
In reply to Comment 208 (RealTruth):
"it doesn't work correctly (i.e: as it should work in a desktop computer)."

So, after the desktop computer DMA has been invented and once implemented, there is no room for improvements. Next you will say that Windows is perfect and the rest of the world does not work correctly bevcause it does not work as desktop computers should.

If the A1 DMA is renamed to AOS4DMA (AmigaDirectMemoryAccess), would it satisfy you?

REALLY. Define how the DMA should work in a desktop computer and why.
Try only to realise the truth : Comment 215 of 335ANN.lu
Posted by Amon_Re on 06-Jul-2004 05:51 GMT
In reply to Comment 213 (Anonymous):
And that has what todo with what i wrote?
Right, nothing, zip, nada :P

I fail to see the connection with my PowerBook 1400 not supporting linuxPPC properly & a production run of peg2's
Try only to realise the truth : Comment 216 of 335ANN.lu
Posted by Anonymous on 06-Jul-2004 06:05 GMT
In reply to Comment 201 (Kolbjørn Barmen):
>so the question is: can you do sound work with the pegasos with that so called >"full USB support"? I think not.

"Yes".
Linux has a so called "full USB support": Audio, ethernet ...
However some "custom" devices driver like WebCam or scanner could be missing.

MorphOS is missing Audio and ethernet USB class, but as Chris said who cares about that when you have on board a 100 Mbit + 1Gb ethernet ??? and also an on board AC97 chip.
I agree that the sound quality on this chip is not really the best I have ever heard (it's a cheap PC sound chip...), but then just buy a cheap SB Live...

Well, in conclusion about this subjet I would say:
Pegasos *has* full USB support including Audio, Ethernet, EHCI...
MorphOS lacks some, but only EHCI is a big annoying.

Bye
Try only to realise the truth : Comment 217 of 335ANN.lu
Posted by James Carroll on 06-Jul-2004 06:37 GMT
In reply to Comment 216 (Anonymous):
The only people who care whats lacking or not working properly in either amigaones or pegasoses are people who want to shit stir.. they all need to fuck off.
Try only to realise the truth : Comment 218 of 335ANN.lu
Posted by Chris Hodges on 06-Jul-2004 06:47 GMT
In reply to Comment 204 (Anonymous):
> I think you and chris didn't speak about the same things...
>
> You're talking about audio control over USB (control sound
> amplificator from computer) and chris is talking about USB sound
> cards, which isn't really the same thing...

If you are right and this is just a misunderstanding, the former (controlling your speaker/amplifier settings etc. over USB) is already supported (HID class), whereas the latter (USB D->A soundcards) is not.
Try only to realise the truth : Comment 219 of 335ANN.lu
Posted by Kolbjørn Barmen on 06-Jul-2004 07:02 GMT
In reply to Comment 216 (Anonymous):
The AC97 chip will help you squat if you want to interact with other external sound devices through USB. Pardon my mistake to not include MorphOS in my previous post - the when I said Pegasos, I meant Pegasos&MorphOS, as in the original comment (which was about Pegasos with MorphOS booting in 7-8 seconds with "full USB support"). And no, the Pegasos doesnt come with EHCI-controller buildt in, you would have to buy a PCI card. But hey, dont get all upset about this, I just thought "full USB support" was not quite correct.
Try only to realise the truth : Comment 220 of 335ANN.lu
Posted by hooligan/dcs on 06-Jul-2004 07:17 GMT
OOOOOOOOOOOOOOOOOOOOOOOOMMMMMMMMMMMMMMMGGGGGGGGGGGGGGGGG!!!!!!!!!

MorphOS doesn't boot with floppy support either :(((((((((
Try only to realise the truth : Comment 221 of 335ANN.lu
Posted by Amon_Re on 06-Jul-2004 08:00 GMT
In reply to Comment 220 (hooligan/dcs):
Floppy? What's that? :P
Try only to realise the truth : Comment 222 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 08:40 GMT
In reply to Comment 198 (Sammy Nordström):
Sammy wrote:
> Johan wrote:
>> So how do you know it works perfectly?
> Because he has not been able to reproduce the so-called bug that
> everyone claims to be so easy to reproduce?


Well, I haven't been able to reproduce the artificial element
einsteinium either. Does that mean einsteinium doesn't exist? No. Even
if I was the world's most reknowned nuclear physicist, and I failed to
reproduce einsteinium, this would not be a strong argument that it
doesn't exist. Many independent tests have shown that it does exist -
and no one has been able to present any evidence that it doesn't.

However, the analogy doesn't hold, because it would be very hard to
prove that einsteinium does *not* exist. It's however very easy to
prove that DMA hardware on the A1 is not broken - just give us some
working DMA to test.
Try only to realise the truth : Comment 223 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 08:46 GMT
In reply to Comment 206 (Amon_Re):
Amon_Re wrote:
> It's broken when there's hardware fault.

Yes. But what criteria do you think are sufficient for claiming that
there is hardware fault?

Is it ok to say that the april-less Peg1 is broken? Is it ok to say
that the A3000 without newer buster revision is broken? Is it ok to
say that the Pentium Pro was broken (math bug)?
Try only to realise the truth : Comment 224 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 08:48 GMT
In reply to Comment 212 (priest):
priest: As far as I know, there are satisfying test cases
demonstrating the A1 hardware to be broken, for every available DMA
implementation for the A1.

For implementations that are not available, how could I possibly come
up with a test? You're not being very reasonable here, are you?
Try only to realise the truth : Comment 225 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 09:04 GMT
Now let me just summarise the arguments for and against the
proposition that the A1 is broken:

Arguments for:
- For every available DMA implementation on the A1, it has been
demonstrated how to reproduce the error.

- The makers themselves, MAI, have removed DMA from the specifications
for the ArticiaS.

- All known third parties, which are not MAI or heavily dependent upon
MAI products, acknowledge that the ArticiaS is broken. There is
currently no known hardware implementation that uses the ArticiaS,
except MAI's own.

- Identical software (Linux) running on the A1 and on the very similar
Pegasos 1, work when a hardware fix (April) is applied to the
Pegasos 1, but not when it isn't.

- After several years, there is still no working DMA drivers for Linux
on the A1. Claims that Linux is uninteresting are not believable, as
all parties involved (Hyperion, Eyetech and MAI) have repeatedly
stated that the main commercial avenue for the A1 is with Linux.


Arguments against:
- There supposedly exists a DMA implementation that works. However, it
is not available for public scrutiny. The people claiming this
implementation works are the same who first claimed that the bug
did not exist, then claimed that the bug existed but wasn't related to
the ArticiaS.

- There are a number of people using said implementation who have not
noticed any problems. However, it has never been claimed that the
problems are necessarily immediately obvious.

- It is claimed that there is an "anomaly" in the ArticiaS, but that
it's not a bug, and that it can be worked around in software. However,
these claims come from the same people who denied that there was a
problem in the first place, and they have been unable to produce a
working solution available for public scrutiny, more than 18 months
after the problem was demonstrated.
Try only to realise the truth : Comment 226 of 335ANN.lu
Posted by Chris Hodges on 06-Jul-2004 09:30 GMT
In reply to Comment 225 (Johan Rönnblom):
I really don't know what people are arguing about. This is my personal view (!) based on my technical knowledge:

During DMA transfers, the ArticiaS does not flag accessed memory as "dirty", therefore the CPU does not automatically know, that it has to update/flush its caches (and Kjetil, the MMU and its associated tables keep track of which pages are cachable and which are not). This is no problem for AmigaOS, given that the old hardware did not support automatic cache invalidation. Hence, CachePreDMA()/CachePostDMA() were introduced for Kickstart2.0, when it was obvious, that DMA capable components would need a mechanism to invalidate certain cachelines in the CPU manually. If all drivers are written with this manual software cache coherence in mind, this is no problem. Therefore I do not assume a problem for AmigaOS4, as this CachePreDMA()/CachePostDMA() should still work as proposed.

This is, however, a problem for other operating systems (such as Linux?), which rely on automatic hardware cache line invalidation/flushing for DMA accessed memory. If the operating system does not allow such fine-granular cache flushing, the whole cache has to be flushed. This bad for L1 cache, but is a heavy speed penalty for L2/L3 caches (remember, they're *big*). Still, working drivers would be possible. If the driver runs in user-space and the OS does not provide cache control at all: game over.

As the hardware DMA support is assumed for most systems, hardly anybody will care for such manual cache consistency in their drivers. So although this might be possible to fix for Linux, I don't think every driver will be checked for necessary CachePreDMA and CachePostDMA calls.

Even if one would not call the ArticiaS bugged related to DMA, it is clearly a missing feature for transparent DMA operations.
Try only to realise the truth : Comment 227 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 09:39 GMT
In reply to Comment 226 (Chris Hodges):
Chris: Well, the problem can be "solved" in Linux too, either by
turning of caches or running a version of Linux that doesn't require
cache coherency. The former method gives an extreme speed penalty of
course, the latter also gives a speed penalty, and probably means that
many drivers won't be available.

To "solve" it in OS4 is really no different. It can be done, but with
a significant performance penalty. Let me quote the old RKM:s for
CachePreDMA:
"[..]
With a Bus-Snooping CPU, this function may end up doing nothing.
[..]"

Which is exactly what you want for modern hardware, for performance
reasons.
Try only to realise the truth : Comment 228 of 335ANN.lu
Posted by Kolbjørn Barmen on 06-Jul-2004 09:41 GMT
In reply to Comment 220 (hooligan/dcs):
Sure it does.. There are USB floppy drives, I am sure they work with Pegasos :)
Try only to realise the truth : Comment 229 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 09:41 GMT
Oh - and let me add that I also suspect there may be hardware out
there that relies on the bus snooping features, where this deficiency
cannot be worked around in software at all. But I'm no expert here and
maybe someone could fill me in on that.
Try only to realise the truth : Comment 230 of 335ANN.lu
Posted by Ferry on 06-Jul-2004 09:42 GMT
In reply to Comment 225 (Johan Rönnblom):
" Arguments against:
- There supposedly exists a DMA implementation that works. However, it
is not available for public scrutiny. The people claiming this
implementation works are the same who first claimed that the bug
did not exist, then claimed that the bug existed but wasn't related to
the ArticiaS.

- There are a number of people using said implementation who have not
noticed any problems. However, it has never been claimed that the
problems are necessarily immediately obvious.

- It is claimed that there is an "anomaly" in the ArticiaS, but that
it's not a bug, and that it can be worked around in software. However,
these claims come from the same people who denied that there was a
problem in the first place, and they have been unable to produce a
working solution available for public scrutiny, more than 18 months
after the problem was demonstrated."

So your "arguments againts" are in fact doubts about the credibility of the people who says they have no problems with DMA... Hmmm... Well, if that's the case I guess you will not touch a Pegasos not even with a barg pole... Look, I'm not saying it's a bad board at all, but if you just care about credibility of some people related to it, you should be carefull then.

Saluditos,

Ferrán.
Try only to realise the truth : Comment 231 of 335ANN.lu
Posted by Kolbjørn Barmen on 06-Jul-2004 09:53 GMT
In reply to Comment 218 (Chris Hodges):
If I read correctly, there are three subclasses of the USB Audio Interface Class:

* AudioControl Interface Subclass
* AudioStreaming Interface Subclass
* MIDIStreaming Interface Subclass

Assuming that AudioControl is done through HID class, and AudioStreaming is useless sine everyone would be using the soundcard instead (huh, tell that to the USB phone headset), what about MIDI?
Try only to realise the truth : Comment 232 of 335ANN.lu
Posted by Sammy Nordström on 06-Jul-2004 09:59 GMT
In reply to Comment 222 (Johan Rönnblom):
You really don't get it, do you? You claim that there is a fault in the hardware, people ask for proof, then you counter by saying things like "not beeing able to prove it's existence doesn't mean that it doesn't exist"? For christ sake, Johan. I don't argue that things can still be true even if it can't be proved, but you can't just walk around making claims without being able to prove it! Even if what you say is true, you still need to prove it in order for it to not be speculations and without the shadow of a doubt. Spreading these speculations and putting your own personal spin on certain facts for the sake of making your theory more "credible" just makes your agenda embarrassingly obvious. When you at the same time hide behind some kind of "Sverker" suit and proclaim yourself as a hero that is providing the consumers of the Amiga community with a service, I find no better word than "hypocrite".

I'll be glad to eat my words the day you have solid evidence. Until then, please stop this FUD mungoring. The Amiga market is doing bad enough without it.
Try only to realise the truth : Comment 233 of 335ANN.lu
Posted by Ferry on 06-Jul-2004 10:04 GMT
In reply to Comment 226 (Chris Hodges):
Thank you for your explanation, Chris, I thinks yours is the only post in this thread with some sense... :¬/

So, if I understand it correctly, if the OS implements in software this fine-granular cache flushing, the speed penalty would be small, or even very small, wouldn't it?

Also, AFAIU, Linux supports either DMA with hardware cache flushing or no DMA at all, is this correct? In that case, I guess it would be possible to write a software driver to handle this lack, wouldn't it? Thanks in advance for your answers.

Saluditos,

Ferrán.
Try only to realise the truth : Comment 234 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 10:06 GMT
In reply to Comment 232 (Sammy Nordström):
Sammy, what would you consider as evidence, then? Obviously, methods
to reproduce the but for every available implementation is not enough.
What would be enough?



Ferrán: I'm not appealing to the credibility of any Pegasos-related
people. However, the *only* arguments supporting the theory that the
ArticiaS is *not* bugged, rely *entirely* upon the credibility of some
people. This of course already makes those arguments very weak. But
seeing that these people are in fact not credible at all, when it
comes to this issue, weakens the "no bug" case even more.
Try only to realise the truth : Comment 235 of 335ANN.lu
Posted by Johan Rönnblom on 06-Jul-2004 10:11 GMT
In reply to Comment 233 (Ferry):
Ferran, it's possible to do the exact same in Linux. This is what Ben
Herrenschmidt says about this possibility:

http://lists.debian.org/debian-powerpc/2004/06/msg00430.html
"[..]
Ok, so Linux do support non-coherent DMA quite well, it's atcueally
widely used by various sorts of embedded CPUs like 4xx, 8xx, ...

_HOWEVER_, doing that in a northbridge for anything but an embedded
CPU, especially a CPU of the 6xx/7xxx family is just insane. It's
basically incompetent northbridge design.
[..]"
Try only to realise the truth : Comment 236 of 335ANN.lu
Posted by Sammy Nordström on 06-Jul-2004 10:36 GMT
In reply to Comment 234 (Johan Rönnblom):
>Sammy, what would you consider as evidence, then?

Indisputable facts. It's really as simple as that. So far, noone has provided us with indisputable facts, all we've seen so far is *disputable* facts (otherwise we wouldn't have threads like these, now would we?). Don't ask me how this would be accomplished, you're the one making accusations and therefore you are the one with the burden of proof.
Try only to realise the truth : Comment 237 of 335ANN.lu
Posted by Nate Downes on 06-Jul-2004 10:42 GMT
In reply to Comment 226 (Chris Hodges):
You know, this is the best explination I've seen in awhile.

I might add that the reason why the AmigaOS required this "software-flag" for the classic hardware is that the classic hardware had no concept of a northbridge, there was no mannerism for DMA transfer included with any hardware back in that day, so the Hi Torro guys made their own. But times have changed, there is now a hardware-flag for PCI DMA transfers.

Ironically, it is the fact that AmigaOS's core has not had an update since 1994 that allows it to work in such an environment.
Try only to realise the truth : Comment 238 of 335ANN.lu
Posted by Ferry on 06-Jul-2004 10:46 GMT
In reply to Comment 234 (Johan Rönnblom):
"However, the *only* arguments supporting the theory that the
ArticiaS is *not* bugged, rely *entirely* upon the credibility of some
people. This of course already makes those arguments very weak."

Some of my hobbies are related to Science, and in scientific method the charge of the proof is always up to the person who states something, i.e. if you states 'einstenium' exist, you MUST provide proofs. If proofs are not provided, it can be a theory or even just a personal opinion, but NOT a fact.

If you provide proofs that Linux can't do DMA, and independent test can be done to verify it, well, that's a fact (of course, it will remain open to further theories and tests that could change the results - that's the way Science works)

If you present a theory in which DMA does not work neither in OS4 (or, in other words, the board is damaged) and you provide the way to do the test to check it, if independent tests are getting different results, this is called a discrepancy, and your theory is not valid in its curent form, it should be either refined, redefined or even discarded. Of course, one can doubt of the tests done, but then one should tell why based in real reasons: the test has been done in a bad way, or not respecting the way it should be done, etc.

For example, you prefer to think that Articia is faulty, and I could think that bPlan engineers did prefer to do, whatever the reason, a "hardware driver" (followinfg Chris explanation) instead of a "software driver" to solve the same issue that OS4 programmers are doing by soft. But those would be only opinions, and they don't give any info about the real "health" of the Articia chip.

So I think you'll agree you cannot base what you call 'facts' only in opinions or theories. You, me, whoever must base facts in real and contrasted tests.

Saluditos,

Ferrán.
Try only to realise the truth : Comment 239 of 335ANN.lu
Posted by Chris Hodges on 06-Jul-2004 11:13 GMT
In reply to Comment 231 (Kolbjørn Barmen):
> Assuming that AudioControl is done through HID class, and AudioStreaming is
> useless since everyone would be using the soundcard instead (huh, tell that to
> the USB phone headset), what about MIDI?

Well, as soon as somebody donates me an USB keyboard, there will be a driver for it short after. Unfortunately, these USB keyboards rather expensive, and for that reason I did not buy one myself yet.
Try only to realise the truth : Comment 240 of 335ANN.lu
Posted by Ferry on 06-Jul-2004 11:15 GMT
In reply to Comment 235 (Johan Rönnblom):
"Ferran, it's possible to do the exact same in Linux."

If I understood Chris explanation correctly, where he says the ArticiaS does not flag accessed memory as "dirty", therefore the CPU does not automatically know, that it has to update/flush its caches, Linux expects Articia to change that flag, but Articia doesn't do, so DMA transfers fail. I'm not an expert, but it seems not a case of 'non-coherent DMA' as Ben
Herrenschmidt says, it seems that Linux drivers are simply not "synced" with Articia specs. To make it work, this "software flag switch" should be implemented for when Linux detects it's running in a Articia equipped board. Does it worth the effort? I don't know, but that's another question...

As for OS4, and as Chris says If all drivers are written with this manual software cache coherence in mind, this is no problem, and that's precisely the way it is being done, AFAIK.

Saluditos,

Ferrán.
Try only to realise the truth : Comment 241 of 335ANN.lu
Posted by Chris Hodges on 06-Jul-2004 11:22 GMT
In reply to Comment 233 (Ferry):
> So, if I understand it correctly, if the OS implements in software this
> fine-granular cache flushing, the speed penalty would be small, or even
> very small, wouldn't it?

Assuming that the operation to find and flush the right pages in memory is performed quickly (i.e. hardware supported), this should not be much overhead. However, there might be some other timing critical things. I would think that with "hardware DMA" (a silly term), the northbridge would invalidate/flush the lines as DMA happens. With CachePre/PostDMA, this would occur as one big operation -- if the buffers are large, this could take some time (bad for realtime behaviour).

> Also, AFAIU, Linux supports either DMA with hardware cache flushing or
> no DMA at all, is this correct?

I'm not a Linux expert, but I don't see a reason why this "software DMA" could not be applied (so all three mechanisms should be possible).

> In that case, I guess it would be possible to write a software driver to
> handle this lack, wouldn't it?

You have to take care of this in each driver doing DMA, such as audio, usb, 100mbit network, TV card etc.. But yes, I guess it would.
Try only to realise the truth : Comment 242 of 335ANN.lu
Posted by Chris Hodges on 06-Jul-2004 11:30 GMT
In reply to Comment 237 (Nate Downes):
> I might add that the reason why the AmigaOS required this "software-flag"
> for the classic hardware is that the classic hardware had no concept of
> a northbridge,

Actually, I would consider Buster/Agnus/Alice similar to a northbridge (in parts).

> there was no mannerism for DMA transfer included with any
> hardware back in that day, so the Hi Torro guys made their own. But times
> have changed, there is now a hardware-flag for PCI DMA transfers.

Both Zorro2 and Zorro3 support DMA transfers, unfortunately, the MC680xx before MC68060 (AFAIK) did not have bus snooping.

> Ironically, it is the fact that AmigaOS's core has not had an update
> since 1994 that allows it to work in such an environment.

The update, that allows working in this environment was added with Kick2.0 and CachePre/PostDMA. It was a no-issue before, because chipram was non-cachable by default and only later, CPUs with bigger caches and no snooping for the custom chip stuff and dma bus transfers were added.

So even if CachePre/PostDMA is a NOP under MorphOS, it be required to work for AmigaOS4 drivers.
Try only to realise the truth : Comment 243 of 335ANN.lu
Posted by Chris Hodges on 06-Jul-2004 11:40 GMT
In reply to Comment 240 (Ferry):
Just to avoid some misunderstandings, here's the DMA issue as I understand it:

Case 1:
Assume you want to read a block from disk to memory. With non-coherent cache, the following could happen: DMA transfers the data to memory. Now the CPU tries to read from that space and already has some bits (or all of it) in its cache! But the CPU does not know that the cached data is now invalid and has benn replaced by some new data. Therefore, the CPU will use the cached, possibly old data and not the freshly read disk block.

Case 2:
Assume you want to write a block from memory to disk. Without cache coherency, DMA will start to transfer the data to disk, without knowing, if the memory has been updated with the correct data. The CPU still might have some data in its caches (usually, the data has been worked on recently, so the CPU has kept it in the cache), because it might be configured to Copyback (not Writethrough) and the memory still contains some of the old, unmodified data. The block on the disk therefore will contain old, possibly corrupt data after the DMA operation.

CachePre/PostDMA informs the CPU to flush the caches after the DMA operation (case 1) or mark the cached lines as dirty (case 2).

With bussnooping DMA cache coherency, this is not needed, as the CPU will be informed about it on the fly.
Try only to realise the truth : Comment 244 of 335ANN.lu
Posted by Amon_Re on 06-Jul-2004 12:28 GMT
In reply to Comment 225 (Johan Rönnblom):
I give up, you're a broken record, i'll get back at you when the AOS DMA drivers are public
Try only to realise the truth : Comment 245 of 335ANN.lu
Posted by Anonymous on 06-Jul-2004 12:44 GMT
In reply to Comment 225 (Johan Rönnblom):
>The makers themselves, MAI, have removed DMA from the specifications
for the ArticiaS.

Do you have some proof they claimed it had a DMA controller?
Old documents, website dumps, anything?
Try only to realise the truth : Comment 246 of 335ANN.lu
Posted by Anonymous on 06-Jul-2004 12:49 GMT
In reply to Comment 228 (Kolbjørn Barmen):
There are USB floppies, but it cannot boot from one, can it?
Try only to realise the truth : Comment 247 of 335ANN.lu
Posted by Bernie Meyer on 06-Jul-2004 13:12 GMT
In reply to Comment 243 (Chris Hodges):
There is a rather more subtle third scenario --- suppose you want to read a block from the hard drive, and some of the area covered is already in the cache[s], and is dirty (i.e. modified).You start the transfer, the new data ends up in main memory. Meanwhile, the CPU does something else, needs to reuse a cache line, and writes back the dirty one... right on top of the new data which was recently DMA'ed into memory, corrupting it :(So when reading, not only do you need to invalidate all caches covering the area *after* the DMA, but also *before* you initiate the DMA. And strictly speaking, you need to make sure that they stay invalidated during the whole period of the transfer (which is where fine-grained MMU tables for non-cachable areas come in handy --- although they typically work on page-sized memory areas, which is *not* the granularity with which you want to disable caching in your data segment. You can use bounce buffers, but that adds a whole lot of overhead and cache performance issues...)Also, remember that we are not talking about "a cache" here. Modern computers have cache hierarchies; Unless I am mistaken, the G3 as used in the A1 has both L1 and L2 cache, with the L1 cache being Harvard architecture (dedicated data and program caches), whereas the L2 cache is unified. It has been too long since I read the PowerPC architecture manual, but I am not 100% certain whether the CPU has complete control over the validity of L2 cachelines.Let's put it this way --- unless and until some independent third party with a very technical background and a firm grasp of the issues involved has performed a range of hand-tailored stress tests, any claims of "no problem" should certainly be treated with caution.
Try only to realise the truth : Comment 248 of 335ANN.lu
Posted by Bernie Meyer on 06-Jul-2004 13:31 GMT
In reply to Comment 247 (Bernie Meyer):
And just before someone points out that writing into your DMA memory during the transfer results in undefined behaviour, anyway, here is a scenario in which pre- and post-DMA invalidating of cachelines is not sufficient to avoid inconsistent behaviour:Scenario A: DMA the data "abcd" into memory range ABCD, in that order. While that transfer is in progress, CPU wites first to "x" C, then to "y" B. Possible outcomes with coherency: "abcd" (if the writes precede the actual DMA), "aycd" (if the write of "x" precedes DMA to C, but the write of "y" comes after the DMA to B), "ayxd" (if both writes happen after the DMA has been done for B and C).Now, if the cache gets explicitly invalidated prior to DMA as well as after the DMA, there is a chance that during the time DMA is done for D, none, one, or both of the CPU-written areas B and C are write-backed from cache to memory. And the problem occurs when C does get written back, but B doesn't. You then end up with "abxd", which is not possible in a properly coherent system.Worse yet, you can run into the same kind of problem without having the CPU write. Scenario B: DMA the data "abcd" into the memory range ABCD, which previously held "wxyz". While the transfer is going, have the CPU execute alternate reads from B and C. In a cache-coherent system, as soon as you have read "c" from C, you will *never* read "x" from B, because the fact that C has been updated implies that B has been updated.In a non-cache-coherent system, however, in which you invalidate caches at the start and the end of DMA, the CPU accesses will pull both B and C into the CPU cache. If at any time the cacheline for C is flushed, while the cacheline for B isn't, you can end up reading "c" from C yet afterwards still read "x" from B.Once again, you *can* get around these issues by using bounce buffers (dedicated temporary memory into which DMA is done, and from which the CPU then copies the data into its ultimate destination) --- but pumping each byte of "DMA'ed" data through the CPU, even memory-to-memory, is hardly the point of DMA.
Try only to realise the truth : Comment 249 of 335ANN.lu
Posted by Fabio Alemagna on 06-Jul-2004 13:46 GMT
In reply to Comment 240 (Ferry):
> If I understood Chris explanation correctly, where he says the ArticiaS does not
> flag accessed memory as "dirty", therefore the CPU does not automatically know,
> that it has to update/flush its caches, Linux expects Articia to change that
> flag, but Articia doesn't do, so DMA transfers fail. I'm not an expert, but it
> seems not a case of 'non-coherent DMA' as Ben Herrenschmidt says, it seems that
> Linux drivers are simply not "synced" with Articia specs

What do you think "cache coherency means"? It means precisely that the CPU's cache is always coherent with what is going on on the various buses and in the main memory. That is, the cache does _never_ have to make it appear as if something is there which is not anymore.

As Mr. Herrenschmidt put it, it's basically an "incompetent northbridge design".
Try only to realise the truth : Comment 250 of 335ANN.lu
Posted by Emeric SH on 06-Jul-2004 13:53 GMT
In reply to Comment 244 (Amon_Re):
"I give up, you're a broken record, i'll get back at you when the AOS DMA drivers are public"

At least this broken record seems to make the only sense, and remained a firm standpoint, while the opposition (your stance included) was pushed close to it to the extreme, from the complete denial of the beginning, the new revision fixed all problems, the VIA bug, then again complete denial, and now blaming it on the Linux drivers, which expected a fully functional northbridge without funky "features"...

The curious thing is, the "broken record" party come forth with a fix immediately, then after discovering new bugs with a fix of the fix, then admitted, that they cannot fix it, and it's broken. On the other side we have so far what... We don't know. Words? A great accomplishment of these long-long years since we live with ArticiaS.
Anonymous, there are 335 items in your selection (but only 135 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 335]
Back to Top