bugzilla-daemon@xxxxxxxxxxxxxxxxxxx put forth on 4/30/2010 8:29 PM: > Now, there may be a difference in what commands the burning software is using > or the ordering that results in some of them taking longer than it does in > Windows or something. (I don't know the MMC commands that well but I think some > of them do have a mode where you can issue the command and poll periodically to > see if it's done rather than blocking on the operation until it finishes.) That > isn't anything the kernel can do anything about, though - if something issues a > command to one drive on the channel that takes a long time, anything wanting to > access the other drive just has to wait. This has been known for over a decade. When I was building white box Windows systems in the mid-late 90s our SOP was to put burners on a dedicated IDE port specifically due to what the OP reports over a decade later as a bug. As Robert points out above, this isn't a software bug, but a hardware limitation of IDE. Parallel SCSI, SAS, and SATA do not suffer this limitation. Apparently Windows engineers have developed a method over the years to mitigate the ill effects of this. I can tell you from experience that Windows 9x/ME/NT4/W2K all suffered performance degradation with HD+burner on the same channel problem. -- Stan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
