Oops, sorry, I sent the patches to linux-kernel...
=
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH 1/2] ch: fix device minor number management bug
ch_probe uses the total number of ch devices as minor.
ch_probe:
ch->minor = ch_devcount;
...
ch_devcount++;
Then ch_rem
This moves ch_template and changer_fops structs to the end of file and
removes forward declarations.
This also removes some trailing whitespace.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/ch.c | 120 -
1 files changed,
Hi,
Thank you for the patch.
I have applied the patch to 2.6.23.14 and it works well.
- In case of 2.6.23.14, the problem is reproduced.
- In case of 2.6.23.14 with this patch, raid1 works well so far.
The fault injection script continues to run, and it doesn't deadlock.
I will keep it runnin
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
> >
> >.
> >. . STGT read SCST read.
Bart Van Assche wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
.
. . STGT read
On Thu, Jan 24, 2008 at 11:36:45AM +0100, Bart Van Assche wrote:
>On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
>> On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
>> >.
>>
On Thu, Jan 24, 2008 at 02:10:06PM +0300, Vladislav Bolkhovitin wrote:
>> On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
>>> how are write speeds with SCST SRP?
>>> for some kernels and tests tgt writes at >2x the read speed.
>
> There is a fundamental difference between regular d
Robin Humble wrote:
On Thu, Jan 24, 2008 at 11:36:45AM +0100, Bart Van Assche wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
Robin Humble wrote:
On Thu, Jan 24, 2008 at 02:10:06PM +0300, Vladislav Bolkhovitin wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
how are write speeds with SCST SRP?
for some kernels and tests tgt writes at >2x the read speed.
There is a fundamental difference betw
On Mon, Jan 14, 2008 at 04:04:21PM -0600, James Bottomley wrote:
> On Mon, 2008-01-14 at 22:03 +0100, Vojtech Pavlik wrote:
> > On Mon, Jan 14, 2008 at 02:03:45PM -0600, James Bottomley wrote:
> > > On Mon, 2008-01-14 at 11:45 -0800, Darrick J. Wong wrote:
> > > > On Mon, Jan 14, 2008 at 03:49:16PM
Alan noticed the lack of locking surrounding the driver's dealings with the fib
context managed by the trio of ioctls that are used by the RAID management
applications to retrieve Adapter Initiated FIBs. I merely expanded the fib lock
to include the fib context. There have been no field reports
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
> >
> >.
> >. . STGT read SCST read.
With gcc 4.1.2 on fedora7 x86_64, cross compiling an i386 kernel i get
the following compilation warning:
CC [M] drivers/scsi/qla2xxx/qla_sup.o
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c: In
function ‘qla2x00_beacon_blink’:
/usr0/export/dev/bharrosh/git/pub/scsi-mi
Greg KH wrote:
> I just am worried that we are
> now suddenly keeping access from the last sector for devices that
> currently did work just fine.
This new workaround doesn't prevent access to the last sector. It only
breaks up a multi-sector access which would also reach the last sector
into sev
I get "unexpected IRQ trap at vector dd" when reloading mptspi with MSI
enabled. This seems to happen only on dual-channel HBAs; single-channel
HBAs are unaffected. It looks like the second channel is generating a
bogus MSI interrupt while the first channel is being brought up.
modprobe mpt_base
> The last-sector-(access-)bug workaround _only_ modifies the command
> stream which is sent to the device. A dangerous command is replaced by
> equivalent safe commands.
BTW, one thing about this patch set needs to be criticized:
"last_sector_bug" is a really bad name choice for the new flag.
On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote:
> Greg KH wrote:
> > I just am worried that we are
> > now suddenly keeping access from the last sector for devices that
> > currently did work just fine.
>
> This new workaround doesn't prevent access to the last sector. It only
> b
On Thu, 24 Jan 2008, Boaz Harrosh wrote:
> With gcc 4.1.2 on fedora7 x86_64, cross compiling an i386 kernel i get
> the following compilation warning:
>
> CC [M] drivers/scsi/qla2xxx/qla_sup.o
> /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:
> In function ‘qla2x00_be
Tony Battersby wrote:
> I get "unexpected IRQ trap at vector dd" when reloading mptspi with MSI
> enabled. This seems to happen only on dual-channel HBAs; single-channel
> HBAs are unaffected. It looks like the second channel is generating a
> bogus MSI interrupt while the first channel is being
Bart Van Assche wrote:
On Jan 24, 2008 8:06 AM, Robin Humble <[EMAIL PROTECTED]> wrote:
On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote:
.
. . STGT read
Hi,
I am experiencing odd error messages on a server and can't sort out if
it is a software or hardware problem.
Server is running linux 2.6.22 kernel from Ubuntu server distro
(2.6.22-14-server) on a bi-AMD64 Opteron machine.
The SCSI board is an Adaptec AIC-7902B (see (1) below for lspci outpu
From: Vegard Nossum <[EMAIL PROTECTED]>
This patch adds the proper $(obj) and $(src) prefixes to dependency
rules in aic7xxx makefile. Without this patch, there is a remote
possibility that parallel make with a different output directory can
fail.
Also changed the deprecated EXTRA_CFLAGS construc
In mptsas.c there are two functions mptsas_find_phyinfo_by_target and
mptsas_find_phyinfo_by_sas
_address. Below is the 'by_target' function. It appears the intent
is to break out of the search when the matching phy_info is found.
However, the 'break' statement will only move to the next 'list' e
On Jan 24, 2008 8:54 PM, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote:
> Ib_rdma_bw now reports 933 MB/s on the same system, correct? Those
> ~250MB/s difference is what you will gain with zero-copy IO implemented
> and what STGT with the current architecture has no chance to achieve.
Yes, that
24 matches
Mail list logo
