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) Gecko/20040301 Description of problem: Hello, After reading this errata: http://rhn.redhat.com/errata/RHBA-2004-433.html 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 wrong? Thanks Version-Release number of selected component (if applicable): kernel-smp-2.4.21-20.EL How reproducible: Always 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 Additional info: I'm using all latest updates up to 09/13/2004 and this problem was not fixed yet!
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?
Hello Tom, 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.