C dangerous?

[Michael Wojcik]

Sure, disk /access/ failure, scribbled on data, unable to boot from the
device etc. But to actually damage the disk electronics so that the BIOS
reports the disk as being nonexistent or defective? Thats pretty unlikely
IMHO.

I have no idea how likely it is, since I haven't seen any reliable
statistics on the subject. However, there's no need for "damage [to]
the disk electronics". If the controller can be put into a mode
where BIOS is unable to detect the drive, eg by writing the proper
value to a memory-mapped port, and that mode is reset by loss of
power but not by CPU reset, that could produce the symptoms Richard
reported.

ATA, for example, defines different reset operations for Power On,
Hardware, and Software reset (see X3T 10/0948D Rev 4c 7.1). That
anticipates situations where those different reset operations would
have different effects.

 

[Peter Pichler]

I'm drawing a blank. Which is it? I may have to go rent it.

Wasn't it "The invisible man"?

 

[Richard Heathfield]

The really silly part is they're both right. It wasn't--in the
strict and literal sense--a disk failure, but the "thing" that
happened to Richard is *commonly* and *frequently* referred to
as a "disk failure". Short hand for 'disk failed to operate
correctly this time'.

Thanks, Chris. Nice to see a little common sense breaking out there.

 

[Dan Pop]

The really silly part is they're both right. It wasn't--in the
strict and literal sense--a disk failure, but the "thing" that
happened to Richard is *commonly* and *frequently* referred to
as a "disk failure". Short hand for 'disk failed to operate
correctly this time'.

It's more like "disk failed to operate as expected by the BIOS this time".
Which doesn't imply a temporary disk failure any more than implies a BIOS
failure to detect and/or initialise the disk from the state it was left
into by the crashing OS.

Dan

 

[Michael Wojcik]

You have still to prove the existence of PC disks that are not immune to
this kind of abuse.

Fortunately, no, I don't. I was merely explaining why I thought
Mark's belief that a failure in ring-0 code could not possibly put a
disk controller in a state which a software reboot would not reset
was unfounded. Whether controllers vulnerable to such symptoms
actually exist is beside the point; the question is whether it's
*possible* that they exist. If it is, then "no ring-0 code error
could cause disk controller failure" is untrue.

--
Michael Wojcik (e-mail address removed)

This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation

 

[Mark McIntyre]

Fortunately, no, I don't. I was merely explaining why I thought
Mark's belief that a failure in ring-0 code could not possibly put a
disk controller in a state which a software reboot would not reset
was unfounded.

If it is, then "no ring-0 code error
could cause disk controller failure" is untrue.

but again, thats not what I said. Please dont misquote me in the context
of a Poppian debate, its bad enough being abused about what I /did/
write...

</mode>

 

[Dik T. Winter]

> Fortunately, no, I don't. I was merely explaining why I thought
> Mark's belief that a failure in ring-0 code could not possibly put a
> disk controller in a state which a software reboot would not reset
> was unfounded.

It depends also quite a bit on the OS used of course. I have had a
system that had damaged the HD in such a way that the system was
unable to reboot even from CD. Also booting through the firmware
did not help. The problem was that the OS would hang at the moment
the disk was mounted, a bug in the OS. But of course there was an
initial bug that would write something on the disk that would make
the system hang. (The helpdesk of the computer-vendor of course
could not believe it was a software bug, he suspected a hardware
bug or a virus...)

 

[Flash Gordon]

On 26 Feb 2004 18:17:54 GMT

You have still to prove the existence of PC disks that are not immune
to this kind of abuse.

Just for the record, at least with floppy disks if you set the first
three octets of the boot sector to the wrong values then the BIOS (at
least in the early 90s when I tested this) would fail to recognise that
the floppy existed and therefor would not allow the OS to format the
disk. Note, this includes not being able to even do a full format with
either MS DOS or DR DOS, both of which I had access to and the disk
editor in Norton Utilities would also fail to recognise that the floppy
existed. The Atari ST, on the other hand, did not care what those three
octets were so I could reset them to the expected values and suddenly
the PC would accept the floppy. I would not be surprised if the same
thing applies to HDs since those three bytes are one of the mechanisms
used to automatically load SW on accessing the disk to provide things
like compressed floppies that can be read on PCs without the disk
compression SW and, I assume, the SW provided by companies like Maxtor
to work passed BIOS limitations on HD size.

