Red Hat Bugzilla – Bug 132467
I/O problems using SCSI controller AIC7XXX (problems remains with kernel 2.4.21-20-EL)
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Description of problem:
After reading this errata:
I updated my kernel to 2.4.21-20.ELsmp, but I still have the I/O
problems when I use the dd command to copy a small file to my DLT device.
My DLT is connected to a SCSI controller AIC7XXX.
I think that the BUG was not completely fixed, or Am I doing something
Version-Release number of selected component (if applicable):
Steps to Reproduce:
dd if=/root/anaconda-ks.cfg of=/dev/nts0 bs=128k
Actual Results: 3+1 records in
3+1 records out
dd: closing output file `/dev/nst0': Input/output error
I'm using all latest updates up to 09/13/2004 and this problem was not
I am looking for more details and the history, if any, on this
problem. Did you submit a bug report on this already? If so, please
post the number? Was there a fix that was purported to resolve the issue?
This was the first time I submitted a bug report on Red Hat Bugzilla.
I read all the ERRATA from the Red Hat Network regarding this bug on
the past kernel releases.
But according to this errata:
http://rhn.redhat.com/errata/RHBA-2004-433.html , the bug should be
fixed, but it didn't.
I still have the problem although I upgraded the the latest kernel
released from Red Hat.
What additional details do you need? Please tell me what exactly what
do you need.
I think this bug should be reported to the Red Hat Enterprise support,
I'm working on that as well.
I'm reporting this problem because eventhough Red Hat released a bug
fix to this problem, it may still be bugged on some hardware.
Thanks for your support so far
This isn't a bug. Most tape drives need padding bytes at the end of
partial blocks. As indicated by the dd command, it read 3 full and 1
partial block from the input file, and wrote the same to the output
file. You either need to tell dd to pad the output to full block
sizes or use tar with the same options (you can tell tar both the
block size to use and to pad any underflow, can't remember the options
to do that though, so man tar will be your friend there). In any
case, if the problem persists when using padded output to talk to the
tape device, then please open another bug report. Until then though,
I'm closing this one as NOTABUG.