Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's not "a single photo of a damaged chip" there are at least 4 different public examples that I've seen. Not that it changes the scale of the evidence much.

The fact that the vendors are acting so quickly about this suggests to me that they have other non-public examples of the problem (from warranty returns, etc.) and the hullabaloo led them to compare notes and determine the root cause rather quickly. Or maybe they're just over-reacting to defuse the mob but I don't think that's super likely.



> The fact that the vendors are acting so quickly about this suggests to me that they have other non-public examples of the problem

In this day and age, if a story is spreading from a small thread on a subreddit to a string of reactions here and there in quick succession, a maker can't just let it run without any statement, even if it was literally a single guy with an unrelated problem.

Getting out a "We're looking into it" statement as soon as possible is the least they can do to manage the PR situation in any sane way, whatever the actual scale of the problem is.


The catch-22 of the PR machine and pretending modern companies love you and are 'good.' Damned if you do, damned if you don't.


I am only aware of 2 examples, the one that was posted on reddit and is now apparently being shipped to GamersNexus, and Der8auer, who didn't even notice pad discoloration (so may not have even been caused by an overcurrent event).

I wouldn't bet their "fast" response is due to them internally already knowing, so much as the PR hit from getting to the top of the PC enthusiast forums on reddit. None of the statements so far even suggest they've reproduced anything wrong, leaving vague statements of investigating it or adding more limitations in case that was an issue.

I remember a while ago something similar happened when someone read a lot into a comment into the open source AMD GPU driver as the "Shader Prefetch" feature of their GPUs was broken and disabled. AMD ended up having to issue a statement saying it's enabled and working where it benefits performance - and that shot to the top of those same forums and people "demanded" an explanation, and that was just an internal detail of hardware performance, not even a user-visible feature. To this day some commenters think the performance is somehow hobbled by this, so there may be more pressure to get faster responses.

I personally work on GPU drivers, AMD GPU drivers, but not on windows. I actively avoid commenting on things I have personal knowledge of, so I don't accidently leak something, but also because I see so much /wrong/ stuff repeated on the internet. In fact, I would say the majority of the specifics that are "generally accepted" on those subreddits are wrong to the point of being misleading. And a couple of times I've tried to question things I knew were incorrect I was heavily downvoted and dogpiled, so I gave up.

So while I have no direct knowledge of anything related to the CPU and it's power management, I'm trying to avoid Gell-Mann amnesia on "facts" repeated in those same subreddits.

So my current position is there may be an issue here, it may even be related to the SoC voltage regulation currently being blamed, but the "evidence" so far could also be caused by a thousand other things.


> To this day some commenters think the performance is somehow hobbled by this

There will always be a sizeable subset of people who are utterly convinced that there is an evil cabal of developers who refuse to press the "go faster" button(s) out of personal malice.


Personal malice, no.

Profit, maybe...?


The four motherboard makers that have issued public press releases about revised firmware that is designed specifically to limit the SoC voltage to prevent failures would disagree with you here. If that isn't a public admission of this being the source of the failure, what is?


> The four motherboard makers that have issued public press releases about revised firmware that is designed specifically to limit the SoC voltage to prevent failures would disagree with you here.

What I'm seeing is four motherboard makers trying to win customers at the expense of ASUS by taking very public steps to state their product does not suffer from this issue unlike ASUS.


Four motherboard makers jumping on the FUD train isn't proof of anything.


AMD has now specified that the issue is SoC voltage in a follow up statement. https://www.tomshardware.com/news/amd-issues-follow-up-state...


In summary you're saying it's caused by GPU drivers.

/s


Why did AMDGPU drop support for Hawaii (eg 390) in newer kernel releases?


[flagged]


And I personally have an 8700k in my home machine.

I work in a large company, I'm not really involved with anything or anyone working on CPUs. I have no internal knowledge of anything in this area.

And I'm just pointing out how the statements of evidence presented here don't naturally lead to this conclusion as seem to be implied - not that this conclusion isn't correct, or some opinion about the quality of the hardware and software involved. I'm trying my best to not involve my opinion, and instead actually stick to the known facts. Which is my issue with this story as written.

I'm not sure if you're reading the same statements, but the ones I've seen explicitly don't admit fault.


> The fact that the vendors are acting so quickly about this suggests to me that they have other non-public examples of the problem (...)

That's quite the extrapolation. It's far more likely that AMD sees the exposure that a hand full of cases is having as a threat to the public's perception of the issues and is actively and very publicly addressing it to contain it.

So far all the reports I've seen about this issue was that it was really a problem with ASUS motherboards which were bricking the processor. The article seems to confirm it, and AMD seemed to have published a mitigation.


> Or maybe they're just over-reacting to defuse the mob but I don't think that's super likely.

I guess you don't believe in "innocent until proven guilty".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: