Re: IP27: Random hard locks after ~16hrs uptime

[Joshua Kinard <kumba@gentoo.org>]

On 02/08/2015 19:53, Joshua Kinard wrote:
> On 02/08/2015 07:06, Maciej W. Rozycki wrote:
>> On Sat, 7 Feb 2015, Joshua Kinard wrote:
>>
>>> I've had my Onyx2 running quite a bit lately doing compile runs, and it seems
>>> that after about ~16 hours, there's a random possibility that the machine just
>>> completely stops.  No errors printed anywhere, serial becomes completely
>>> unresponsive.  I have to issue a 'rst' from the MSC to bring it back up again.
>>
>>  If the time spent up is always similar, then one possibility is a counter 
>> wraparound or suchlike that is not handled correctly (i.e. the carry from 
>> the topmost bit is not taken into account), causing a kernel deadlock.
> 
> I believe I've pinned the problem down to the block I/O layer and points
> beneath, such as SCSI core, qla1280, etc.  I am using an out-of-tree patch to
> add the BFQ I/O scheduler in, so that may also be a cause to consider.
> 
> I had a very similar hardlock on the Octane, too, when I upgraded the RAM to
> 3.5GB the other day, but going back to 2GB solves the problem there.  Octane
> is, for all intents and purposes, a single-node Origin system w/ graphics
> options, HEART instead of HUB, and a much more simplified PROM).  Both use the
> same SCSI chip, a QLogic ISP1040B, and thus the same driver, qla1280.o.  The
> difference with the Octane is I can reproduce the hardlock on demand by
> untarring a large tarball (a Gentoo stage3, to be exact).  Compared to the
> Onyx2, which has 8GB of RAM, and the lock seems more random.
> 
> I'll have to reconfigure the Octane later on with 3.5GB of RAM again, but test
> BFQ, CFQ, and Deadline out to see if the hardlock happens with all three.  I
> know BFQ is largely derived from the CFQ code, so if the system remains stable
> with Deadline, but not CFQ or BFQ, then I know the subsystem.  Then, if it only
> happens on BFQ, I'll go pester their upstream for debugging advice.

For the Octane, it looks like it's something with the scheduler.  If I use
"No-op", the machine can unpack a stage3 just fine.  If I use Deadline or CFQ,
it dies.  I did get several oopses under both, but they're not specific to
Octane or MIPS code, and the Oops output doesn't always trigger with each
attempt.  Several were actually "Reserved instruction in kernel code", but the
failing instruction was an "sw", which should work fine.  Other weird one was
"do_cpu invoked from kernel context!" -- new to me.  Saved all of them in case
anyone is interested in it.

I'll have to test this on the Onyx2 later to see if similar results
happen there.  That way, I'll know that I am chasing the same bug down.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic