PC slows to crawl when reading bad CD

[blevsta]

Anytime I try transfering files from a bad CD to my hard drive the entire PC becomes unresponsive. Any action will take about 1-5 minutes to respond. Like opening internet explorer, or windows explorer. My friend has the exact same problem, so I'm hoping this is a known issue, and someone knows of a fix...The only way to recover is to let the DVD drive to time out, let it finish copying the files (if it gets that far), or open the DVD drive.

Here's my PC specs:
Windows 7 64bit
i7-920
GIGABYTE GA-EX58-UD3R
LG Black 22X DVD+R

My friend has an NVidia card and faster memory but same components as above.

 

[bilbat]

Throw away the bad CD!

 

[englandr753]

Its a lost cause if the drive doesn't recognize the cd and hangs like that. I had the same issue with a Q9550 system and tried to read the same disk on my other Q9550 media system and another AMD 620 x4 system and all were rendered unresponsive.

I threw away the disk.

You will want to have a backup of valuable data and not rely on a single cd anyway so this shouldnt be a problem. If it is, you will know better for the next time! = P

 

[apache_lives]

IDE dvdrw or SATA?

 

[blevsta]

SATA II DVDRW

It just seems odd that it kills the rest of my computers responsiveness. Why can't my processor and memory be used for internet explorer while the DVD drive is fumbling?

 

[bilbat]

Here's what's up:

First, devices are operated, inside an operating system/BIOS by something called an 'interrupt mechanism'. Interrupts, to the system, are kind of like a little kid tugging on ma's skirt - "Ma, can I have a candy bar?"; "Ma, can I have a coloring book?"; "Ma, look at the funny man!" Every time you hit a key on your keyboard, the hook-up generates an interrupt, telling the system "Hey, this is important - I've got a keystroke to process!" The BIOS/operating system have a set-up to then do what the interrupt requires - handle a keystroke, read a track from disk, whatever... Your first problem is that a repetitive attempt to read a 'bad' track generates a whole lot of repetitive interrupts, which have to be handled. Obviously, the interrupt mechanism has to 'stack up' the interrupts; it can't simply do 'this' while negecting 'that', say, 'ignoring' your keystrokes - they all have to be taken care of, mostly by the DPC (deferred procedure call) stack, which you can read about here:
http://www.thesycon.de/deu/latency_check.shtml

Second, operating systems are built to be very 'anal retentive' about storage devices - to 'preserve' your (maybe) important and (maybe) valuable data. If they get an error when they try to 'service' an interrupt related to a storage device, they will do 'retry' after 'retry', in an effort to safeguard/retrieve/whatever the information that seems, at first try, either unavailable or corrupted - this is what you're seeing...

 

[blevsta]

Thanks for the detailed response. At least I understand the problem a little better now.

This isn't something I've taken notice of before, and I've gone through plenty of bad discs. Could this have anything to do with the new hardware and Windows 7? Like maybe they're sending 10x the amount of interrupts as the hardware/software from before? Is this something that can be throttled down, DVD read errors specifically?

 

[bilbat]

Might be a driver problem (but I haven't seen it - and I run four 'flavors' of seven), or a firmware problem with your particular drive... If you're running in AHCI mode, try switching back to 'compatibilty' mode, if not running AHCI, might try it... Easiest solution - what I first told you - throw out the ^%$#ing bad disk! [:bilbat:9]

 

[Starges]

Here's what's up:

First, devices are operated, inside an operating system/BIOS by something called an 'interrupt mechanism'. Interrupts, to the system, are kind of like a little kid tugging on ma's skirt - "Ma, can I have a candy bar?"; "Ma, can I have a coloring book?"; "Ma, look at the funny man!" Every time you hit a key on your keyboard, the hook-up generates an interrupt, telling the system "Hey, this is important - I've got a keystroke to process!" The BIOS/operating system have a set-up to then do what the interrupt requires - handle a keystroke, read a track from disk, whatever... Your first problem is that a repetitive attempt to read a 'bad' track generates a whole lot of repetitive interrupts, which have to be handled. Obviously, the interrupt mechanism has to 'stack up' the interrupts; it can't simply do 'this' while negecting 'that', say, 'ignoring' your keystrokes - they all have to be taken care of, mostly by the DPC (deferred procedure call) stack, which you can read about here:
http://www.thesycon.de/deu/latency_check.shtml

Second, operating systems are built to be very 'anal retentive' about storage devices - to 'preserve' your (maybe) important and (maybe) valuable data. If they get an error when they try to 'service' an interrupt related to a storage device, they will do 'retry' after 'retry', in an effort to safeguard/retrieve/whatever the information that seems, at first try, either unavailable or corrupted - this is what you're seeing...

Wow.., with sucha detailed answer, even a 2 yr old wouldn't need further explanation :lol: :lol:

Nice

 

[bilbat]

Thanks! I try... [:bilbat]

 

[englandr753]

So basically your pc had 3,000 kids tugging on its skirt at the same time, LOL!

Thats a cute little truck you have there. = P Good job. I tag you with the best answer. = )

 

[bilbat]

basically your pc had 3,000 kids tugging on its skirt at the same time

Exactly! I've posted this before:

What's going on behind the scenes: the task scheduler is scurrying around, busier than a centipede learning to tap-dance, counting 'ticks': ...tick... yo - over there, you gotta finish up, your tick is over, push your environment, that's a good fella; oops - cache snoops says we've got an incoherency - grab me a page for him from over there; you - get me the address of the block being used by {F92BFB9B-59E9-4B65-8AA3-D004C26BA193}, will 'ya; yeah - UAC says he has permission - I dunno - we'll just have to trust him; damnit - everybody listen up, we've got a pending interrupt request, everyone drop what you're doing, and you - over there - query interrupt handler for a vector - this is important!!! ...tick....

And the most fascinating (scary) thing about it all, is that, at some synaptic, neural level, we're doin' the same thing!

(...though, the older I get, the less dependable my interrupt return mechanism is - I repeatedly find myself at the bottom of the basement steps, wondering "now what did I come down here for?!")

 

[qhorque]

This is the ONE thing that Microsoft and Intel need to fix. Dual core, quad core, 6-core, etc. No matter how fast the processors and no matter how many cores they contain, the bottleneck has been and seems to continue to be the antiquated interrupt system which renders our hot new machines useless at the drop of a hat.

I can't tell you the number of times I have double clicked on an icon only to have to wait for the computer to respond when it's apparently doing nothing. When it finally responds, I find out there was some intensive background process (typically anti-virus or some corporate version of BlackIce running) that was being over-protective and scanning in high priority mode the same files it scanned an hour ago. That on a dual Xeon system with hyper-threading and 4GB of RAM.

Apparently computers can still only do one thing at a time. It's extremely frustrating and I wish they'd fix it.

 

[bilbat]

Indeed!! I'm seriously considering a Tyan dual-'hexacore' for the next workstation upgrade, but it's not gonna make a lot of difference if twenty-one of those twenty-four hyper-threads are sitting around with their thumb up their @$$, collecting 'welfare payments' from the PSU

 

[englandr753]

Hehe, this is great stuff! Lol! I've got my entertainment for the day!

 

[blevsta]

Best answer selected by blevsta.