Re: kill -9 <pid of X>

Jon M. Taylor (taylorj@ecs.csus.edu)
Thu, 13 Aug 1998 18:45:22 -0700 (PDT)


On Thu, 13 Aug 1998, Ian Stirling wrote:

> Sorry about this, but I can't find my VGA programmers book, and never
> did much anyway.
>
> About stopping accelleration operations in the middle:
>
> Why can't we just wait 10ms, for any outstanding operations to complete?
> Or are there operations on some cards that may take times that are
> perceptible to the user to complete?

No no no. The problem is not firing an accel and then resetting
the card before it is done (that might cause problems too, I dunno) but
having to set six accel registers to fire the accel and resetting the card
after only three have been set.

> Is it really impossible to completely re-setup the hardware, ignoring
> any values that may have been there before, to get a "sane" state?

It isn't impossible. There are many cases where it works. There
are also many cases where it does NOT work, and those cases are often tied
to subtle hardware bugs or misfeatures. In any case there's certainly no
"this is when you can get away with resetting the hardware" lists. To be
safe, you have to ensure atomicity of the mode setting and accel
programming.

> Does the bios have special abilities, or do cards power up in a special
> initialisation state, with defined parameters?

There's usually a predefined power-on mode, set by the BIOS IIRC.
The ATI Mach32 had an EEPROM on the card which could store mode timings
and other info - you could preset the power-up mode there. AFAIK it is
hardwired on all other cards.

> I don't think cards that can be crashed enough to make them require a
> power-down to work in NT, is an important part of this, it's a buggy card,
> and needs replaced.

You just threw away the majority of SVGA cards ever produced.
Most cards can be wedged tight like this. It is easier to do on some
cards than on others, but pretty much *ALL* SVGA cards have bugs. Even if
they don't, the fact of that matter is that these cards were designed
under the assumption that their SVGA featureset would be used exclusively
by driver code written by the manufacturer, or maybe VESA BIOS calls.
They counted on the driver and BIOS code to keep the card sane, and this
let them cut a lot of corners.

Why support the ability to break off accel programming midstream
if the drivers can ensure that this will never happen? Why ensure that a
modeset is always legal if you can control when it happens? Why do
extensive bughunting and bugfixing when you can hide the bugs with a
little driver kludge and avoid having to rework your VHDL? The damn
product's only going to have a sales life of a year or less anyway! Get
it out the door! If any hardware bugs show up in the field, whip up
another driver kludge-around and tell everyone to get the new driver
updates. Why do you think Windows video drivers need update so often?

People who have not been exposed to the gory details of SVGA card
programming tend not to fully comprehend the sheer scale of this problem.
PC SVGA video cards are the hardware equivalent of Microsoft's software
products. Each one is rushed out the door, loaded with bugs both known
and unknown. Beta testing is skimpy to nonexistent, and the assumption is
that the next rev of the silicon can fix the bugs, and the driver code can
kludge around the existing bugs. Occasionally a hardware bug does arise
in the field that can't be worked around in the driver code, and in those
cases the buyers are usually screwed unless they got they video card in an
OEM prebuilt machine, in which case they can send it back. Often when you
send a broken video card back, you will get another brand of video card
back as a replacement!!! One time I was shipped a new ramdac chip, with
the necessary tool needed to pull the old chip out of its wierd,
nonstandard socket. It is surreal sometimes.

Quality has gotten a lot better since the 3D revolution took hold
and some workstation hardware designers entered the PC video card market.
But it ain't perfect yet, not by a long shot. I sometimes wonder if some
of the NDA-happiness of the 3D videocard world isn't due to their desire
to cover up rendering bugs in their hardware. I wonder if the time it
took a lot of those hardware vendors to create OpenGL drivers for their
cards wasn't lengthened by having to insert workarounds all over the place
in the rendering pipeline.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html