Bug 16609
| Summary: | Blanking CD w/ cdrecord stops some network traffic | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Bitt Faulk <wfaulk> |
| Component: | cdrecord | Assignee: | Crutcher Dunnavant <crutcher> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.2 | CC: | giulioo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-08-19 21:58:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bitt Faulk
2000-08-19 21:50:33 UTC
I forgot to mention that I can record on CDRs and CDRWs fine without any network interruption. I asked johnsonm, and he says that this IS NOT A BUG (tm). The answer is that IDE transfers DISABLE interupts on the machine (So LARGE transfers disable them for a LONG time). The reason is that some harddrive/chipset combos corupt data if you don';t do this. The fix is, if you are brave, (AND BACK EVERYTHING UP, CAUSE THIS COULD KILL YOUR FILESYSTEM!!!) edit /etc/sysconfig/harddisks and uncomment the line "DMA = 1". Be careful :) I understand what you're saying here, but what I can't reconcile is why it hoses up my interrupts when blanking a CDRW but not when writing one. It seems to me that there's more real data going through on a write than a blank. If it's really sending a long string of nothing, instead of an ioctl or something, it seems like it ought to be possible to send that in the same chunked format that the write apparently sends it in, in order to allow interrupts to get through. Or is my reasoning completely wrongheaded here? I'm certainly not an expert at this low a level of communication. I have the same problem when burning: system totally "suspended" while
performing PMA, TOC, pregap and at the end when fixating; ps, ls, .. everything
blocks.
kernel 2.2.19 from rh errata, cdrtools updated to cdrecord-1.11a01-1
Since I use software mirroring (hda+hdc) I cannot put ide cdrw on a separate
idechannel, which solves the issue.
crutcher said:
>The fix is, if you are brave, (AND BACK EVERYTHING UP, CAUSE THIS COULD KILL
>YOUR FILESYSTEM!!!) edit /etc/sysconfig/harddisks and uncomment the line "DMA =
>1".
I do have dma on on the hard disks, and still experience the problem. Any other
thing to try?
$ hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 1240/255/63, sectors = 19932192, start = 0
$ hdparm /dev/hda
/dev/hdc:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 1240/255/63, sectors = 19932192, start = 0
$ hdparm /dev/hdd (ide cdrw)
/dev/hdd:
HDIO_GET_MULTCOUNT failed: Input/output error
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
HDIO_GET_NOWERR failed: Input/output error
readonly = 0 (off)
BLKRAGET failed: Input/output error
HDIO_GETGEO failed: Invalid argument
I even tried u1 c3 on hdd.
To clarify; I wrote:
>I have the same problem when burning: system totally "suspended" while
>performing PMA, TOC, pregap and at the end when fixating; ps, ls, ..
>everything blocks.
I burn a cdrw, I get about 60secs block when "PMA/TOC/pregap", then system is
normal while writing data, then another 60secs block while "fixating".
|