Changing PCI cards without switching off?

[Overlord]

Bring up the diagnostics. In 2K it's Control Panel => System => Hardware
=> Device Manager => Modem. Double click, go to the Diagnostics tab and
see what the modem BIOS thinks of itself, NVRAM settings, S registers,
versions, phone numbers, etc.
Unless the markings you want to inspect were where your son was shooting
it with a BB gun....

As for pulling the card hot, it's A Bad Thing. See the caps? Like Winnie the Pooh;
Going On A Grand Adventure With Christopher Robin To The Cathouse.
It might work but the odds are low. Most likely scenario is that it would
burn the contacts in the PCI slot and on the card possibly rendering card and
slot useless. The least that would happen is that it would work, maybe, once.
I suppose the worst that could happen is the system bursting into flame as your
cheap PS surges thru the chipset and CPU and all the other cards

If you really want to pull it, the MB BIOS would probably sideline the slot and
when you put it back in, it wouldn't be recognized. You would end up with down
time as you rebooted in any case.
BTW, on ATX machines, unless you have a physical switch on the power supply
and use it to turn the PS off, there is still current in the system. If you have no
switch ON THE POWER SUPPLY, pull the plug and wait half a minute before
playing with drives, cards, etc.

I usually switch off my PC before I change a PCI card but a recent
case I wanted to remove a modem card, then inspect the markings and
then restore it in the PC.

If I don't switch off the PC then what sort of damage might I cause?

~~~~~~
Bait for spammers:
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
postmaster@[127.0.0.1]
(e-mail address removed)
~~~~~~
Remove "spamless" to email me.

 

[Noozer]

Apparently the acronym IRQ means Interrupt ReQuest.

What is "the interrupt fires" supposed to mean?

An interrupt works like someone tapping you on the shoulder. Do you
constantly check your shoulder (polling) to see if someone is tapping it or
do you just act when you feel the sensation?

