On Wed, Apr 06 2005, James Bottomley wrote:
> On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote:
> > > I think the correct model for all of this is that the block driver
> > > shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can
> > > reject requests from a queue whose device h
Hi,
Sorry, no such "driver" directory in /sys/class/scsi_host/hostX/
(checked: Emulex "lpfc" 8.0.24 and LSI "mptscsih" 3.01.18)
note: there's also a "proc_name" interface for LSI "mtpscsih", located in
/sys/class/scsi_host/hostX/, which is reporting "mptscsih" string.
Any other ideas ?
Best regar
Dear Sir,
You will be surprise to see this message but I got your information
through Spartanburg, area chamber of commerce USA.
My name is Howard Jones, a Chief Auditor, during my last auditing in
the United States of America with JPMORGANCHASE CO.in New York, we
realized
the sum $35.5million ow
Patrick Mansfield wrote:
On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0]qla1280
[1]qla1280
[2]qla2xxx
[3]
On Wed, 2005-04-06 at 21:08 +0200, Jens Axboe wrote:
> > I think the correct model for all of this is that the block driver
> > shouldn't care (or be tied to) the scsi one. Thus, as long as SCSI can
> > reject requests from a queue whose device has been released (without
> > checking the device) t
Tejun Heo [EMAIL PROTECTED] wrote:
> Jens Axboe wrote:
> >On Wed, Apr 06 2005, Arjan van de Ven wrote:
> >
> >>>@@ -324,6 +334,7 @@
> >>> issue_flush_fn *issue_flush_fn;
> >>> prepare_flush_fn*prepare_flush_fn;
> >>> end_flush_fn*end_flush_fn;
> >>>+ release_queu
On Wed, Mar 30, 2005 at 08:07:02PM +0200, Kay Sievers wrote:
> On Tue, Mar 29, 2005 at 08:20:43PM -0800, Greg KH wrote:
> > On Wed, Mar 30, 2005 at 05:15:55AM +0200, Kay Sievers wrote:
> > > /**
> > > + * sysfs_chmod_file - update the modified mode value on an object
> > > attribute.
> > > + * @k
On Wed, Apr 06 2005, James Bottomley wrote:
> On Wed, 2005-04-06 at 19:58 +0200, Jens Axboe wrote:
> > I rather like the queue lock being a pointer, so you can share at
> > whatever level you want. Lets not grow the request_queue a full lock
> > just to work around a bug elsewhere.
>
> I'm not pro
On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote:
> 2/ now, how can we get the adapter module name from sysfs ?
Why do you need it?
Anyway, try lsscsi, it walks the sysfs tree:
[elm3b79 patman]$ lsscsi -H
[0]qla1280
[1]qla1280
[2]qla2xxx
[3]qla2xxx
Or, scrip
welcome. let us know if works. thx.
ming
On Wed, 2005-04-06 at 14:30, Salyzyn, Mark wrote:
> Thanks, needed to set shost->max_cmd_len to 16 in the driver.
>
> Sincerely -- Mark Salyzyn
>
> -Original Message-
> From: Ming Zhang [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 06, 2005
Thanks, needed to set shost->max_cmd_len to 16 in the driver.
Sincerely -- Mark Salyzyn
-Original Message-
From: Ming Zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 06, 2005 12:12 PM
To: Salyzyn, Mark
Cc: Linux SCSI
Subject: Re: SAI_READ_CAPACITY_16?
we tested several iSCSI init
On Wed, 2005-04-06 at 12:00 -0400, Salyzyn, Mark wrote:
> For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
> kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
> command to the queuecommand handler (the handler is not even called),
> even though it instruments up
On Wed, 2005-04-06 at 19:58 +0200, Jens Axboe wrote:
> I rather like the queue lock being a pointer, so you can share at
> whatever level you want. Lets not grow the request_queue a full lock
> just to work around a bug elsewhere.
I'm not proposing that it not be a pointer, merely that it could be
On Wed, Apr 06 2005, Tejun Heo wrote:
> Jens Axboe wrote:
> >On Wed, Apr 06 2005, Arjan van de Ven wrote:
> >
> >>>@@ -324,6 +334,7 @@
> >>> issue_flush_fn *issue_flush_fn;
> >>> prepare_flush_fn*prepare_flush_fn;
> >>> end_flush_fn*end_flush_fn;
> >>>+ release_q
On Wed, Apr 06 2005, James Bottomley wrote:
> On Tue, 2005-03-29 at 14:03 +0200, Jens Axboe wrote:
> > It is quite a serious problem, not just for CFQ. SCSI referencing is
> > badly broken there.
>
> OK ... I accept that with regard to the queue lock.
It is much deeper than that. The recent hack
On Tue, 2005-03-29 at 14:03 +0200, Jens Axboe wrote:
> It is quite a serious problem, not just for CFQ. SCSI referencing is
> badly broken there.
OK ... I accept that with regard to the queue lock.
However, rather than trying to work out a way to tie all the refcounted
objects together, what abou
we tested several iSCSI initiator/target combinations that work with
>2TB devices in current 2.6.11.x kernel.
our experience is that some code only support cdb len 10 or 12. you need
16.
Ming
On Wed, 2005-04-06 at 12:00, Salyzyn, Mark wrote:
> Troubled spoofing back >2TB support in the aacraid
Troubled spoofing back >2TB support in the aacraid driver.
For some reason, sd_read_capacity (in sd.c) in the 2.6.9-5.EL (RHEL4)
kernel is not issuing the SERVICE_REQUEST_IN+SAI_READ_CAPACITY_16
command to the queuecommand handler (the handler is not even called),
even though it instruments up tha
Hi,
This patch mainly introduces support for point-2-point
topology.
Regards,
Andreas
From: Heiko Carstens <[EMAIL PROTECTED]>
From: Maxim Shchetynin <[EMAIL PROTECTED]>
From: Andreas Herrmann <[EMAIL PROTECTED]>
zfcp changes:
- add support for point-2-point topology
- correct permissions f
Hi,
Patch converts zfcp to use compat_ioctl.
Thanks to Cristoph who reminded me to adapt zfcp.
Regards,
Andreas
zfcp changes: convert zfcp to compat_ioctl
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
= zfcp_aux.c 1.19 vs edited =
--- 1.19/drivers/s390/scsi/zfcp_aux.c 2005-
Jens Axboe wrote:
On Wed, Apr 06 2005, Arjan van de Ven wrote:
@@ -324,6 +334,7 @@
issue_flush_fn *issue_flush_fn;
prepare_flush_fn*prepare_flush_fn;
end_flush_fn*end_flush_fn;
+ release_queue_data_fn *release_queue_data_fn;
/*
On Wed, Apr 06 2005, Arjan van de Ven wrote:
> > @@ -324,6 +334,7 @@
> > issue_flush_fn *issue_flush_fn;
> > prepare_flush_fn*prepare_flush_fn;
> > end_flush_fn*end_flush_fn;
> > + release_queue_data_fn *release_queue_data_fn;
> >
> > /*
> > *
> @@ -324,6 +334,7 @@
> issue_flush_fn *issue_flush_fn;
> prepare_flush_fn*prepare_flush_fn;
> end_flush_fn*end_flush_fn;
> + release_queue_data_fn *release_queue_data_fn;
>
> /*
>* Auto-unplugging state
where does this function
On Tue, Mar 29 2005, Jens Axboe wrote:
> On Tue, Mar 29 2005, Chris Rankin wrote:
> > >> > I have one IDE hard disc, but I was using a USB memory stick at one
> > > > point. (Notice the usb-storage and vfat modules in my list.) Could
> > > > that be the troublesome SCSI device?
> >
> > --- Jens Ax
Hello,
We are using HBAs modules names from "proc_name" interface in sysfs:
/sys/class/scsi_host/hostX/proc_name.
But with new Emulex drivers (8.0.21 and +), proc_name is reporting
(previous drivers were reporting "lpfc").
=> In the driver code, .proc_name field from scsi_host_template structure
25 matches
Mail list logo