So writing three octets to a floppy could definitely cause a "failure"
that you could not used a PC to recover from and the same may well be
true (although I have not verified it) with IDE HDs (SCSII is different
because it used to be the case that to do a low level format you just
sent a command to the HD telling it to do the low level formatting of
itself, although having to do a low level format would not be nice!).

 

[Michael Wojcik]

If you check back, you'll see that this is not what I said.

When I wrote:

Why not? The bug in question causes code running in privileged mode
(ring 0) to fail in unpredictable ways. It's certainly possible that
in general such a fault can, say, write invalid data to memory-mapped
controler ports. (<[email protected]>)

You responded:

Sure, disk /access/ failure, scribbled on data, unable to boot from
the device etc. But to actually damage the disk electronics so that
the BIOS reports the disk as being nonexistent or defective? Thats
pretty unlikely IMHO. (<[email protected]>)

In short, I claimed that the bug could affect the controller in such
a way as to produce the symptom in question (BIOS can't access disk
until after cold boot). You contradicted me. I ignored the clause
about "damag[ing] the disk electronics", since I hadn't claimed
anything of the sort, and assumed that you disagreed with what I
had actually written.

I admit that in the message you've quoted above I suggested you were
objecting to the hypothetical controller-in-an-invalid-state
diagnosis, since that's what I had been talking about all along. If
that's not in fact what you meant, then your original objection to
my post is moot, since I never claimed any "damage to the drive
electronics".

You also wrote:

FWIW while I accept completely that you saw a disk failure
immediately after the restart, I don't believe that this specific bug
can actually *cause* a disk failure.
(<[email protected]>)

and I continue to claim that you are mistaken. The issues of drive
versus controller and "damage to electronics" versus controller
state are beside the point, because "damage to drive electronics"
is not (I have claimed) the only problem that could produce the
reported symptom (disk failure reported on warm boot).

but again, thats not what I said. Please dont misquote me in the context
of a Poppian debate, its bad enough being abused about what I /did/
write...

I didn't quote you at all in this case. I paraphrased, in a what I
feel was a generous manner: I interpreted your argument as relevant
to what I had actually claimed, not about some chimerical "damage to
electronics". If you prefer, I'm happy to interpret your argument
more strictly and simply note that it's irrelevant.

 

[Dan Pop]

Fortunately, no, I don't. I was merely explaining why I thought
Mark's belief that a failure in ring-0 code could not possibly put a
disk controller in a state which a software reboot would not reset
was unfounded. Whether controllers vulnerable to such symptoms
actually exist is beside the point; the question is whether it's
*possible* that they exist. If it is, then "no ring-0 code error
could cause disk controller failure" is untrue.

Until you prove their existence, Mark has all the rights to believe that
such a thing is *practically* impossible. Theoretical possibility is of
little relevance in a discussion about a thing that allegedly happened.

In theory, it is equally possible that running Richard's program made
dragons fly out of Mark's nose (but Mark didn't notice, being asleep at
the time).

Dan

 

[Mark McIntyre]

You responded:

Sure, disk /access/ failure, scribbled on data, unable to boot from
the device etc. But to actually damage the disk electronics so that
the BIOS reports the disk as being nonexistent or defective? Thats
pretty unlikely IMHO. (<[email protected]>)

Do you see the last sentence here? Do you understand it ?

You also wrote:

FWIW while I accept completely that you saw a disk failure
immediately after the restart, I don't believe that this specific bug
can actually *cause* a disk failure.
(<[email protected]>)

and I continue to claim that you are mistaken.

*shrug*. And I care because?

if you want to continue this, take it to alt.flames.hardware. I'm not
particularly interested except to remove what I felt was a
misrepresentation of what i said.