Re: port-sparc/46530 (Install failure of NetBSD/sparc 5.1.2 and 6.0_BETA2 on qemu-1.0.1 and 1.1.0)

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

The following reply was made to PR port-sparc/46530; it has been noted by GNATS.

From: jnemeth%victoria.tc.ca@localhost (John Nemeth)
To: gnats-bugs%NetBSD.org@localhost, martin%NetBSD.org@localhost, 
gnats-admin%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost, ryoon%NetBSD.org@localhost
Cc: 
Subject: Re: port-sparc/46530 (Install failure of NetBSD/sparc 5.1.2 and 
6.0_BETA2 on qemu-1.0.1 and 1.1.0)
Date: Thu, 27 Sep 2012 23:07:33 -0700

 On Jan 11,  6:22am, Ryo ONODERA wrote:
 }
 } The following reply was made to PR port-sparc/46530; it has been noted by 
GNATS.
 } 
 } From: Ryo ONODERA <ryo_on%yk.rim.or.jp@localhost>
 } To: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
 } Cc: 
 } Date: Wed, 26 Sep 2012 03:12:07 +0900 (JST)
 } 
 }  Sadly with tsutsui@'s patch,
 }  I have gotten the errors.
 }  
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
 }  
 }  Frequency is relatively low, but reproducable.
 }  
 }  I have submit the patch to qemu-devel.
 }  And I will follow the report.
 
      I've seen these messages on my Ultra 2 with a Seagate ST373453LC
 hard disk.  It is a 72.5 GB, 15,000 RPM Ultra SCSI drive.  The drive
 works fine in a PC:
 
 ahc1 at pci8 dev 1 function 0: Adaptec 2940 Ultra SCSI adapter
 ahc1: interrupting at ioapic0 pin 22
 ahc1: aic7880: Ultra Wide Channel A, SCSI Id7, 16/253 SCBs
 scsibus0 at ahc1: 16 targets, 8 luns per target
 sd0 at scsibus0 target 0 lun 0: <IBM-SSG, S53D073, C61A> disk fixed
 sd0: 70006 MB, 31310 cyl, 8 head, 572 sec, 512 bytes/sect x 143374000 sectors
 sd0: sync (100.00ns offset 8), 16-bit (20.000MB/s) transfers, tagged queueing
 
 The drive was rebadged by IBM with at least some firmware customisation
 (i.e.  model string).
 
      This means that the bug might not be in qemu, but rather with our
 esp(4).
 
 }-- End of excerpt from Ryo ONODERA