Hi Tejun,
I know I said that I would try new kernels etc with this issue but I gave up. I bought a new tower server to replace my aging laptop 'server', that now runs on an ASUS P5Q3 M/B with an Intel ICH10 AHCI SATA controller and bought 2x1TB Western Digital RE3 drives to replace the e-SATA WD MyBook 500GB drives I was having issues with on the sata_sil 3512 controller.
As you can guess, I now have no issues whatsoever and the RE3 discs work wonderfully. I ended up selling the MyBook drives. Takes just over 3.5 hours to resync the RE3 drives compared with over 26 hours for the e-SATA 500GB drives. However I do not know how much the system performance affects the resync. I was running an AMD Turion 64 mobile chip 1.6GHz and now running Quad Core Q9550.
Regards,
Andrew
Hello, Henry.
Sorry about the late reply. I was traveling for quite some time.
Henry, Andrew wrote:
> I tried the patch wd.debug. I am sorry that it took so long. I
> assume that this was to help the wake-up problem with the MyBook
> drives ( I have many problems). I added this patch to 2.6.25.9 and
> ran the kernel and then started up my raid-1 array and did not use
> any cron scripts to keep the drives awake. I left the drives
> inactive for 30 minutes and then tried to access them. It seems ok.
> If this is what the patch was meant to fix, then it does seem to
> work. I have only tested this one time though.
Can you please post kernel log with and without the patch?
> I have so many other issues that I have gone back over to USB2
> instead of using the sata_sil 3512 CardBus controller, because it
> seems to stink badly.
>
> Other issues with 3512 controller:
>
> 1. When I write to the array, the activity lights show burst
> activity, i.e. the LEDs are not on constantly, but burst visibly
> with gaps inbetween where there is no activity. They burst many
> times a second, but it's enough to see that its not going at max
> throughput. If I read from the disk, then *sometimes* they light up
> constantly without going off. Does this indicate in some way, that
> the controller is not being utilized to it's maximum capability?
> Seems like the controller is capable of higher throughput, but
> something in the way IO happens is hindering it.
Well, the only way you can tell is by actually measuring the
throughput. How fast does it actually transfer?
> 2. A shutdown/startup or a reboot can kill the array, and then when
> it comes back up, only one disk is in the array and I have to re-add
> the other one causing a re-sync. This never happens on USB2, only
> when using 3512 and sata_sil on CardBus controller. One thing I
> notice is that when shutting down, after the the final KILL
> processes, I see a message saying something like "md is still
> active" right before the PC shuts down. Is this why I am losing a
> disk, because md is not being shut down properly before a
> reset/poweroff?
Hmmm... I can't tell without looking at the log. Can you please
attach log for the case where it loses one disk?
> 3. When the drives have gone to sleep and I try to access the
> mounted filesystem, or if I type "fdisk -l" after 10 minutes of not
> accessing the array, then the activity light on the CardBus
> controller lights up and does not go out for 1 minute. Fdisk -l
> does not report back until after the activity light has gone off.
> The same thing happens when udev starts when booting the system.
Does the kernel complains about anything during that 1 minute? Sounds
like there are command timeouts there.
> 4. If I eject the CardBus controller, after havin unmounted the raid
> filesystem and having stopped md, then I get a console message
> saying something along the lines of: **DANGER** power could not be
> stopped [when ejecting the controller card]. Sounds serious.
> Possible that I am damaging the controller when I do this.
I don't have much idea about that. Can you please report this to
linux-pcmcia@xxxxxxxxxxxxxxxxxxx and cc linux-ide and me?
> 5. IO times are very poor using eSATA CardBus 3512. I get 15MB/s vs
> 35MB/s on USB2 (reads using /usr/bin/time and dd where if is the
> device and of is /dev/null. Seems like either the 3512 controller
> card I have is just crap, and/or there are serious problems with the
> sata_sil driver when used in combination with a CardBus controller
> (anyone else out there with a CardBus?) Maybe the issues do not
> manifest themselves as much on PCI controllers? I am trying to
> source a CardBus controller at the moment that uses sata_sil24
> instead.
Hmmm... I also have a 3512 cardbus controller and it works just fine.
Again, does the kernel complain about anything? 15MB/s is way too
slow. What does "hdparm -t" on the drive report?
Thanks.
--
tejun
��.n��������+%������w��{.n�����{��'^�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
