Silicon Image controller trouble

[larry moe 'n curly]

Windows XP Home SP3 runs very, very sluggishly and reports I/O errors
with certain hard drives connected to a Silicon Image SiL3512 SATA PCI
controller card (two samples), but only when another HD is connected
to the motherboard's built-in controller. With both HDs connected to
the Silicon Image card, everything is fine. Also other controller
cards, based on VIA or Promise chips, have no problems with any of
these configurations or HDs.

The HDs that don't always get along with the SiL3512 are WD10EADS and
Samsung F1. HDs that always work normally include the WD4000AAKS,
Hitachi 7K1000.C, and Seagate 7200.12.

I slowed the drives to 1.5Gbps (jumper or flash) and tried the Silicon
Image card in RAID and non-RAID configurations, with several BIOSes
and drivers. Also with the WD drives I tried many configurations for
IDLE3 and TLER. Nothing mattered.

The motherboards are based on Intel G41 and Nvidia GeForce6100 and
Nforce6 chipsets. Configuring the motherboard for AHCI or IDE mode or
turning off its RAID made no difference.

What's going on here?

 

[Arno]

Windows XP Home SP3 runs very, very sluggishly and reports I/O errors
with certain hard drives connected to a Silicon Image SiL3512 SATA PCI
controller card (two samples), but only when another HD is connected
to the motherboard's built-in controller. With both HDs connected to
the Silicon Image card, everything is fine. Also other controller
cards, based on VIA or Promise chips, have no problems with any of
these configurations or HDs.

The HDs that don't always get along with the SiL3512 are WD10EADS and
Samsung F1. HDs that always work normally include the WD4000AAKS,
Hitachi 7K1000.C, and Seagate 7200.12.

I slowed the drives to 1.5Gbps (jumper or flash) and tried the Silicon
Image card in RAID and non-RAID configurations, with several BIOSes
and drivers. Also with the WD drives I tried many configurations for
IDLE3 and TLER. Nothing mattered.

The motherboards are based on Intel G41 and Nvidia GeForce6100 and
Nforce6 chipsets. Configuring the motherboard for AHCI or IDE mode or
turning off its RAID made no difference.

What's going on here?

Just a WAG, but are external and internal conroller maybe on the
same interrupt? I don't really know how to change these with
the PCI bus, but XP doe not have good interrupt handling, so maybe
you get some kind of trahsing-like effect that very much depends on
the exact disk traffic timing.

You can also try with Linux (e.g. a current Knoppix CD/DVD should
have the Sil drivers and does not need an installation), and if
it is also slow there, then it is likely not an OS issue.

Arno

 

[larry moe 'n curly]

Just a WAG, but are external and internal conroller maybe on the
same interrupt? I don't really know how to change these with
the PCI bus, but XP does not have good interrupt handling, so maybe
you get some kind of trashing-like effect that very much depends on
the exact disk traffic timing.

You can also try with Linux (e.g. a current Knoppix CD/DVD should
have the Sil drivers and does not need an installation), and if
it is also slow there, then it is likely not an OS issue.

This Silicon Image controller works fine with Ubuntu Linux and Windows
98SE. Under XP, it shares IRQ 10H with lots of other devices, and
sometimes when XP becomes sluggish with the Intel G41 mobo, the system
buzzes with mouse movement and the Realtek audio software pops up and
asks if I've plugged something into an audio jack.

What puzzles me is why some model HDs work fine with this controller
but other HDs don't.

 

[Arno]

This Silicon Image controller works fine with Ubuntu Linux and Windows
98SE. Under XP, it shares IRQ 10H with lots of other devices, and
sometimes when XP becomes sluggish with the Intel G41 mobo, the system
buzzes with mouse movement and the Realtek audio software pops up and
asks if I've plugged something into an audio jack.

Ok, so I think the interrupt handling looks likely.

What puzzles me is why some model HDs work fine with this controller
but other HDs don't.

I suspect some specific characteristics, like how long it takes
after a command is set for the data to arrive or something like
that. The problem may only happen if this intervall falls
with some frequency into a certain window. Practically impossible
to debug except with extreme effort. The solution is typically
to swap out components until it seems to vanish (low reliability
systems) or to go to a different, more robust driver model
entirely (high reliability needs). As XP is was pretty much
already 1-2 decades behind the times when it reached the market,
I am not surprised to see such problems.

Although it is not interlectually satisfying, I would propose not
to spend more effort trying to understand the issue in detail. The
poytential gain os just too small.

Arno

 

[larry moe 'n curly]

larrymoencurly wrote:

Ok, so I think the interrupt handling looks likely.


I suspect some specific characteristics, like how long it takes
after a command is set for the data to arrive or something like
that. The problem may only happen if this intervall falls
with some frequency into a certain window. Practically impossible
to debug except with extreme effort. The solution is typically
to swap out components until it seems to vanish (low reliability
systems) or to go to a different, more robust driver model
entirely (high reliability needs). As XP is was pretty much
already 1-2 decades behind the times when it reached the market,

I.e., a recent upgrade for me.

Although it is not interlectually satisfying, I would propose not
to spend more effort trying to understand the issue in detail. The
potential gain is just too small.

I guess I'm expecting too much from a controller that was less than
$50, delivered -- for 20 of them. I bought these controllers
because everybody said the ubiquitous VIA VT6421A controllers were
troublesome and also incompatible with 3.0 gigabits/second SATA
drives, but apparently VIA has fixed the defects because I can't get
the latest ones to act up with anything (date code 1004, version CD,
BIOS 4.95).