>We are talking about M$, remember? Zero sense is their
>business model.
Zero sense is your trademark, not MS'. MS business model is reaping in tons of profits, and doing a silly cpu id string check for any other reason as to display a warning, doesn't fit into this model.
> As I said, kernel dependancy upon IOMMU is the likely
>problem, whether that IOMMU implementation be hardware or
>software makes no difference.
It sure as hell makes a difference! If you do it in software, you ingore the hardware support for it (possibly at the cost of performance). Besides, as you pointed out yourselve, this only matters when a PCI(E/X) card tries to access memory beyond 4 GB <b>ram </b>, so there is no reason those linux distro's wouldn't boot with 4 GB or less that I can see, if IOMMU would be the only reason. OTOH, the erratta I pointed out seems extremely likely to crash any OS that has not yet implemented a workaround, in fact, I can't see how the OS would work at all if it loads top down (like windows for sure, Linux perhaps) and expects to be able to use 40bit addresses. Seriously, how could it ??
I don't know why you refuse to accept this possibility and its likelyhood, just arguing to argue ? Or simply because you like to make a fool out of yourselve ? Your thesis is MS did something extremely stupid with no advantage whatsoever, and at the same time every (non patched) 64 bit Linux OS available would somehow crash on a feature they do not even require (if its done in software) and doesn't play a role with less than 4 GB of RAM ram. Neither seems likely, the second even seems impossible. The 36/40 bit errata OTOH, has every potential to crash any non patched OS just like we've witnessed. Which is more likely ??
>No, you never even so much as implied that it was ever
>anything else than an easily overcome minor issue that
>shouldn't have been capable of stuffing up every OS that
>has tried to run it. Not once did you try to give it even a
>>hint of more import than that
Thats right I didn't. Not loading beta OS's (windows) or requiring non tested/approved server OSs (linux) to issue a tiny patch to run in 64 bit mode, is not a big issue in my book. Perhaps you think it is though, and therefore don't want to accept reality ?
>Face it, if you can't even support your own arguments then
>how can you possible hope to refute mine? Just give up
>already.
What arguments ? Mine are only based on logic, while I have no idea what yours are based upon. Just a desire to "prove" me wrong on anything perhaps ?
>Could you get any more picky over semantics? Considering
>that no one in the world would believe that there is one
>and only one version of the beta, your argument is yet
>another example of the weakness in your debating skills.
No, its another example of your poor reading and/or posting skills, and your lack to see context. "the 64 bit windows beta" clearly relates to the existing beta, not some unreleased inhouse version still under NDA. If you meant otherwise, you should have mentioned it, otherwise expect a correction stating Nocona does not boot "THE 64 bit beta".
Besides, why don't you just reply stating you didn't mean "the" beta, but "some secret inhouse NDA beta" instead of blaming my "weakness in debating skills" for your poor choice of words ?
>In your effort to counter my point that the only Fortune
>500 companies that are testing Nocona's 64-bit capabilities
>are those doing software development or are OEMs, you
>provide me with a link stating that the Bank of New York is
>testing "a statistical trading algorithm"
Yeah, those fortune 500 companies run *software* on those machines, they do not test them to see if they work with inhouse developped PCI-X SCSI adaptors. Are you surprised ?
Lets look back at your exceptional debating skills: I claimed
I guess that is why all those fortune 500 companies are testing Nocona with 64 bit windows and Linux? Cause I tell you, they are.
To which you replied:
Do you even know how many ways you're wrong here? I bet you don't. I also bet that you don't have a single scrap of evidence
<font color=red>1) Except for software development companies and equipment manufacturers (OEMs) there is no one testing this <i> at all</i>.</font color=red> Most companies leave that up to the OEMs to handle.
Now tell me, is the Bank of NY a software development company perhaps ? If not, aren't they testing Nocona with 64 bit windows ? So pray tell me, in how many ways was I wrong again ?
You so much love to prove me wrong and making those 'stupid/silly/ignorant' claims while being wrong yourselve it gets, hmm. well, fascinating. Again reinforcing my feeling you don't want to argue for any other reason as arguing and "proving" me wrong.
>But it gets better than that, because this very article
>also states "During the operating system installation
>process, Windows checks to see whether or not it is being
>installed on an AMD system. If it is not, the software
>cannot be installed", thereby also defeating another of
>your arguments. Amazing!
What is amazing ? You quoted the MS PR guy that stated exactly what I claimed to be most likely slightly incorrect at the beginning of the thread. You can probably find that same quote 200 times on the web, doesn't make the slightest difference, I <b>KNOW</b> that is the official MS line, and I don't believe it for reasons I explained. For press release/article both stories pretty much ammount to the same thing, it doesnt matter wether its the errata, cpu id check or IOMMU issue, one just sounds a bit better than the other. If you are going to derive low level technical issues from blanket statementes like that, you'd better have your head checked anyway. BTW, from that same link:
Aside from a few discrepancies, the chips are largely compatible. But even if they use the same instruction set, the chips don't have to use the same method to tell the operating system what instructions are available, said Kevin Krewell, editor in chief of the Microprocessor Report.
Now, what does that relate to you think ? CPU ID check for the words "opteron" ? Thought not. Sounds like another nice way of saying Nocona <i>misreports</i> its abilities (like the 36/40 bit issue). Its different allright, intel's doesnt work like it should and if the OS doesnt take the erratum into account, it won't work, period.
>And to top off the help that you have given me the article
>also states "AMD also uses two instructions designed to
>improve Opteron's ability to quickly switch back and forth
>between applications. The additional instructions were
>added after AMD published its design papers that Intel used
>to create the architecture for the Nocona chip." which only
>goes back to support my argument with trooper11 that AMD
>could (and now we have proof that they in fact did)
>implement x86-64 differently from their own whitepapers,
>thereby creating x86-64 flavor incompatibilities
I never claimed anything else, why bring this up ?
>You're my hero, P4man! If everyone debated with me with the
>same skill (or lack thereof in your case) I'd never lose.
Win/lose.. lol. You can "win" all you want, you're still dead wrong on this one. But that is obviously not what matters to you, is it ?
>Why would I tell you something contradictory to that which
>I said in the first place over something which I did say in
>the first place? I said that for Linux it was requirement
>of IOMMU and I still stick to that.
Use google, look for Linux change logs, search for "software IOMMU", and you'll see hardware IOMMY is *not* a requirement for recent kernels.
>Remove IOMMU dependancy
>and then we'll see.
We have: BOOM, crash upon install.
>But your own link now gives me even another argument. If
>the kernel uses the instructions that AMD added to their
>CPU but left out of their whitepaper, then AMD created an
>x86-64 base incompatability which would crash the kernel.
What ? LMAO ! lets see, AMD adds some instructions, and that would crash the kernel ? Seriously, WTF are you smoking ? If anything, it *could* be possible that MS uses these instruction in windows (from what I've read, they don't actually) and since Intel didn't implement them, it could cause trouble (even though I highly doubt it would impact even the installation routine!). But lets assume this nevertheless, and think these instructions would be the real reason anyhow. You think this give you an additional argument LOL man, reread your own brabbeling, here is what you claimed:
<font color=red>The two x86-64 instruction sets are functionally identical enough that the initial 64-bit beta for Windows would run on Nocona. That wasn't the problem</font color=red>. The problem was that the installer was specifically written to check for an AMD chip before installing.
Here are how many ways that you are wrong: <...>
<font color=red>2) There is no incompatibility to work out.</font color=red> There is a lack of drivers on the M$ side, and an unnecessary dependancy on IOMMU support in the northbridge on the Linux side.
So now "evidence" that Nocona's implementation would NOT be as "functional identical" as you thought would <i>reinforce </i>your point ? ROFL!! Oh man..
>Right. So the use of 64-bit integers in 64-bit software
>doesn't use twice as much memory as using 32-bit integers.
></sarcasm hat> It's funny how every single time you try to
>counter me you have to twist words into something other
>than what I said. Did I say that hybrid software running in
>64-bit mode and using mostly 32-bit integers would increase
>the memory usage? No. So why then did you argue that
>instead of arguing what I actually said?
I argued <b>exactly</b> what you said. There is no need to state my arguments don't apply to claims you did indeed not make, when they fully apply to what you did claim. If you think you can confuse me that way to "win" an argument, you picked the wrong man.
The point still is your "1.5x the memory bandwith" claim just ain't gonna happen, ever, when running the same software in 64 bit mode as opposed to 32 bit mode. 64 bit INTs being twice as long matter zilch, and you "1.5x average" is probably an average of the times you are wrong when you claim anything, but relates to nothing in this discussion. Either that, or I have no idea what it refers to.
>No, I'm both debating and simultaneously pointing out your
>inability to do so. A wise person would take that advice
>and stop bothering while they learn how to debate.
>To put it bluntly, you suck at debating. Give it up and go
>help people or play softball or something. Surely you must
>be better at something you enjoy more than this?
Thanks, that comment just made me spit coffee all over my keyboard. You think you're a great debater because you make long posts, use strong words and insults, and refute any sensible point that is being made by stating the point doesn't apply to something you did not say. Go into politics, debate Kinney or something, but you're pretty pathetic in your attempts to prove your "skills" while making one factual error after the other logical one. Besides, you don't need great debating skills when you simply argue reason and facts, it take skill to prove an incorrect point, but you're so wrong on so many accounts, no ammount of skills is gonna help you. on the contrary, makes it all the more hilarious.
<edit> Added some colour, just in case "debating skills" is about being able to use colour, instead of making sense or using logic. I can even use <font color=green> green </font color=green>, wow, what a <b> great </b> debater I am ! Maybe I should also add some insults to display my complete superiority ? </edit>
= The views stated herein are my personal views, and not necessarily the views of my wife. =<P ID="edit"><FONT SIZE=-1><EM>Edited by P4man on 08/06/04 06:27 AM.</EM></FONT></P>
Facebook
Twitter
Instagram