Adrian Bunk wrote:
Before I'm getting flamed to death:
Adrian,
I have a few comments below.
This patch contains possible cleanups. If parts of this patch conflict
with pending changes these parts of my patch have to be dropped.
This patch contains the following possible cleanups:
- make needlessl
On Tue, 2005-03-01 at 16:19 +0900, FUJITA Tomonori wrote:
> The user-space daemon handles authentication and the kernel threads
> take care of network and disk I/O requests from initiators by using
> the VFS interface. The kernel-space code is not intrusive. It doesn't
> touch other parts of the k
On Tue, Feb 22 2005, Greg Stark wrote:
>
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> > fsync has been working all along, since the initial barrier support for
> > ide. only ext3 and reiserfs support it.
>
> Really? That's huge news. Since what kernel version(s) is that?
Since 2.6.9.
> What ab
Hi, list
If I surprisingly hot-remove a SCSI disk from HBA manually
without executing "echo "scsi remove-single-device
" > /proc/scsi/scsi", can the "hotplug"
event be notified to SCSI mid-layer or user space?
I briefly browse some code of LLDD, it seems that LLDD never
report "hotplug" event
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 09:40:38 +0100
> > Could you please review the code? Any comments are greatly
> > appreciated.
> > -
>
> can you explain why the target has to be inside the kernel and can't
On Tue, 2005-03-01 at 18:35 +0900, FUJITA Tomonori wrote:
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> Subject: Re: [ANNOUNCE] iSCSI enterprise target software
> Date: Tue, 01 Mar 2005 09:40:38 +0100
>
> > > Could you please review the code? Any comments are greatly
> > > appreciated.
> > > -
>
Under a fresh Mandrake 10.1 with a 2.6.8 kernel, the Fusion MPT driver
do recognize the HP tape autoloader. The autoloader is composed of tape
drive (on LUN 0) and the changer (on LUN 1).
The message comes from scsi_scan.c :
printk(KERN_WARNING "scsi: %s lun%d has a LUN larger"
" than
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 10:46:03 +0100
> fsync or msync() ? I would imagine the target mmaping it's backend in
> userspace and using msync() to kick off IO. At which point it's no
On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
> Date: Tue, 01 Mar 2005 10:46:03 +0100
>
> > fsync or msync() ? I would imagine the target mmaping it's backend in
On Tue, 2005-03-01 at 11:33 +0100, Arjan van de Ven wrote:
> On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
> > From: Arjan van de Ven <[EMAIL PROTECTED]>
> > Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
> > Date: Tue, 01 Mar 2005 10:46:03 +0100
> >
> > >
Manu wrote:
Under a fresh Mandrake 10.1 with a 2.6.8 kernel, the Fusion MPT driver
do recognize the HP tape autoloader. The autoloader is composed of tape
drive (on LUN 0) and the changer (on LUN 1).
The message comes from scsi_scan.c :
printk(KERN_WARNING "scsi: %s lun%d has a LUN larger"
Arjan van de Ven wrote:
On Tue, 2005-03-01 at 19:22 +0900, FUJITA Tomonori wrote:
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 10:46:03 +0100
fsync or msync() ? I would imagine the target mmapi
On Tue, 2005-03-01 at 11:48 +0100, Libor Vanek wrote:
> >
> I don't know in detail what are you talking about (if whole disk must
> fit address space) but please consider we're speaking about TBs (10-20
> TB RAID is quite cheap nowadays with 400 GB SATA disks).
so? if you need one map/unmap per
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Re: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 11:46:32 +0100
> note that on 32 bit servers the kernel side needs to do kmap() on the
> pages anyway, and that a kmap/kunmap series is very much equiv
Christoph Hellwig writes:
>> - scsi_scan.c: scsi_rescan_device
>aacraid was going to use that one, Mark, any chance to get a patch
anytime soon?
>> - scsi_scan.c: scsi_scan_single_target
>as mentioned above we'll need this one soon.
Yup, we use both of them in our branch of the driver. I submi
Douglas Gilbert wrote:
Perhaps you could try the sg_luns utility from the
sg3_utils package ( http://www.torque.net/sg )
with either the 2.4 or 2.6 kernel. It should be sent
to lun 0 (i.e. the tape drive), for example:
sg_luns /dev/st0
[I'm not sure whether st devices support the SG_IO
ioctl in l
On Tue, Mar 01, 2005 at 05:06:55PM +0800, Zhao, Forrest wrote:
> If I surprisingly hot-remove a SCSI disk from HBA manually
> without executing "echo "scsi remove-single-device
>" > /proc/scsi/scsi", can the "hotplug"
> event be notified to SCSI mid-layer or user space?
>
> I briefly browse s
On 03/01/05 03:14, Douglas Gilbert wrote:
- scsi_error.c: scsi_normalize_sense
I introduced scsi_normalize_sense() recently, Christoph H.
proposed it should be static but Luben Tuikov (aic7xxx
maintainer) said he wished to use it in the future.
Hence it was left global.
Hi guys,
I think the idea
If you are trying to automate the process then taking a look at SCSI RAS
tools at http://scsirastools.sourceforge.net might help. I am not sure how
much are these tools in use around (any comments?). Alternatively If you are
running on a disk hot-swap capable system the enclosure service processor
Nope. The last thing I put in was error recovery fix's,
but that should not effect performance. I'm not sure
whether that when into 2.6.10.
Do you know if http://linux-scsi.bkbits.net:8080/scsi-rc-fixes-2.6 is down
or moved?
I can't seem to see this website, to see whether there were any patche
Jens Axboe <[EMAIL PROTECTED]> writes:
> > What about a non-journaled fs, or at least a meta-data-only-journaled fs?
> > Journaled FS's don't mix well with transaction based databases since they're
> > basically doing their own journaling anyways.
>
> Only works on ext3 and reiserfs currently.
D
> On Tue, Mar 01, 2005 at 05:06:55PM +0800, Zhao, Forrest wrote:
> > If I surprisingly hot-remove a SCSI disk from HBA manually
> > without executing "echo "scsi remove-single-device
> >" > /proc/scsi/scsi", can the "hotplug"
> > event be notified to SCSI mid-layer or user space?
> >
> > I br
One thing that's implicit in your reasons for wanting to be in the kernel
is that you've chosen to exploit the kernel's page cache. As a user of
the page cache, you have more control from inside the kernel than from
user space. The page cache was designed to be fundamentally invisible to
user
Hello,
I found that the megaraid driver always fails to reset the
adapter with the following message:
megaraid: resetting the host...
megaraid mbox: reset sequence completed successfully
megaraid: fast sync command timed out
megaraid: reservation reset failed
On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
> One thing that's implicit in your reasons for wanting to be in the kernel
> is that you've chosen to exploit the kernel's page cache. As a user of
> the page cache, you have more control from inside the kernel than from
> user space.
On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
> On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
> > One thing that's implicit in your reasons for wanting to be in the kernel
> > is that you've chosen to exploit the kernel's page cache. As a user of
> > the page cache, you have m
Ming Zhang wrote:
On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
One thing that's implicit in your reasons for wanting to be in the kernel
is that you've chosen to exploit the kernel's page cache. As a user of
the page cache, you ha
On Tue, 2005-03-01 at 14:01, Jeff Garzik wrote:
> Ming Zhang wrote:
> > On Tue, 2005-03-01 at 13:37, Arjan van de Ven wrote:
> >
> >>On Tue, 2005-03-01 at 10:24 -0800, Bryan Henderson wrote:
> >>
> >>>One thing that's implicit in your reasons for wanting to be in the kernel
> >>>is that you've ch
Please try:
In mbox_post_sync_cmd_fast(...) replace
for (i = 0; i < 0xF; i++) {
if (mbox->numstatus != 0xFF) break;
}
with
for (i = 0; i < 0xF; i++) {
if (mbox->numstatus != 0xFF) break;
rmb();
}
Additionally, increase the loop counter to a bigger value.
Thank
On Tue, 2005-03-01 at 14:01, Vikas Aggarwal wrote:
> And If future IET be visioned as an Enterprise Class Array(Multiple
> Host-Side Adapters ie., FAs + Multiple Device Side Adapters ie., DAs),
> should better be in direct control of all the system-resources without
> being pushed out the kernel.
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> You want to *use* the kernel pagecache as much as you can. You do so by
> using mmap and such, and msync to force content to disk. That uses the
Last time I checked you couldn't mmap block devices. Has this changed
now? Could be a problem for an iS
On Tue, 2005-03-01 at 15:38, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > You want to *use* the kernel pagecache as much as you can. You do so by
> > using mmap and such, and msync to force content to disk. That uses the
>
> Last time I checked you couldn't mmap block d
Hi,
thanks for the info.
Adding one more 'F' to the loop counter works.
i.e. 0xFF.
Just adding rmb() didn't solve the problem though it
may decrease the necessary counter value.
I don't know this value is ok for environments other than mine.
Bagalkote, Sreen
>You want to *use* the kernel pagecache as much as you can.
No, I really don't. Not always. I can think of only 2 reasons to
maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
allows me to share resources (memory and disk bandwidth come to mind) with
others in the same
On Tue, 2005-03-01 at 12:53 -0800, Bryan Henderson wrote:
> >You want to *use* the kernel pagecache as much as you can.
>
> No, I really don't. Not always. I can think of only 2 reasons to
> maximize my use of the kernel pagecache: 1) saves me duplicating code; 2)
> allows me to share resource
Great! Can you give us details about your environment?
If it makes sense, we will increase the loop counter in the driver.
Thanks,
Sreenivas
LSI LOGIC Corporation
>-Original Message-
>From: Jun'ichi Nomura [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 01, 2005 3:50 PM
>To: Bagalkote,
>it is hard to beat linux kernel [page] cache performance though.
It's quite easy to beat it for particular applications. You can use
special knowledge about the workload to drop pages that won't be accessed
soon in favor of pages that will, not clean a page that's just going to
get discarded
On Tue, 2005-03-01 at 16:04, Bryan Henderson wrote:
> >it is hard to beat linux kernel [page] cache performance though.
>
> It's quite easy to beat it for particular applications. You can use
> special knowledge about the workload to drop pages that won't be accessed
> soon in favor of pages th
On Tue, 2005-03-01 at 13:04 -0800, Bryan Henderson wrote:
> >it is hard to beat linux kernel [page] cache performance though.
>
> It's quite easy to beat it for particular applications. You can use
> special knowledge about the workload to drop pages that won't be accessed
> soon in favor of pa
On Tue, Mar 01, 2005 at 09:40:48AM -0500, Luben Tuikov wrote:
> On 03/01/05 03:14, Douglas Gilbert wrote:
> >> - scsi_error.c: scsi_normalize_sense
> >
> >
> >I introduced scsi_normalize_sense() recently, Christoph H.
> >proposed it should be static but Luben Tuikov (aic7xxx
> >maintainer) said he
On Tue, Mar 01, 2005 at 09:38:34PM +0100, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > You want to *use* the kernel pagecache as much as you can. You do so by
> > using mmap and such, and msync to force content to disk. That uses the
>
> Last time I checked you couldn't
On 03/01/05 17:17, Christoph Hellwig wrote:
Doing it in the core means less duplication and avoiding updating
all drivers.
I agree.
Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
On Fri, Feb 25, 2005 at 01:26:50PM -0800, Mark Haverkamp wrote:
> I wonder if it wouldn't be better to just check the error return before
> the index value.
It's all the same to me.
In drivers/scsi/sd.c:sd_probe:
int index;
...
spin_lock(&sd_index_lock);
error = i
From: Bryan Henderson <[EMAIL PROTECTED]>
Subject: Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 1 Mar 2005 13:04:58 -0800
> >it is hard to beat linux kernel [page] cache performance though.
>
> It's quite easy to beat it for particular applications. You can use
> special knowledge
What surprises me is that if the LLDD *can't* get to know about the hot
plugging / unplugging of device, what is the use of the functions
scsi_add_device() and scsi_remove_device()??
Please note that these functions are provided by scsi mid-level driver to
LLDD to add / remove devices (Refer to
On Tue, Mar 01, 2005 at 11:35:28AM -0500, [EMAIL PROTECTED] wrote:
> > On Tue, Mar 01, 2005 at 05:06:55PM +0800, Zhao, Forrest wrote:
> > > If I surprisingly hot-remove a SCSI disk from HBA manually
> > > without executing "echo "scsi remove-single-device
> > >" > /proc/scsi/scsi", can the "ho
< but the LLDD doesn't get an interrupt from the firmware on such
events).
So you mean that when SCSI device is surprise-removed, HBA will not
assert an interrupt to kernel? Even LLDD doesn't know the SCSI device is
removed?
Thanks,
Forrest
-
To unsubscribe from this list: send the line "unsubscr
On Wed, Mar 02, 2005 at 12:47:46PM +0800, Zhao, Forrest wrote:
> < but the LLDD doesn't get an interrupt from the firmware on such
> events).
>
> So you mean that when SCSI device is surprise-removed, HBA will not
> assert an interrupt to kernel? Even LLDD doesn't know the SCSI device is
> removed
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
Date: Tue, 01 Mar 2005 18:35:49 +0900
> The last reason is that user-space cost like memory copy. With 1Gbs
> Ethernet, is is not critical. However, with 10G, it is critical, I
>
On Fri, Feb 18, 2005 at 12:05:52PM -0800, Greg KH wrote:
> On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
> > > /*
> > > + * sysfs stuff
> > > + * this should be moved to it's own file, maybe cciss_sysfs.h
> > > + */
> > > +
> > > +static ssize_t cciss_firmver_show(struct devic
On Wed, 2005-03-02 at 14:04 +0900, FUJITA Tomonori wrote:
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Subject: [Iscsitarget-devel] Re: [ANNOUNCE] iSCSI enterprise target software
> Date: Tue, 01 Mar 2005 18:35:49 +0900
>
> > The last reason is that user-space cost like memory copy. With 1Gbs
> >
hostt->queuecommand(cmd, scsi_done); and in the meantime a
timer is set. When the timer expires, SCSI mid-layer know the
execution of command has failed.
My question is: when SCSI device is surprise-removed, if SCSI mid-layer
issue a command to this removed device, will mid-layer has to wait
a t
Mark Lord wrote:
>"irq XX: nobody cared" is a screaming interrupt situation, which could
have 1001 causes.
Speaking of which. The 3ware drivers appear to have a bug
in their handling of this. They *always* report "handled=1"
from their interrupt routines, regardless of whether it was
their har
Only indicate irq-handled if that is really true
Driver currently returns IRQ_HANDLED for all interrupts. Fix this.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff -Nru a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
--- a/drivers/scsi/3w-9xxx.c2005-03-02 02:14:42 -05:00
+++ b/drivers/sc
Remove bogus irq test.
Driver tested irq handler's "irq" argument against the PCI device's
pci_dev->irq value, a test which would always succeed.
Change this to "if (1)" to avoid re-indenting the [huge]
interrupt handling code.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff -Nru a/drivers/scsi
Reduce irq handler indentation level.
The previous patch replaced an always-true test with "if (1)",
a function change.
This patch simply eliminates the "if (1)", and reduces the indentation
level of the entire [rather large] interrupt handler code.
No code changes other than eliminating the "if (1
Jeff Garzik wrote:
The previous patch replaced an always-true test with "if (1)",
a function change.
er, s/function/functional/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
57 matches
Mail list logo
