From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugme-daemon@bugzilla.kernel.org Subject: [Bug 12120] [Block layer or SCSI] requests aborted too early during check_partition() Date: Sat, 29 Nov 2008 07:12:35 -0800 (PST) Message-ID: <20081129151235.C9895108041@picon.linux-foundation.org> References: Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:51695 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342AbYK2PMh (ORCPT ); Sat, 29 Nov 2008 10:12:37 -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 mATFCZv8008519 for ; Sat, 29 Nov 2008 07:12:36 -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=12120 ------- Comment #1 from anonymous@kernel-bugs.osdl.org 2008-11-29 07:12 ------- Reply-To: stefanr@s5r6.in-berlin.de On 29 Nov, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12120 > > Summary: [Block layer or SCSI] requests aborted too early during > check_partition() > Product: IO/Storage > Version: 2.5 > KernelVersion: 2.6.28-rc > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: SCSI > AssignedTo: linux-scsi@vger.kernel.org > ReportedBy: stefan-r-bz@s5r6.in-berlin.de > OtherBugsDependingO 11808 > nThis: > Regression: 1 > > > Latest working kernel version: 2.6.27.4 > Earliest failing kernel version: 2.6.28-rc6 (I didn't test earlier -rcs yet) > > Hardware Environment: OxSemi 912 and 92x based FireWire harddisks > > > See http://marc.info/?l=linux-scsi&m=122774022130397 -- > Disks may still spin their motor up when the kernel attempts to read > partitions. In kernel 2.6.27, this was handled transparently. But since > 2.6.28-rc?, the kernel immediately aborts the associated requests and sets the > new scsi_device offline. > > I tried a workaround in firewire-sbp2: Check whether the new sdev is offline right after scsi_add_device. If so, remove the sdev and try everything again. However, - a regression still remains because the addition of the HDD takes about 30...40 seconds instead of only a few seconds like in 2.6.27. - The workaround works with OXFW912 and OXUF922, but not with OXUF924DSB. Login retries don't succeed with the latter at all. - The workaround would be very hard to implement in the older ieee1394/sbp2 driver. - Other hardware besides FireWire may be affected. -- 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.