On Fri, May 15, 2009 at 11:17 PM, Bill Hacker <w...@conducive.org> wrote:

> Tim Darby wrote:
>
>> I have a machine that was running Windows XP until I recently
>> installed 2.2.2 on it.  This was mainly for the purpose of trying out
>> Hammer.  It contains a 40GB drive, which I made the boot drive and
>> installed with Hammer.  The other 2 drives are a 300GB Samsung IDE and
>> a 200GB Western Digital IDE, both connected to a SiI 0680 controller.
>> I've succcessfully installed Hammer on the WD drive, but the Samsung
>> fails as follows:
>>
>> # newfs_hammer -L BACKUP /dev/ad6s1a
>> Volume 0 DEVICE /dev/ad6s1a     size 279.46GB
>> initialize freemap volume 0
>> ad6: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=2245359
>> ad6: TIMEOUT - READ_DMA retrying (0 retries left) LBA=2245359
>> ad6: WARNING - READ_DMA status=51<READY,DSC,ERROR>
>> error=84<ICRC,ABORTED> LBA=2245359
>> newfs_hammer: get_buffer: /dev/ad6s1a:2000000000814000 Read failed at
>> offset 1149583360: Input/output error
>>
>> I ran a Samsung diagnostic on it and it found a DMA command timeout
>> problem (service code AJ27), so it appears that the drive really does
>> have a problem.  Just for kicks though, I tried installing UFS on this
>> drive and it gave me no complaints and seems to actually work.  Also,
>> Windows XP seemed to be working fine with this drive.  Does that make
>> any sense?
>>
>> Tim
>>
>
> I don't see your Silicon Image HBA reported in dmesg all that differently
> from one I am using.
>
> Relevant ID's from FreeBSD 7.1 AMD64 are;
>
> atapci0: <SiI SiI 3114 SATA150 controller> port
> 0x40a0-0x40a7,0x4094-0x4097,0x4098-0x409f,0x4090-0x4093,0x4080-0x408f
> mem 0xdc040000-0xdc0403ff irq 19 at device 6.0 on pci10
>
> Yours form DragonFly were:
>
> atapci0: <SiI 0680 UDMA133 controller> port
> 0xec70-0xec7f,0xec90-0xec93,0xec98-0xec9f,0xeca8-0xecab,0xecb0-0xecb7
> mem 0xff1afc00-0xff1afcff irq 11 at device 11.0 on pci2
>
>
> Further - I've had chronic trouble of the same sort with WD, Maxtor,
> Fujitsu, and Samsung drives on the Intel IHC7 (Tyan Tomcat) under FreeBSD
> between 6.2 and 7.1 - not entirely absent on 7.1, either, and have moved
> drives OFF the onboard IHC7 onto a cheap-as-dirt SiI PCIB HBA that runs 'em
> slower, but trouble free.
>
> Mine has:
>
> atapci1: <Intel ICH7 SATA300 controller> port
> 0x30c0-0x30c7,0x30b4-0x30b7,0x30b8-0x30bf,0x30b0-0x30b3,0x30a0-0x30af mem
> 0xdc500400-0xdc5007ff irq 19 at device 31.2 on pci0
>
>
> You are showing an IHC2:
>
> atapci1: <Intel ICH2 UDMA100 controller> port
> 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on
> pci0
>
> (rest of dmesg snipped).
>
>
> So I don't think it is the drives, and it may not be DragonFly, either.
>
> Intels' IHC series are as ubiquitous as housefly feces - and not a great
> deal more welcome in our house these days as drive controllers go.
>
> HTH,
>
> Bill
>
>
Thanks, Bill.  I tried switching the drive ports on the Sil 0680 and no
luck. I have an open IDE port on IC2, so I tried moving the problem Samsung
drive there and, voila, it works fine with Hammer now.  The WD drive is
still working fine on the Sil 0680, so I'm leaving it there.  I can only
conclude at this point that the Sil and the Samsung simply can't talk DMA,
for whatever reason, and I'm not inclined to chase it down.  I read
somewhere that if Windows XP has problems getting DMA to work, it
automatically switches to PIO.  Could that be why XP was OK with the
original configuration?

Tim

Reply via email to