From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugme-daemon@bugzilla.kernel.org Subject: [Bug 11646] QLA2xxx: Kernel deadlock on high load somewhere after 2.6.20 Date: Fri, 27 Feb 2009 08:17:21 -0800 (PST) Message-ID: <20090227161721.516A511D10A@picon.linux-foundation.org> References: Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:55967 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753137AbZB0QRx (ORCPT ); Fri, 27 Feb 2009 11:17:53 -0500 Received: from picon.linux-foundation.org (picon.linux-foundation.org [140.211.169.79]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id n1RGHLex013723 for ; Fri, 27 Feb 2009 08:17:22 -0800 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: linux-scsi@vger.kernel.org http://bugzilla.kernel.org/show_bug.cgi?id=11646 ------- Comment #21 from grin@grin.hu 2009-02-27 08:17 ------- #20, enlighten me in the internals, please. Can multipathd actually _cause_ driver timeouts? As much as I understood directio checker does nothing more than reads first and last sector of the device by direct IO (O_DIRECT) calls, and if that fails it fires an uevent towards userspace to handle the situation. Can it do anything "below", like the qla driver, or the scsi device itself? I tried 'tur' checker in the past with mixed results, and I'm not sure it meant the path was really down that much or the checker failed, but directio seemed the most generic. I thought it's the other way around, eg. qla timoeuts which makes multipathd cry. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.