Core 2 Duo

I'm scared.

- A Thermal Interrupt is Not Generated when the Current Temperature is Invalid
- REP Store Instructions in a Specific Situation may cause the Processor to Hang
- Concurrent Multi-processor Writes to Non-dirty Page May Result in Unpredictable Behavior
- Cache Data Access Request from One Core Hitting a Modified Line in the L1 Data Cache of the Other Core May Cause Unpredictable System Behavior
- Invalid Instructions May Lead to Unexpected Behavior
- FXSAVE/FXRSTOR Instructions which Store to the End of the Segment and Cause a Wrap to a Misaligned Base Address (Alignment <= 0x10h) May Cause FPU Instruction or Operand Pointer Corruption
- Upper 32 Bits of the FPU Data (Operand) Pointer in the FXSAVE Memory Image May Be Unexpectedly All 1's after FXSAVE
- Writing Shared Unaligned Data that Crosses a Cache Line without Proper Semaphores or Barriers May Expose a Memory Ordering Issue

More info courtesy of Theo here: http://marc.info/?l=openbsd-misc&m=118296441702631

So are these the things that Microsoft et al. are scrambling to provide "fixes" for? Niiiiice.

Looks to me like another of those ultrasparc chips that were effectively unusable with the L2 cache switched on. (And horribly, horribly slow without.)

Only this doesn't affect the L2 cache, this affects the L1 cache, the MMU, and TLB, and the frigging FPU.

Hahaha oh wow. These are some serious enterprise exploits.

On the other hand, I've now been running a core 2 duo chip in my laptop for the last five weeks or so. No problems, except the shitty USB keyboard freaking out every now and then.

They should stop making workarounds, as that only encourages Intel to get more sloppy ("they'll find a way around it, so we don't have to make sure everything works correctly"). Boycott the chips.

First, the quality of software starts degrading (Vista etc.) and now the HARDWARE? Unbelievable.

THE 6502 SHALL RISE AGAIN

helo 2 u f00f

:)

>>7

Your rallying cry, tinged with a sense of tender nostalgia, gave me goose bumps all over and sent a happy shiver down my spine.

glad i'm an amdfag

Z80 > 6502 btw

oh wow, /prog really doesn't anything about programs OR cpus

OH EXPLOITABLE!

>>12
you must be new here

>>12
oh wow, Intel doesn't know anything about CPUs either:

Cache Data Access Request from One Core Hitting a Modified Line in the L1 Data Cache of the Other Core May Cause Unpredictable System Behavior

Concurrent Multi-processor Writes to Non-dirty Page May Result in Unpredictable Behavior

It's like they literally jammed two processors together and forgot to deal with the hazards.

arm > 6502 > z80

It's like they literally jammed two processors together and forgot to deal with the hazards.
or they jammed two processors together and figured they'd let microsoft worry about the hazards. why do it right when it's easier to do it wrong and let someone else absorb the cost of developing workarounds for your horribly broken shit?

>>1
Enjoy your 90 cycles for a CALL.

I meant >>11, sorry

>>17
Except that "someone else" is writing horribly broken shit too.

Don't worry guys we'll just fix it in the microcode amirite?

Meh. The MMU "bug" is just something about PTEs or other structures being fetched from the L2 cache, so they need to be flushed all the way to RAM for changes to take effect (since immediately after change, the changed version is only in the L1 cache). Not really a big deal, far as I can tell, since that behaviour has never been specified by the x86 MMU documentation; not that given by Intel anyhow.

The string primitive things could be more serious though.

>>22
that behaviour has never been specified by the x86 MMU documentation; not that given by Intel anyhow.
Yet you suppose caches should be transparent unless otherwise said.

>>23
The instruction cache isn't transparent.

Really, I'd only expect caches to be transparent in the common user-space case, i.e. not involving MMIO, DMA or dirtying of MMU structures.

SAGESAGESAGE

Don't change these.

Name:		Email:
Entire Thread Thread List