[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ob9koogb.fsf@spindle.srvr.nix>
Date: Tue, 30 Jul 2013 01:56:20 +0100
From: Nix <nix@...eri.org.uk>
To: Douglas Gilbert <dgilbert@...erlog.com>
Cc: Bernd Schubert <bernd.schubert@...tmail.fm>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-scsi@...r.kernel.org,
"Martin K. Petersen" <martin.petersen@...cle.com>,
nick.cheng@...ca.com.tw, stable@...r.kernel.org
Subject: Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition
On 30 Jul 2013, Douglas Gilbert outgrape:
> Please supply the information that Martin Petersen asked
> for.
Did it in private IRC (the advantage of working for the same division of
the same company!)
I didn't realise the original fix was actually implemented to allow
Bernd, with a different Areca controller, to boot... obviously, in that
situation, reversion is wrong, since that would just replace one won't-
boot situation with another.
It looks like a solution is possible that will let us boot *both* my
controller (with its old 2009-era firmware) *and* his. We just have
to let Martin implement it. Give him time, I only got a successful
boot out of it an hour ago :)
> I just examined a more recent Areca SAS RAID controller
> and would describe it as the SCSI device from hell. One solution
> to this problem is to modify the arcmsr driver so it returns
> a more consistent set of lies to the management SCSI commands that
> Martin is asking about.
I can't help notice that something is skewy in its error handling, too.
When the controller errors, even resetting the bus doesn't seem to be
enough to bring it back :/ I've seen errors from it before which did
*not* lead to it imploding forever, but this is apparently not one such.
Certainly Areca-the-company has... issues with communication with the
community (i.e., they don't). A shame I didn't know that before I bought
the controller and made all my data completely dependent on it, really.
Shame, the controller otherwise works very well (fast, and has coped
with a disk failure with aplomb).
--
NULL && (void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists