DVDD gets stuck while searching for SCSI/ATAPI devices

[Rdunzl]

This isn't really a bug report of imgburn, and it's not really about a bug in dvdd either...

 

I've posted my troubles in the doom9 forum, and you can read it here if you want the full story.

 

One helpful guy suggested that I reported the problem here since imgburn is based on the dvdd code. So if you ever get a similar bug report, you'll have a hint on what could be the cause.

 

Since I've fixed the problem, I can't really tell if the problem will occur with the code you have ported to your new app (thanks a lot for both of your great apps).

 

Well, lets take the steps to reproduce the behaviour:

1) Push pin 21 of your DVD reader into the back of the device, so that it can't be connected to the IDE cable

(I'm not to be held responsible if anyone chooses to reproduce this lame behaviour).

 

2) Run DVDD (any of the later versions will do)

 

This will cause the system to hang. If you try to access the device's properties in Control Panel>System>Hardware>Device manager>[Name of your DVD device] (the correct captions may be different, I have translated from a danish version of windows XP) you'll get the same effect, and if you insert a DVD media, you'll also get the same effect (this was my secondary DVD drive that I almost never use).

 

Solution:

Repair the DVD device or get rid of it

 

The peculiar thing is that neither Nero, Isobuster, Alcohol 120%, SmartRipper or any other applications I've been using was causing the same problem, so it took me a great deal of time to figure out that it was a hardware error.

Edited October 13, 2005 by Rdunzl

[dontasciime]

Stands to reason if you break it, it won't work.

 

Pin 21 DMARQ or it's absence.

 

Multiword DMA is a data transfer protocol used with the READ DMA, WRITE DMA, READ DMA

QUEUED, WRITE DMA QUEUED, and PACKET commands. When a Multiword DMA transfer

mode has been set via the SET FEATURES 03h subcommand, this data transfer protocol shall

be used for the data transfers associated with these commands. Signal timing for this protocol is

described in 10.2.3.

The DMARQ and DMACK- signals are used to signify when a Multiword DMA transfer is to be

executed. The DMARQ and DMACK- signals are also used to flow control a Multiword DMA data

transfer.

When a device is ready to transfer data associated with a Multiword DMA transfer, the device

shall assert DMARQ. The host shall then respond by asserting DMACK-, negating CS0- and

CS1-, and begin the data transfer by asserting, then negating, DIOW- or DIOR- for each word

transferred. The host shall not assert DMACK- until DMARQ has been asserted by the device

shall transfer data only when both DMARQ and DMACK- are asserted. Having asserted DMARQ

and DMACK-, these signals shall remain asserted until at least one word of data has been

transferred.

The device may pause the transfer for flow control purposes by negating DMARQ. The host shall

negate DMACK- in response to the negation of DMARQ. The device may then reassert DMARQ

to continue the data transfer when the device ready to transfer more data and DMACK- has been

negated by the host.

The host may pause the transfer for flow control purposes by either pausing the assertion of

DIOW- or DIOR- pulses or by negating DMACK-. The device may leave DMARQ asserted in this

case. The host may then reassert DMACK- when DMARQ is asserted and begin asserting

DIOW- or DIOR- pulses to continue the data transfer.

When the Multiword DMA data transfer is complete, the device shall negate DMARQ and the

host shall negate DMACK- in response.

 

Pete McLean

Maxtor Corporation

[zacoz]

Thanks for that explanation Pete....it all makes sense now

[AlienX69]

Pete McLean

Maxtor Corporation

Yeah, thanks for that explaination Pete, btw I didn't you worked for Maxtor ...... LOL !

 

AX

Edited October 14, 2005 by AlienX69

[dbminter]

You never know how those bent pins will behave. I once, as it turned out, had a bent pin on a floppy drive's interface. The drive worked just fine... except formatting would always fail with an error message, BUT, disks were formatted just fine. It would reach 99% and say it failed. I discovered the pin bent on the floppy interface, straightened it out as best I could, did my best to insert the cable back so as not to bend the pin, and formats resumed completing at 100% with no errors.

[dontasciime]

With a bent pin you could easily get away with various results, but with no pin at all, the device will more than likely fail at most tasks, all of the time.

[lfcrule1972]

Bent pin ? Is that a double entendre for ??

 

[dontasciime]

[dbminter]

With a bent pin you could easily get away with various results, but with no pin at all, the device will more than likely fail at most tasks, all of the time.

 

 

I didn't say it but I meant to say that by a bent pin, the pin was bent and was NOT connected. The formats would still complete even with the pin not connected at all. I then later straightened it out and reconnected it, i.e. didn't have a bent pin straightened and connected the whole time. I was actually surprised the pin hadn't been snapped completely off.

[jmet]

Amber bent my pin the other night!

[dbminter]

Don't worry. You've still got 39 left. Of course, most of us now are using 80!