Re: 2.6.25: sata_sil freezes, hard resets port.

[Tejun Heo <tj@kernel.org>]

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@lists.infradead.org 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