PC interrupts are the same... when an interrupt fires (ie INT pin is
grounded, the CPU or controlling circuitry automatically interrupts the
currently running code and jumps to an interrupt handling routine. Once the
interrupt has been handled the CPU goes back to what it was doing.

....and this whole thread should have died a ***LONG*** time ago.

 

[recursor]

An interrupt works like someone tapping you on the shoulder. Do you
constantly check your shoulder (polling) to see if someone is tapping it or
do you just act when you feel the sensation?

PC interrupts are the same... when an interrupt fires (ie INT pin is
grounded, the CPU or controlling circuitry automatically interrupts the
currently running code and jumps to an interrupt handling routine. Once the
interrupt has been handled the CPU goes back to what it was doing.

...and this whole thread should have died a ***LONG*** time ago.

You are right about the way interrupts work but this thread's gonna live forever, I once forced an
ISA card into a PCI slot with a sledgehammer and the sledgehammer wasn't damaged at all.

 

[mhaase-at-springmind.com]

You aren't replying to the original poster, and the person you are
replying to isn't really asking for help IMO.

You're right, of course. My mistake. Thanx! Happy Holidays!

 

[mhaase-at-springmind.com]

What I am after is an explanation of how certain he is of his
statement. I AM NOT SURE OF MINE, but my experiences led me to believe
the computer would drop the device pulled from the socket if done so
with power on, and not work if inserted again without rebooting. If he
IS SURE OF HIS statement, then I trust he is correct. My question is
one of curiosity and NOT criticism. THAT is what I am trying to
accomplish. If YOU have the ability to answer the question I posed, by
all means answer it. So to answer your question, I am after KNOWLEDGE.

I have worked on hundreds of computers, and I AM STILL LEARNING. I DO
NOT HAVE ALL THE ANSWERS, AND NEVER WILL. One of the great things about
the news groups is that you can learn from the experiences of others if
you are willing to listen and ask questions. That is, unless some other
poster who has nothing to add but criticism turns off those willing to
add their experiences and comments. Lighten up!!

Easy there! Calm down. I made a mistake and wrongly assumed I *was*
replying to the original poster (who, FWIW, seems to have
disappeared).

Just trying to help the OP who seemed like he/she was trying to *do*
something (get an end result), and stubbornly thought this (hot
plugging) might be the correct way (or a shortcut). It's not.

It's like when my neighbor came over asking to borrow a certain
wrench. I asked "Why?" (knowing he's a little dangerous around
tools). Turned out he was trying to install new brake pads on his
car, but had no clue on how to do it - so was taking the entire brake
cylynder off the wheel. A quick, "Pat - what are yoiur trying to
do?", saved alot of time and effort (and possibly a family of four
careening down the road with no brakes).

As a side note, I find that a car's brakes are NOT the best place for
"somebody with no clue" to start learning.

Happy Holiday!

 

[Euan Kerr]

I usually switch off my PC before I change a PCI card but a
recent case I wanted to remove a modem card, then inspect the
markings and then restore it in the PC.

If I don't switch off the PC then what sort of damage might I
cause?

Interesting how an obviously stupid question started such an
extensive technical mass-debating session.

Well trolled.

 

[GB]

An imperfect plan executed violently is far superior to a perfect plan.
-- George Patton

I've no idea whether you are right about the PCI cards, but that George
Patton quote has the ring of truth about it.

 

[Alex Fraser]

[snip]

At the least, to hot-swap PCI cards, you would need some sort of
mechanical system to ensure they go in more or less straight?

Other posters have already hinted that the PCI slot is first powered down. I
don't know one way or the other, but would have thought the signal lines are
also isolated, because shorts (for certain) and noise (possibly) caused by
insertion would affect signal integrity for other things attached to the
bus.

Alex

 

[Guest]

http://tinyurl.com/666mp

(http://groups-beta.google.com/groups?as_epq=hot popped&saf
e=images&as_ugroup=Sci.electronics*&as_scoring=d&lr=lang_en&
num=100&hl=en)

There is no such thing as "hot popped".

How about hot swapping, which would include both popping and plugging?

 

[David Maynard]

What is "the interrupt fires" supposed to mean?

There are a number of variations to interrupt handling but the original
notion, from which the term gets its name, is just as it says; an
'interrupt' to the normal execution flow. I.E. Upon assertion of the
interrupt line the processor is jerked away from whatever it's doing and
sent into the interrupt service routine. The processor does not 'poll' or
otherwise 'monitor' the interrupt line. The redirection is handled in the
hardware.

 

[John Doe]

There are a number of variations to interrupt handling but the
original notion, from which the term gets its name, is just as it
says; an 'interrupt' to the normal execution flow.

I would guess it is an "interrupt request" at the hardware input pin
level.

I.E. Upon assertion of the interrupt line the processor is jerked
away from whatever it's doing and sent into the interrupt service
routine. The processor does not 'poll' or otherwise 'monitor' the
interrupt line. The redirection is handled in the hardware.

That might be what I would have guessed if I knew something about the
hardware and software involved. I was thinking the term IRQ [number]
refers more to hardware than software. I don't think it's worth
arguing, but I suspect you disagree.

 

[John Doe]

....

In effect, yes, interrupt lines are polled in hardware. Often,
pending interrupts are acted upon at the start of the next
instruction executed by the processor. ....
Rene refers to polling in software, where the processor
periodically executes instructions to read a hardware register
which indicates when the hardware needs attention.

Thanks. And that answers my questions in reply to David Maynard.

 

[Noozer]

In effect, yes, interrupt lines are polled in hardware. Often, pending

interrupts are acted upon at the start of the next instruction executed by
the processor.

Nope... The CPU does not poll anything.

Rene refers to polling in software, where the processor periodically
executes instructions to read a hardware register which indicates when the
hardware needs attention.

Again you're wrong.

When an interrupt occurs the CPU is pulled away from it's current task to
execute an IRQ routine. Part of this routine does read hardware registers to
find out what interrupt occured (since there are multiple interrupts) and
acts accordingly.

There is NO polling involved with interrupts. That's the whole point of
them - they just "happen" and affect the CPU.

 

[John Doe]

There is NO polling involved with interrupts.

That has already been established (strictly speaking, software
wise), perhaps too subtly for you to understand.

For someone who wrote "this whole thread should have died a
***LONG*** time ago", seems you enjoy beating a dead horse.

 

[Alex Fraser]

Nope... The CPU does not poll anything.

Suppose, as I suggested, pending interrupts are acted upon at the start of
the next instruction - that is, the processor's interrupt mechanism kicks in
at the point where the next instruction would begin to be executed (I don't
know of anything that doesn't work like this). That means that based on
whether there is a pending interrupt, the processor periodically (albeit
very frequently) chooses whether to execute the next instruction or begin
the process for handling the interrupt (eg saving the PC and jumping to some
predefined address). Sounds very similar to polling to me.

Again you're wrong.

No, I just didn't explain it very clearly; blame it . What I meant was that
the software (which is doing the polling) contains the instructions I
mentioned. The software is written such that hardware registers are read
periodically, their values tested, and any necessary action is taken.

When an interrupt occurs the CPU is pulled away from it's current task
to execute an IRQ routine.

Yes, but not asynchronously. And that is what makes it similar to polling.

Part of this routine does read hardware registers

Not necessarily. But yes, practically always.

to find out what interrupt occured (since there are multiple interrupts)

Not necessarily.

In a basic 8051 for example, different interrupt sources cause the processor
to branch to different addresses according to the interrupt. So you already
"know" which interrupt occurred in a given interrupt handler.

and acts accordingly.

Alex

 

[David Maynard]

There are a number of variations to interrupt handling but the
original notion, from which the term gets its name, is just as it
says; an 'interrupt' to the normal execution flow.

I would guess it is an "interrupt request" at the hardware input pin
level.
Yes.

I.E. Upon assertion of the interrupt line the processor is jerked
away from whatever it's doing and sent into the interrupt service
routine. The processor does not 'poll' or otherwise 'monitor' the
interrupt line. The redirection is handled in the hardware.

That might be what I would have guessed if I knew something about the
hardware and software involved. I was thinking the term IRQ [number]
refers more to hardware than software. I don't think it's worth
arguing, but I suspect you disagree.

IRQ does refer to the hardware. Specifically, which interrupt line it is.

The original PC had an interrupt controller chip that provided 8 interrupt
lines. The AT added a second 8 line interrupt controller that connects to
the first one on IRQ2, so you have 7 on the first (IRQ2 being used already
for the chain to the second controller) and 8 on the second for 15 total.
Of the 15... 0, 1, 2, 8, and 13 are reserved for system use. That leaves
the ones most PC builders should be familiar with.

When an interrupt occurs on one of the IRQ lines the processor is
interrupted and the corresponding interrupt handler routine is vectored to
by the IRQ number, which is an offset into an IRQ table at the beginning of
memory. I.E. the IRQ number causes the hardware to load in the address
stored in location IRQ_VECTOR_BASE + IRQ#(times 4 because there are 4 bytes
per address vector) and code execution resumes at that location: the
interrupt routine. At the same time the interrupt is vectored, where the
processor *was* executing code is saved and, when the interrupt routine is
finished, it restores that and execution goes back to where it was when
interrupted.

Point is, the 'interrupt' is done by the hardware.

IRQ sharing is when more than one device is on the same IRQ line and, in
that case, the interrupt handling routine must then go and query the
card(s) to see which one made the interrupt request.

I see someone else has mentioned that the processor 'waits for the
beginning of the next instruction' and then claims this sounds like
'polling' to him. Regardless of what it might sound like, that is not
'polling' as the term is commonly used. That the interrupt occurs on an
instruction cycle boundary is, again, handled by the hardware (or rather,
the hardware and microcode in the processor) and not the software.

'Polling' generally refers to software having to perform the function of
repeatedly scanning the item(s) of interest to see if it/they need(s)
service because there's nothing to 'interrupt' the processor when
'something needs to be done'.

The reason for hardware interrupts should be rather obvious from that
description. With polling, processor time is used up by repeatedly scanning
whatever it is that's being checked and response time is limited by how
fast the processor does it, which you will want to do as little as possible
to avoid sucking up processor time. It's a catch-22 between response time
and processor time.

With hardware interrupts the processor can work it's little heart out on
whatever software you're running and is burdened only when something really
does need servicing.

If hardware interrupts are enabled, and one goes active, then the processor
*is* going to get interrupted and execution *will* be redirected to
whatever location is stored in the interrupt vector table regardless of
what 'code' one writes. The hardware will cause it.

With 'polling', nothing will happen unless you write the code to do it.

 

[David Maynard]

I wrote:




Suppose, as I suggested, pending interrupts are acted upon at the start of
the next instruction - that is, the processor's interrupt mechanism kicks in
at the point where the next instruction would begin to be executed (I don't
know of anything that doesn't work like this). That means that based on
whether there is a pending interrupt, the processor periodically (albeit
very frequently) chooses whether to execute the next instruction or begin
the process for handling the interrupt (eg saving the PC and jumping to some
predefined address). Sounds very similar to polling to me.

You're mixing hardware and software together.

To the O.S. programmer, O.S. because that's where interrupt handling will
be done, there is no 'polling' code to write because it is done by 'the
hardware' and whether the hardware performs it's logic using discrete
gates, a PAL, PIC, or whatever clever mechanism, is moot because it simply
happens and there's nothing the O.S. programmer can do to alter the
functioning of it. I.E. It's hardware.

Secondly, you're calling every bit and portion of a processor 'the
processor' and that's like saying you 'decide' to snap your leg up when
someone whacks your knee in the right spot testing reflex actions. It may
be a 'part' of 'you' but that doesn't mean 'you decided'. Nor do you
'decide' to speed up your heart when exercising and slow it back down at rest.

The address unit of the processor, note that is a 'part' of a processor,
can get the next address from a number of sources. One is to simply
increment the current address. Another is code altering what the next
address is, as in a branch. And another is the next address automagically
appearing because the interrupt unit, another 'part' of the processor,
shoved it in there. And they all go in there at the right time for 'the
next instruction' because the hardware is simply designed to do it that way
but I seriously doubt you'd call getting the next instruction address
'polling' for one and neither is the interrupt unit shoving one in there.

No, I just didn't explain it very clearly; blame it . What I meant was that
the software (which is doing the polling) contains the instructions I
mentioned. The software is written such that hardware registers are read
periodically, their values tested, and any necessary action is taken.

*What* 'software'? Nothing the O.S., or any other i386, programmer wrote is
doing that.

Yes, but not asynchronously.

Compared to what? It certainly *is* asynchronous relative to instruction
execution.

And that is what makes it similar to polling.

That things inside the processor take place at the appropriate times does
not, in any way, imply 'polling'. Synchronicity perhaps, but not 'polling'.

 

[John Doe]

Alex Fraser wrote:

You're mixing hardware and software together.

That makes two brilliant, however redundant insights.

That things inside the processor take place at the appropriate
times does not, in any way, imply 'polling'. Synchronicity perhaps,
but not 'polling'.

Polling is testing periodically to see whether a condition exists.
There is a similarity between software polling and a hardware clock
transition testing an input pin. The software meaning of the term is
fairly generic IMO.

For the pedantic. Once again, no one is saying that the two forms of
polling are the same thing. Everybody has already been schooled on
the proper use of the term, at least three times so far in this
thread.

 

[David Maynard]

That makes two brilliant, however redundant insights.

Actually, that's only one insight. But only redundant if the person I was
replying to knew it and it's not at all clear that he does.

Polling is testing periodically to see whether a condition exists.
There is a similarity between software polling and a hardware clock
transition testing an input pin.

You're assuming a 'hardware clock' is needed to 'test' the pin but, while
that might be one way to accomplish the task, it isn't a 'requirement'.

The software meaning of the term is
fairly generic IMO.

Even if true there would have to be software involved and, in the case of a
hardware interrupt, there isn't any doing polling.

For the pedantic. Once again, no one is saying that the two forms of
polling are the same thing. Everybody has already been schooled on
the proper use of the term, at least three times so far in this
thread.

If the schooling had taken we wouldn't have people calling a hardware
interrupt 'polling'.

 

[Alex Fraser]

news:3DAzd.572117$Pl.189475@pd7tw1no... [snip]
Suppose, as I suggested, pending interrupts are acted upon at the
start of the next instruction - that is, the processor's interrupt
mechanism kicks in at the point where the next instruction would begin
to be executed (I don't know of anything that doesn't work like this).
That means that based on whether there is a pending interrupt, the
processor periodically (albeit very frequently) chooses whether to
execute the next instruction or begin the process for handling the
interrupt (eg saving the PC and jumping to some predefined address).
Sounds very similar to polling to me.

You're mixing hardware and software together.

Only to point out the conceptual similarity.

To the O.S. programmer, O.S. because that's where interrupt handling
will be done, there is no 'polling' code to write because it is done by
'the hardware' [...]

Yes, as I said before: "In effect, yes, interrupt lines are polled in
hardware."

Secondly, you're calling every bit and portion of a processor 'the
processor' and that's like saying you 'decide' to snap your leg up when
someone whacks your knee in the right spot testing reflex actions. [...]
The address unit of the processor, note that is a 'part' of a processor,
can get the next address from a number of sources. One is to simply
increment the current address. Another is code altering what the next
address is, as in a branch. And another is the next address
automagically appearing because the interrupt unit, another 'part' of
the processor, shoved it in there.

Try looking at it the other way round: the new PC (incremented PC, branch
target or interrupt vector) is selected (ie chosen), based on control
signals within the processor (affected by, amongst other things, interrupt
lines).

*What* 'software'?

Software that is polling, when there are no interrupts.

Rene wrote: "There is one reason why hardware interrupts were invented, and
that is so that polling wouldn't be necessary anymore."

Apparently, both you and Noozer missed that.

Compared to what? It certainly *is* asynchronous relative to instruction
execution.

That's either true or false, depending what you mean. I know what you mean.
I meant asynchronous like an asynchronous set/clear on a flip-flop.

That things inside the processor take place at the appropriate times
does not, in any way, imply 'polling'. Synchronicity perhaps, but not
'polling'.

I only said it was *like* polling. John Doe summed it up nicely.

Alex