Bug 16609 - Blanking CD w/ cdrecord stops some network traffic
Blanking CD w/ cdrecord stops some network traffic
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: cdrecord (Show other bugs)
6.2
i586 Linux
medium Severity high
: ---
: ---
Assigned To: Crutcher Dunnavant
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-19 17:50 EDT by Bitt Faulk
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-19 17:58:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bitt Faulk 2000-08-19 17:50:33 EDT
I have a Pentium machine that I use as a router/firewall, mail server, and 
dns server for my home.  It also contains an IDE CDRW drive.  I've 
configured the kernel to do IDE->SCSI emulation (I don't remember the 
kernel option right now, but cdrecord requires it for IDE CDR support).  
Whenever I try to blank a CDRW, some network traffic stops.  I feel that 
it might be totally blocking on that IDE chain, but I'm not sure.  It 
would seem to not work when disk access is required.  Anyway, the symptoms 
I see are:

Can continue to browse the web w/ Windows client behind the machine.
Cannot get to sites I have not already been to.
These seem to hold no matter what the traffic.  (I think that DNS lookups 
on the Linux machine are not happening properly).

Network traffic to the Linux machine itself can continue in some cases.  
The ssh connection I have open running the cdrecord job still functions, 
but I cannot open a new session.

When I ctrl-c'd out of the cdrecord process, I tried to run w, out of 
habit, I guess.  This locked up as well.  I could still send traffic over 
the ssh session (it still echoed newlines), but I could not ctrl-c or ctrl-
\ out of the w process.  At this point the CDRW drive LED was still 
flashing as it was since I started the cdrecord process (about once a 
second), even though I had interrupted that process.  Pressing the eject 
button did not make a difference.  I eventually paper-clipped the drive 
and manually removed the tray, at which point, all network services 
returned to normal.

Also, in another test, an ``ls /var/spool/imap'' (which is on the hard 
drive on the same chain) blocked.

Pertinent dmesg info:

hda: WDC AC2200F, ATA DISK drive
hdb: WDC AC2340H, ATA DISK drive
hdc: WDC WD102AA, ATA DISK drive
hdd: CD-RW CRX100E, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: WDC AC2200F, 202MB w/64kB Cache, CHS=989/12/35
hdb: WDC AC2340H, 325MB w/128kB Cache, CHS=330/32/63
hdc: WDC WD102AA, 9787MB w/2048kB Cache, CHS=19885/16/63
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1 host.
  Vendor: SONY      Model: CD-RW  CRX100E    Rev: 1.0m
  Type:   CD-ROM                             ANSI SCSI revision: 02
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
scsi : detected 1 SCSI cdrom total.
sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Uniform CDROM driver Revision: 2.56

and df:

[root@inky root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda5               153099    123329     21865  85% /
/dev/hda1                15858      3808     11222  25% /boot
/dev/hda6                31722     21447      8628  71% /home
/dev/hdb1               172857    157354      6578  96% /usr
/dev/hdc7               247919     12978    222141   6% /var
/dev/hdc5              2015952   1879004     34540  98% /var/cd
/dev/hdc6              2015984     98808   1814768   5% /usr/local
/dev/hdc8              5491816      1308   5377120   0% /var/spool/imap
Comment 1 Bitt Faulk 2000-08-19 17:51:36 EDT
I forgot to mention that I can record on CDRs and CDRWs fine without any 
network interruption.
Comment 2 Crutcher Dunnavant 2000-08-21 15:35:53 EDT
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 :)
Comment 3 Bitt Faulk 2000-08-21 19:09:04 EDT
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.
Comment 4 giulioo 2001-06-05 10:28:54 EDT
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@redhat.com 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.
Comment 5 giulioo 2001-06-05 11:02:40 EDT
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".

Note You need to log in before you can comment on or make changes to this bug.